InstancePerRequest 的构造函数注入服务解析新实例

Question

I register a service FooRequest as InstancePerRequest in ASP.NET MVC & OWIN:

builder.RegisterType<FooRequest>().AsSelf().InstancePerRequest();

After that I resolve FooRequest in two locations. First is global.asax Application_BeginRequest():

protected void Application_BeginRequest(object sender, EventArgs e)
{
  var fooRequest = DependencyResolver.Current.GetService<FooRequest>();
}

A second time in another services constructer. The other service has InstancePerLifetimeScope:

public class FooService
{
  public FooService(FooRequest fooRequest)
  {
    ...
  }
}

My problem is that those two resolves in different instances of FooService and the one used in constructor injection of service does not call Dispose[Async] on the end of the request.

What am I doing wrong?

Btw. using DependencyResolver.Current.GetService<FooRequest>() outside the constructor does resolve the proper instance of FooRequest in FooService.

Additional requested information

OWIN & Container configuration:

[assembly: OwinStartup(typeof(Project.Web.Startup))]
namespace Project.Web
{
    public partial class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            var builder = new ContainerBuilder();

            // REGISTER CONTROLLERS SO DEPENDENCIES ARE CONSTRUCTOR INJECTED
            builder.RegisterControllers(typeof(MvcApplication).Assembly);
            builder.RegisterApiControllers(typeof(MvcApplication).Assembly);

            // REGISTER DEPENDENCIES
            builder.RegisterModule(new ProjectWebModule());
            builder.Register(c => new IdentityFactoryOptions<ApplicationUserManager> { DataProtectionProvider = app.GetDataProtectionProvider() });

            // REGISTER FILTERS SO DEPENDENCIES ARE PROPERTY INJECTED
            builder.RegisterFilterProvider();

            // BUILD THE CONTAINER
            var container = builder.Build();

            // REPLACE THE MVC DEPENDENCY RESOLVER WITH AUTOFAC
            DependencyResolver.SetResolver(new AutofacDependencyResolver(container));

            // REPLACE THE WEBAPI DEPENDENCY RESOLVER WITH AUTOFAC
            GlobalConfiguration.Configuration.DependencyResolver = new AutofacWebApiDependencyResolver(container);

            // REGISTER WITH OWIN
            app.UseAutofacMiddleware(container);
            app.UseAutofacMvc();

            app.Use((context, next) =>
            {
                var httpContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);
                httpContext.SetSessionStateBehavior(SessionStateBehavior.Required);
                return next();
            });

            // STANDARD MVC SETUP
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); // immer nach RouteConfig.RegisterRoutes ausführen!
            BundleConfig.RegisterBundles(BundleTable.Bundles);

            // PLACE ConfigureAuth AFTER RegisterGlobalFilters
            ConfigureAuth(app);
        }
    }
}

ProjectWebModule

namespace Project.Web.Autofac
{
    public class ProjectWebModule : Module
    {
        protected override void Load(ContainerBuilder builder)
        {
            builder.RegisterType<FooRequest>().AsSelf().InstancePerRequest();
            builder.RegisterType<FooService>().AsSelf().InstancePerLifetimeScope();

            builder.Register(c => HttpContext.Current.GetOwinContext().Authentication).As<IAuthenticationManager>();
            
            builder.Register(c =>
                                 //register FakeHttpContext when HttpContext is not available
                                 HttpContext.Current != null
                                     ? new HttpContextWrapper(HttpContext.Current) as HttpContextBase
                                     : new FakeHttpContext("~/") as HttpContextBase)
                   .As<HttpContextBase>()
                   .InstancePerLifetimeScope()
                   .OnActivated(e =>
                   {
                       Toolbox.HttpContext = e.Instance;
                   });

            builder.Register(c => c.Resolve<HttpContextBase>().Request)
                .As<HttpRequestBase>()
                .InstancePerLifetimeScope();
            builder.Register(c => c.Resolve<HttpContextBase>().Response)
                .As<HttpResponseBase>()
                .InstancePerLifetimeScope();
            builder.Register(c => c.Resolve<HttpContextBase>().Server)
                .As<HttpServerUtilityBase>()
                .InstancePerLifetimeScope();
            builder.Register(c => c.Resolve<HttpContextBase>().Session)
                .As<HttpSessionStateBase>()
                .InstancePerLifetimeScope();

            base.Load(builder);
        }
    }
}

Answer 1

I mention in the comments on the question that there's not enough info here to really tell, but here's my guess: you have a race condition.

As you know from the Autofac.Mvc.Owin README and the MVC/OWIN integration docs , ASP.NET MVC doesn't actually fully run in the OWIN pipeline. Trying to make the two work creates some weird issues that aren't of Autofac's creation. For example (again, from the Autofac docs):

Minor gotcha: MVC doesn't run 100% in the OWIN pipeline. It still needs HttpContext.Current and some other non-OWIN things. At application startup, when MVC registers routes, it instantiates an IControllerFactory that ends up creating two request lifetime scopes. It only happens during app startup at route registration time, not once requests start getting handled, but it's something to be aware of. This is an artifact of the two pipelines being mangled together. We looked into ways to try working around it but were unable to do so in a clean fashion.

But that also means there's a sort of order around when Application_BeginRequest handlers run that could cause oddness like what you're seeing. For example, the Autofac OWIN MVC integration tries to set up a request lifetime (if it's not already set up) when you put app.UseAutofacMvc() in the pipeline, but the ASP.NET MVC framework also tries to set up a request lifetime internally (using DependencyResolver.Current ), so those things have to work together. It's not entirely impossible that your Application_BeginRequest handler is resolving from a different lifetime scope than what the MVC framework is trying to set up as the request lifetime, for example if the MVC framework hasn't had a chance to set it up before you've tried resolving from it.

I would recommend if you're trying to use OWIN with MVC, give in to OWIN and actually use OWIN middleware in the pipeline rather than event handlers in MVC. It'll remove the race condition for Application_BeginRequest and give you greater control over the order of operations. It'll also get you closer to where ASP.NET Core is so if/when it's time to migrate your application you won't have to deal with the event handlers that aren't there anymore.

Of course, again, this is totally a guess based on what I could gather from the question. Hopefully it helps.

---

Edit after new info was added to question: I think my guess is still correct, but it also looks like you're not setting up OWIN right for WebAPI, which could contribute to the problem. You shouldn't be using GlobalConfiguration . Also, again, MVC doesn't really run in OWIN, so you may see weirdness trying to get two app types (MVC, WebAPI) with two different pipelines to mash together. It's why they unified it in ASP.NET Core.