Make AutofacRegistration.Register public

[InspiringCode]

I have a scenario, where I just need to populate the container with the services from IServiceColletion but do not want to register AutofacServiceProvider and AutofacServiceScopeFactory.

Would it be possible, that you make AutofacRegistration.Register public? Otherwise I will have to resort to calling via reflection which is very ugly.

[tillig]

It's really not intended to be used by itself, it's supposed to be a one-line bridge to allow Autofac to back the IServiceProvider interface. If we were to expose it publicly, that's an extension point we will need to document and support, and answer questions about why folks who just call Register aren't getting the support they think they should be getting in IServiceProvider.

Perhaps you could expand on the use case and we could provide an alternate solution.

[cmeyertons]

I second this!

My primary use case is registering things inside Autofac modules. There is a ton of framework implementations that only provide a way to wire up via MS DI (HttpClientFactory, Logging, etc.). If you new up a ServiceCollection and call builder.Populate, it can have unintended side effects (e.g. in an Azure Function - it wipes away registrations the platform added)

I think the documentation is pretty solid already, the code inside Register is super valuable to bridge a registration from MS DI -> Autofac.

Might want to change the name of Register to something more specific, e.g. RegisterServiceDescriptors.

[tillig]

I'm still sort of torn here, for a couple of reasons:

• I really don't think "register Microsoft format things in an Autofac module" is a use case we really want to support. In general, it's intentional that these things are kept separate and not intermingled. From a support perspective, "how come I tried to register this in this one way and this other thing this other way and there are weird conflicts" is not a set of questions I'm super interested in having to tack on to the existing support question load. Generic hosting provides a nice, easy way to keep these things separate already.
• Having Populate and Register (or RegisterServiceDescriptors or anything else like that) is another support issue waiting to happen. "I didn't read the docs and I wanted to register my service descriptors but things aren't working. Why not?" It violates that sort of "pit of success" API we're trying for.
• I'm not convinced there's just no way to use what's already here. There are community libraries like this one and this one that seem to make Azure Functions integration with Autofac work.

Now, admittedly, I'm not an Azure Functions dev so I could be missing something in that respect. Perhaps being more specific and walking me through exactly what the problem is - with a small code sample (ideally here and not "go troll through this giant repo and ramp up on Azure Functions" because I just don't have time for that) - might help. I'd also be interested to know if either of the aforementioned community libraries might solve the problem for you, and if not, why not.

I'm sorry to sound kind of obtuse here, it's just that "make it public" sounds great if you're not the person who has to answer all the questions and maintain it forever after. We need to really understand why before we go for it.

[tillig]

Given the potential maintenance issues arising from this (e.g., people trying to mix and match Autofac and M.E.DI registrations), I'm going to close this as not planned. Sorry.