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
The purpose of WebActivator is to wire things up automatically without the need to make modifications to your project's Global.asax file. You could manually add MvcSiteMapProvider.DI.Composer.Compose(); to your application's startup code if you really wanted to. But when delivering a library via NuGet, it makes sense for the installation to be as complete as possible without affecting the rest of the application.
However, I agree with you that this bootstrapping code should not be a direct dependency of MvcSiteMapProvider.dll, but it would make more sense to create a new bootstrapping DLL that contains the WebActivator.PostApplicationStartMethod attribute and wrap it into a separate NuGet package from MvcSiteMapProvider.Core. That way you could exclude it from your project if you didn't want the dependency.
FYI - In v4.6.13 there is now no longer a direct reference from MvcSiteMapProvider.dll to WebActivator. You can now avoid installing WebActivator by installing the MvcSiteMapProvider.Web and MvcSiteMapProvider.MVCx.Core packages into your project. If you are using the internal DI container, you will need to add the following line to the end of Application_Start() event in Global.asax.
As far as I understand you position it as a feature, but, unfortunately, this is more like a bug.
I think it's a good way when 3rd party solutions don't have references to another 3rd party solution.
We don't use WebActivator in our projects, so we can't use MvcSiteMapProvider library without the modifications to the source code.
I think it would be better to have a separate module that implements WebActivator features into MvcSiteMapProvider.
The text was updated successfully, but these errors were encountered: