Add Ability to Set a global IPropertySelector

[jwyza-pi]

Problem Statement

Currently, based on the documentation as far as I can tell, you can set a IPropertySelector for individual registrations, but you cannot do so globally.

In my use case, I'd like to have a custom IPropertySelector, but I want to apply it to all registrations made unless explicitly overridden. In our case we want to enforce a specific subset of things we allow for property injection globally.

Desired Solution

A mechanism where you can set a custom IPropertySelector in lieu of the DefaultPropertySelector at a global level. This would work for both individual registrations and assembly scanning registrations.

Alternatives You've Considered

• Manually doing it on each registration.
• Just hoping that no one accidentally tries to use it in scenarios where we don't want them to.
• Not using property injection.

Additional Context

None.

[tillig]

A similar StackOverflow question just came through about wanting a global IConstructorSelector setting.

Unfortunately, the team here is small and this is a somewhat niche request, so we need to lean on the community (the folks wanting these features) to contribute the actual design (and possibly a PR) with the feature.

Things to consider in the design:

• How do registration sources work? Registration sources allow folks to dynamically provide registrations into a lifetime scope. How does that work with this setting? How do we enforce that the source(s) know about the setting to use it?
• How do nested lifetime scopes work? If you can override the property selector, does that happen at the lifetime scope level or... where? If you do override it at the scope level, how does that interact with singletons or instance-per-matching-lifetime-scope objects which may have been created and cached using a different property selector?
• Does it affect all registrations or just reflection registrations? You can register delegates, types, provided instances... what happens with those?
• Can I access this value in a resolution pipeline? Object resolution goes through a pipeline. For custom middleware, having the full context of resolution including "global values" is important. How do I access that? Or can I?
• Is there some other pattern here? If we have a global property selector, and there's a request for a global constructor selector, what other things might there be? Is there a way we can look at something like this and find a pattern instead of a one-off setting?
• How do we offer support for that? If someone sets the global property selector somewhere and no one knows where that code is, how do we help people using the code go, "Darn you Autofac guys, this worked great earlier and now my properties aren't getting populated - what did you break?" How do we get people to "know" about the implicitly attached behavior so we don't get a bunch of support questions and can help guide folks to the solution on their own? This includes stuff like "they're using this in an ASP.NET application underneath Microsoft.Extensions.DependencyInjection and now the global behavior has changed and no one understands why.

This isn't everything. It's a few minutes' worth of general brainstorming about challenges with "change global behavior" sorts of features that we need to have answered in the design of such a feature before taking a PR or implementing something like this.

I'm sure if folks spend even more time on it, they might find other things. Like how we might need to verify behavior against decorators and interceptors. Again, there's not a complete list like a checkbox of stuff to think about. We need to rely on the folks who want this (or who are potentially submitting PRs) to be super detail oriented and think that sort of thing through.

I know that's painful, but that's why this isn't already there. If it was just a quick "jam this new property on ContainerBuilder and call it good" thing, that'd be a different story.

[tillig]

Given there's been no feedback on feature design here, I'm closing the issue. If other folks want this feature, please open a new issue but include feature design information like the kind noted above. Given there's a lot to work through, there's not a lot of value in just keeping the issue open forever since no one is working on it.