Define an initialization order of WebActivator.PreApplicationStartMethod classes

Question

I have several WebActivator.PreApplicationStartMethod decorated classes.

One is for Ninject, another class for AwesomeMVC and a third one is for background task scheduler.

The problem is that the scheduler class needs to take advantage of the dependecies, that are resolved by IoC container.

My questions are:

1. Can I have several WebActivator.PreApplicationStartMethod classes?
2. Can I define order, in which they are initialized, so that IoC, being the most important, comes first?
3. Can WebActivator.PreApplicationStartMethod static class instances rely on IoC container to resolve their constructor-defined dependencies?

Answer 1

If you know that PreAppStart method A needs to run after PreAppStart method B, then the only way to achive that is to explicitly add a call to B inside the body of A.

For that strategy to work correctly you should also make sure that your PreAppStart method implementations are indempotent i.e. they can safely be called multiple times. Usually this can be achieved by keeping track of whether the method has already been called in a static boolean variable and not doing anything if that vale is true.

Answer 2

Yes, you can have as many classes as you want which have a WebActivator.PreApplicationStartMethod assembly attribute pointing to them. Many NuGet packages use this technique to enable them to bootstrap into your application without editing Global.asax.

You can define the order too. You can pass a named parameter, Order in the PreApplicationStartMethod call. The WebActivator framework will ensure that the methods are called in the order specified. For example, to make your IoC framework register first, do something like this:

[assembly: WebActivator.PreApplicationStartMethod(typeof(MyApp.App_Start.NinjectWebCommon), "Start", Order=1]
[assembly: WebActivator.PreApplicationStartMethod(typeof(MyApp.App_Start.BGScheduler), "Start", Order=2]

Because WebActivator classes are static classes, I don't see how you can use constructor injection in them. You can however, use the service locator (anti?)-pattern by registering your IoC resolver as Mvc's default service locator, using System.Web.Mvc.DependencyResolver.SetResolver(IDependencyResolver resolver).

I don't particularly want to go into the benefits and drawbacks of the service locator pattern here though!