.NET 4.7.2 Dependency Injection in WebForms

[johnrutherford]

With the newly released .NET Framework 4.7.2, there is (finally!) built-in support for dependency injection in WebForms applications. https://blogs.msdn.microsoft.com/dotnet/2018/04/30/announcing-the-net-framework-4-7-2/

Is there a plan for updating this package to use this or to create a new version?

Obviously it's trivial to write an implementation of System.IServiceProvider that resolves from an Autofac container, but per-request scopes should be supported.

[johnrutherford]

It looks like I can use Autofac.Owin to create a lifetime scope on each request. Then the IServiceProvider can do something like this to get the current request scope:

HttpContext context = HttpContext.Current;
ILifetimeScope scope = context.GetOwinContext().GetAutofacLifetimeScope();

I'm willing to do a pull request if this is something that's wanted.

[tillig]

I think a PR for something like this would be awesome, but before you start into code, it'd be good to think about some of the requirements. For example...

• Autofac.Extensions.DependencyInjection already contains an AutofacServiceProvider that implements IServiceProvider and supports netstandard1.1 (which is compatible with .NET 4.7.2). Can any of that be reused/referenced?
• For folks doing an upgrade from 4.5 to 4.7.2, does the old way and the new way need to work together? If not, how do we avoid people shooting themselves in the foot? If so, the design needs to consider that.
• It shouldn't require OWIN in the app, but it also should work well with OWIN if it's there. Lots of work has been done to ensure there's no duplicate request lifetime created.
• How does this work with MVC? Web API? How do we avoid duplicate request lifetimes being created?
• Should we make the update in this project?
  • If so, how can we do it without forcing everyone on .NET 4.5 to upgrade their projects to 4.7.2 if they're not ready? (Or do we call this a "breaking change" and do a major version release?)
  • If not, where should the change go? (Not in Autofac.Extensions.DependencyInjection because that isn't tied to web at all and shouldn't be.)

I think the .NET 4.7.2 enhancement is interesting it's just not 100% straightforward where the update for this should go or how it should be implemented. I really haven't had time to think about it. I'd love to hear what an overall design might be before getting code out here. PRs totally welcome, just that we have to support it all once it's put into the product so putting it in the right spot in the right way is pretty important.

[johnrutherford]

Yeah, I definitely wanted to discuss the best approach before I started working on a PR.

I don't think using Autofac.Extensions.DepedencyInjection would be helpful here. We would still need to create the request scope. It's not necessary in ASP.NET Core because the framework creates the request scope.

I personally don't see any reason that the old way and the new way should need to co-exist. Since DI is built-in, constructor injection is now available.

I agree that OWIN should probably not be required. Lots of people using WebForms will not be using OWIN. I think there would need to be separate packages for OWIN and non-OWIN, though. If you tried to do it in one package, you'd have to pull in dependencies for both.

To support WebForms without OWIN there would need to be an HttpModule like this one. I guess that would have to be duplicated unless things were refactored around to put that in a separate package.

I think it would definitely need to be a major version bump or even a completely separate package.

[flookami]

Hi folks, no update on this issue so far ? I found this blog post explaining how to wire Autofac with the new net472 webforms dependency injection system : https://www.natmarchand.fr/aspnet-dependency-injection-net472/

[NatMarchand]

Yup! The article is mine, Would be glade to help/contribute/make the PR.

[dotnetjunkie]

Autofac.Extensions.DependencyInjection already contains an AutofacServiceProvider that implements IServiceProvider and supports netstandard1.1 (which is compatible with .NET 4.7.2). Can any of that be reused/referenced?

No, it can't. The IServiceProvider implementation that ASP.NET Web Forms expects can never return null from its GetService method. Doing so will cause Web Forms to through a NullReferenceException from deep down its call stack.

By requiring the IServiceProvider implementation to always return a value, Web Forms breaks the IServiceProvider contract, which specifies that GetService should return null in case there is no suitable implementation/registration.

This means that AutofacServiceProvider can't be reused as it most likely does adhere to the IServiceProvider contract and will allow null to be returned.

Instead, a specially crafted implementation is required.

[flookami]

Hi, is there anyone currently working or planning to work on that specific implementation ? thanks

[tillig]

To the best of my knowledge this is not being worked on.

[flookami]

To the best of my knowledge this is not being worked on.

Ok :(

May be one day if someone is willing to do the PR, (s)he can take the example of the Unity IoC Webforms adapter implementation here : https://github.com/aspnet/AspNetWebFormsDependencyInjection/tree/master/src/UnityAdapter

[wasabii]

The unity one doesn't seem to even attempt lifetime scopes.

[jrmoreno1]

Anything we can do to get some movement on this?

[tillig]

@jrmoreno1 Write the integration and submit a PR. Comment from earlier talking about how submitters will need to think about the design.

[jrmoreno1]

@tillig : I was thinking more money or time on specific other issues, not doing it from scratch.

[tillig]

Unfortunately, right now the Autofac team is about three people doing everything across core Autofac and the ~20 integration packages in unpaid spare time. Priority ends up going to reviewing pull requests and issues in the core package, followed by issues in more recent and heavily used integrations. I'll admit I personally prioritize things that are interesting to me because if I'm going to give up time on vacation or time with my family to provide folks with free work it's going to be something I think is interesting.

I wish throwing money at the problem was a fix, but it'd need to be enough money for me to quit my day job because the real issue here is time. For a long time we've been asking for maintainers - people to not just throw some code at us but help support the product long term (review PRs, respond to questions, relieve the day to day burdens). We have not been successful in increasing the regular team size.

COVID and world issues have also had a non-zero impact here, with team members having to work more day-job hours and having less and less time to allocate here.

All that boils down to: if you want this feature, you need to write it and submit a PR for it. I personally haven't picked it up because, of all the open issues, this doesn't sound like fun to me; it's not something I'll use in my day job; and there are lots of other features and fixes that demand more immediate attention.

I'm sorry that's how it is, but that's how it is. If we had more regular project members and contributors - not just drive by contributions that add to the existing team's ownership burden, but actually folks that regularly help address issues and support ongoing - we'd be in a better position to provide more stuff to more folks.

[tillig]

This has been open for quite some time, and the availability from the Autofac team has not changed. I also haven't seen any PRs coming in from the community for this. As such, I'm closing the issue. There's no value in just keeping it open indefinitely. If there is a PR that comes in for this, we'll be happy to look at it, but it's not on the radar for the Autofac team.