Autofac Module Scanning for Various Applications

Go To


Let's say you're working on an ASP.NET MVC project and it is layers split up into different projects in a single solution. Each project has autofac modules created to wire up the dependencies. Now, I would like to scan the assemblies and register all of the modules into the container.

I adapted an extension method similar to what was shared here

public static void RegisterAssemblyModules(this ContainerBuilder builder, Assembly 
  var scanningBuilder = new ContainerBuilder();

    .Where(t => typeof(IModule).IsAssignableFrom(t))

  using (var scanningContainer = scanningBuilder.Build())
    foreach (var m in scanningContainer.Resolve<IEnumerable<IModule>>())

My first question, considering that this sample was provided a few years ago, is this still an feasible construct to use with current versions of autofac?

Secondly, the MVC app is dependent on functionality in the other layers which means at times I would need to register types with .InstancePerHttpRequest(). However, I would also like to have the option of referencing them from non web applications and not take a dependency on System.Web. What is the best approach for to register modules that can be used in these different contexts?

2012-04-04 20:34
by cecilphillip
Almost a year ago... but still curious. Did you manage to wire-up your MVC app modules nicely without having to referring mvc and that you still could use them properly in lifetimescope of a http request? I'm having the same situation as you right now. Options are: All module registrations in web prj or module registration in each assembly.. - Magnus Backeus 2013-10-21 09:00
So far I've taken the approach of Modules in each assembly where necessary. Since this post, autofac has included a RegisterAssemblyModules extension method in their core dll. For the projects not referencing any web components, I've been fine registering components as InstancePerDependency() for most general cases. I try to avoid one huge registration in the main project. I find you'll give up a little flexibility that way or can even up with "messier" registration setup - cecilphillip 2013-10-22 14:45
Ok. Good info. Problem is (for my case) when you register Entity Framework DBContexts (I do DDD with several bounded contexts) and want to inject them into repositories, You want them to have lifetimescope as a webrequest. This causes me to reference AutoFac (thats ok), AutoFac MVC intergration (Hmm.. maybe ok) and MVC Web prj (Not OK). The other components in our project I actually have not specified lifetime scope, so they are PerDependency. I actually discovered that I could wired up my DBContext with InstancePerMatchingLifetimeScope("AutofacWebRequest"). I know its an ugly reference - Magnus Backeus 2013-10-24 21:55
... continue: But for me it's not an option to reference web project anywhere in other project. So I will try this solution and you could probably write you own extension method that calls InstancePerMatchingLifetimeScope("AutofacWebRequest") so you are sure the "parent" lifetimescope name will be correct. The problem is when you want to use same autofac modules for registering DBContexts used in a non WebContext... such as a background batch. Then you'll probably need to use MultiTenant (have not looked at that yet) or just have other modules for the batch - Magnus Backeus 2013-10-24 22:04


I would not register the modules in the container. I see no reason to do that.

Here is an alternative.

It uses Activator.CreateInstance to create the modules and register them in the builder.

The same framework also gives you configuration free registration support. Just add an attribute to your services:

public class MyService : IService

And run the builder extension method:

2012-04-05 05:39
by jgauffin
in your link, the RegisterModules method is somewhat more long the lines of what I'd do, but instead of using the built in autofac modules support you're creating your own - cecilphillip 2012-04-05 20:48