This project is read-only.

WebActivator Initialization vs. Global.asax app_start configuration paradigm

May 9, 2013 at 7:04 PM
Personally, I like the direction the MVC team has gone in recent years in regards to any application_start code. Take any of the following for examples:
protected void Application_Start(Object sender, EventArgs e)
    {

        ViewEngineConfig.Configure();

        AreaRegistration.RegisterAllAreas();

        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);

    }
Using WebActivator goes against this practice and also added another dependency to your project. Technically, your SimpleInjectorIntializer class can be re-written to use the above paradigm and then remove the need for WebActivator.

What do you think?
May 9, 2013 at 7:57 PM
I must admit that I myself prefer the use of the Global.asax and Application_Start. I do use the Quick Start package, but copy the need configuration to the Global.asax and uninstall the package afterwards.

The use of the WebActivator however, was chosen because this allowed users to get started with Simple Injector just by pulling in the "Simple Injector MVC Integration Quick Start" NuGet package. That package just contains some references to other NuGet packages and one single content file. Adding a content file is a very safe. It prevents having to use tricky Visual Studio integration, which would be needed when an existing Application_Start was altered. Besides, the addition of one single content file is much easier to grasp for developers, compared to finding out that existing files and code has been altered by some package.

So we went for the safest way that is easiest to explain to developers. If this doesn't suit you (as it doesn't really suit myself either), I advice you to just do what I do: copy that code to the Application_Start and uninstall that package.

Note that that although the Quick Start NuGet package takes a dependency on WebActivator, none of the Simple Injector assemblies in fact have a dependency on WebActivator, so from an architectural perspective there's no problem here. And again, if you don't want to take a dependency on WebActivator, just uninstall the Quick Start NuGet package and you're fine.
May 13, 2013 at 4:54 PM
Edited May 13, 2013 at 4:58 PM
The statement "none of the Simple Injector assemblies in fact have a dependency on WebActivator" seems to be incorrect. I just tried to uninstall WebActivator after uninstalling the Quick Start NuGet package and get the following:

"Unable to uninstall 'WebActivator 1.4.4' because 'SimpleInjector.Integration.Web 2.2.3' depend(s) on it."

The .nuspec clearly has the following dependencies:
<dependencies>
  <dependency id="WebActivator" version="1.4.4" />
  <dependency id="SimpleInjector" version="2.2.3" />
</dependencies>
Using JustDecompile, I can clearly see that there shouldn't be a dependency on WebActivator from the SimpleInjector.Integration.Web.dll assembly.
May 13, 2013 at 7:21 PM
An assembly is not the same as an NuGet package. In fact, the MVC Quick Start Package itself, does not contain an assembly. It contains a reference to three other NuGet packages (two Simple Injector packages and the WebActivator package) and one content file.

Again, none of the dlls (assemblies) provided by Simple Injector reference the WebActivator. To integrate Simple Injector with MVC you don't need the MVC Quick Start package. The Quick Start is really just built to bootstrap everything together. If you don't want to use WebActivator, just deinstall the MVC Quick Start package and use the SimpleInjector.Integration.Web.Mvc NuGet package directly. The assembly in that package depends on SimpleInjector.dll and SimpleInjector.Integration.Web.dll and those are located in the NuGet packages with the same name.

SimpleInjector.Integration.Web.dll however, does not have a dependency on WebActivator. It only takes (besides SimpleInjector.dll) a dependency Microsoft.Web.Infrastructure.dll, which is part of the .NET framework.
Marked as answer by dot_NET_Junkie on 2/26/2014 at 1:31 PM