ContainerBuilder
beachwalker opened this issue · 9 comments
Is your feature request related to a problem? Please describe.
Currently, it is not possible using the AutofacServiceProviderFactory to use a different ContainerBuilder implementation (e.g. use the MultitenantContainer from https://github.com/autofac/Autofac.Multitenant)
Describe the solution you'd like
The construction of the AutofacServiceProviderFactory should allow to delegate the creation of the ContainerBuilder and switch out the implementation.
My proposed changed AutfacServiceProviderFactory (see new Constructor and call in CreateBuilder method):
public class AutofacServiceProviderFactory : IServiceProviderFactory<ContainerBuilder>
{
private readonly Func<ContainerBuilder> createFunc;
private readonly Action<ContainerBuilder> configurationAction;
public AutofacServiceProviderFactory(Action<ContainerBuilder>? configurationAction = null)
: this(() => new ContainerBuilder(), configurationAction)
{
}
public AutofacServiceProviderFactory(Func<ContainerBuilder> createFunc, Action<ContainerBuilder>? configurationAction = null)
{
this.createFunc = createFunc ?? throw new ArgumentNullException(nameof(createFunc));
this.configurationAction = configurationAction ?? (builder => { });
}
public ContainerBuilder CreateBuilder(IServiceCollection services)
{
var builder = this.createFunc();
builder.Populate(services);
this.configurationAction(builder);
return builder;
}
...
}
Describe alternatives you've considered
An alternative is to create an own implementation of the AutofacServiceProviderFactory and use this instead. But I would like to stay with the provided "original" instead.
Additional context
I created a repository with that change and create a pull-request for this issue.
Is your problem specific to wanting to use the MultitenantContainer? Because we have the existing ASP.NET Core Multitenant Integration for that.
Is your problem specific to wanting to use the MultitenantContainer? Because we have the existing ASP.NET Core Multitenant Integration for that.
It is currently specific to the MultitenantContainer but I don't use ASP.NET Core. I use Net Core 3.1 with WPF and built using the Generic Host. So I can't rely on HttpContext for example.
There's a multitenant-aware IServiceProviderFactory in that package that you can use, even if you don't use ASP.NET Core.
There's a multitenant-aware
IServiceProviderFactoryin that package that you can use, even if you don't use ASP.NET Core.
There is a dependency to ASP.NET Core App. Should rely on Generic Host.
Does this make it literally unusable or is it just a dislike? There are some ASP.NET Core specific things in there. That particular factory does not require ASP.NET Core. We won't be modifying the existing factory in this assembly, and there's already a factory that works with multitenancy and should do what you need.
Please try it. If it works, awesome. If it doesn't work, we need more information about exactly what isn't working - a build error, an exception being thrown, etc.
literally not extensible. I modified it in a way that it is open for extension. Currently, it is not possible to change anything there. Copy and paste wasteland is the result then just to change behavior that is hard coded in one line. I think, forks should be made to improve the original and give feedback, not to roll out own versions everywhere... nightmare of keeping everything in sync and working. Anyway, stay with the unchangeable version then. But I don't integrate unnecessary dependencies.
Please try it. If it works, awesome. If it doesn't work, we need more information about exactly what isn't working - a build error, an exception being thrown, etc.
It is not an exception. I just need a custom builder. I have to copy some classes instead of just to change it. That simple. Nice, that a library for DI is working against it at some point here.
OK, let's step back and level set a little here.
Every feature we add, however small, is something the Autofac team has to support for years. That means, among other things - documentation, fixing bugs, answering questions on Stack Overflow, answering questions on the forums, answering questions on Gitter, making examples showing the feature in action, updating the examples as .NET/.NET Core updates, and having a plan to obsolete the feature over the course of years if it turns out it's not something we can support or something that has bugs in it. this is for core Autofac and the something-like-25 integration libraries, including this one.
There are only three or four people who are really full Autofac owners and work consistently on the product. Until reasonably recently, it was just two. We are all entirely unpaid, none of us work for Microsoft, this isn't part of our job. You get the product, discussions on issues, fixes, releases, new features, the whole bit - entirely out of personal free time. Time folks aren't spending with their kids, with their families, or doing other hobbies.
At this precise moment in time, the whole world has a heightened sense of anxiety due to disease and quarantine. I don't know about you, but I'm now not only doing my job but also trying to home school my nine year old; providing tech support to the teachers in my area; worrying about my wife on the front lines at the local VA hospital; worrying about my dad with compromised lung issues; and coping with people I know that have contracted the disease. I'm lucky, I don't personally know anyone who's died from it. Yet.
So there's a lot to consider here, both at the project and the personal level.
I recognize you have a need, however you haven't actually explained what you're doing. You've explained the end goal you want, but you haven't spent any time walking us through the use case.
My boss uses a great analogy: A customer walks into a mobile phone store and asks the salesperson for a larger antenna for their phone. The salesperson tries to ask questions about the request - certainly, selling the person an antenna is easy enough, right? - and it turns out the person wants the antenna because calls are getting dropped. "Ah," says the salesperson, "you don't need a bigger antenna, you want better reception."
There's a difference between specifying the requirements and specifying the solution up front. Perhaps the solution you've presented is valuable and is something we can take in. Awesome.
However, you haven't actually explained the requirements very well. "I need a custom container builder." Why? This is an exceptionally uncommon use case. Like, if that means you've derived your own class from ContainerBuilder, you're literally the only person I've ever heard of doing that [and it makes me think we should make ContainerBuilder sealed to stop that sort of thing and force extension methods]. We need to know more about that.
We have an extension point where you can pass in an action to run on the ContainerBuilder. Why isn't that enough? Again, that hasn't been explained.
When asked about the use case, you mentioned:
It is currently specific to the MultitenantContainer but I don't use ASP.NET Core.
We have a solution for the multitenant container already. The factory itself doesn't require ASP.NET Core, so it should work fine. Have you tried it? Did it not work? We don't know. You haven't explained it.
So, please be patient with us and understand that there are real people here trying to help you for free, own this for free, support this for free. If we're going to take on a new feature with the support burden it entails, however small you may feel that is, we need to know why.
Ideally, show a small bit of code illustrating what you're doing. It well could be that you could change the way you're doing things and use an existing feature. And, if not, hopefully the sample will make clear why you're asking for what you're asking for.
Hmm, think you're the only one in this situation? don't know how this brings this project a single step further...
Anyway, like you I have a lot to do and just tried to support with a "fix/patch" to solve issue - so it is not only helping me but also helping you. Because I wanted to share the problems that I faced with the current implementation. The problem seems obvious to me in the moment you need "little" customization - you are stuck with the current class. Sorry, if my explanation it is not enough.
But I decide to go on with own implementation (like many others who used the extensions if you look at stackoverflow).
Autofac itself has enough extension points (for the things I did so far) and I just miss them in the other libraries here.
There is no upvote/downvote here for the issue - if this is due to that there is no interest or others switched already to own implementations and do not spend not much interest here anymore is then your part of the story.
Anyway, thanks for the support and stay healthy.