You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the current way of registering the services in the DI Container it is a bit difficult (even impossible in some cases) to override Controller registrations.
In the case of WebApi Controllers, they are registered after all IDnnStartup implementations, at the end of DotNetNuke.Web.Startup.ConfigureServices().
As for the MVC Controllers, they are registered in the MVC IDnnStartup. The iteration over the IDnnStartup implementations does not have a specific ordering, which means that most likely they will be called based on the name of the containing assembly. Because of this, the MVC Startup might be executed after some other vendors Startup's.
This ordering issue might affect other areas as well.
Description of solution
The direct solution for the issue at hand would be to register the controllers using the TryAddScoped(controllerType) IServiceCollection extension method, which will add the controller to the collection only if the controller hasn't already been registered.
Description of alternatives considered
A solution to the broader issue, would be to either define an ordering/priority scheme, that could span multiple levels, either just calling the DNN IDnnStartup implementations first and then the rest.
Affected browser
Chrome
Firefox
Safari
Internet Explorer
Edge
The text was updated successfully, but these errors were encountered:
@bdukes Yes, this appears be a duplicate of #3335. From what I can see there is no PR for that issue and solving the priority might not be trivial. With the fix in the PR that I've opened for this issue the controllers (which are the entry point for the vendors) can be easily overridden no matter the ordering of the IDnnStartups. I was hoping that the PR could be merged for the 9.5.0 release as the changes are minimal and reverting back from the TryAdd is non-breaking once the ordering is in place.
Description of problem
With the current way of registering the services in the DI Container it is a bit difficult (even impossible in some cases) to override Controller registrations.
In the case of WebApi Controllers, they are registered after all IDnnStartup implementations, at the end of
DotNetNuke.Web.Startup.ConfigureServices()
.As for the MVC Controllers, they are registered in the MVC IDnnStartup. The iteration over the IDnnStartup implementations does not have a specific ordering, which means that most likely they will be called based on the name of the containing assembly. Because of this, the MVC Startup might be executed after some other vendors Startup's.
This ordering issue might affect other areas as well.
Description of solution
The direct solution for the issue at hand would be to register the controllers using the
TryAddScoped(controllerType)
IServiceCollection extension method, which will add the controller to the collection only if the controller hasn't already been registered.Description of alternatives considered
A solution to the broader issue, would be to either define an ordering/priority scheme, that could span multiple levels, either just calling the DNN IDnnStartup implementations first and then the rest.
Affected browser
The text was updated successfully, but these errors were encountered: