@alexmg If I'm creating that
MyViewModel via autofac though then the only object that by default knows about that instance of
ILifetimeScope would be the
MyViewModel no? So where else would I dispose of it?
In this specific case I have another object like
MyFirstViewModel which has a call to scope in it to
scope.Resolve<MyViewModel>() but the only way it would know about the scope created for
MyViewModel is if that were then exposed as a property or something of that nature.
scopeyou referred to in
MyFirstViewModela new child lifetime scope? If it is not and
MyViewModelis resolved from the root lifetime scope disposing it would not be a good thing. You might need to provide some more example code so we can better understand your scenario.
Obviously, I'd prefer you to take all my code and incorporate it, instead of maintaining my own version. But I'm doing things quite differently.
We have too many packages already and need to start offloading some if anything. Do you still require the functionality provided in your package? It is quite different and seems like you might be continually fighting battles on multiple fronts.
Any hope of supporting ByRef ctor parameters? Clarity: I mean for 'in' parameters.
Looks like there is already a related issue open for that. #1226
I have a real question. Imagine I have a set of services. They all depend on each other by resolving each other through interfaces. There's a set of HostedServices that go along with them as well.
I want to register this block of services twice. But have each block only resolve from amongst itself. So, two copies of this set of services, that only depend on other services within the same set. Named services are the idea. Except, I want to make the names of the ctor injectors dynamic to the name of the set, also.
Or, register it all twice, in two separate Lifetime Scopes. However, it's not really a lifetime scope. Because there's HostedServices, and those really need to be started by the top-level generic Host.
var registry = (HttpClientMappingRegistry)builder.Services.Single(sd => sd.ServiceType == typeof(HttpClientMappingRegistry)).ImplementationInstance; Debug.Assert(registry != null);
.WithParameter( new ResolvedParameter( (pi, ctx) => pi.ParameterType == typeof(IReadonlyRepository), (pi, ctx) => ctx.Parent.Type == typeof(SomeType) ? ctx.Resolve<NonDefaultReadonlyRepository>() : ctx.Resolve<DefaultReadonlyRepository>())
Is it possible to transitively perform property injection? What I want to do is for every Form instantiated, recursively walk the child tree of Controls and inject properties on the concrete types. My previous solution using Unity was to make every Form and User Control derive from a special class that, in its constructor, would inject properties on itself. The issue with this is that it breaks lifecycle management because everything uses the root container. Sadly also now code has started to depend on properties being injected before/during construction of the object. So I need an elegant, transparent two-phase initialization process for these winforms objects. It's really tough.
As a workaround, I created a
IUserControlPropertyInjector service that I inject in any forms which it uses to inject properties in child UserControl objects. But it's a very manual process and requires me to refactor each class.
I think Stack Overflow has been ineffective in getting help for this, so I'm happy to patiently wait for a helpful response here.
I don't personally come into Gitter, I won't lie. There are too many existing avenues to monitor from Stack Overflow to Twitter to newsgroups to issues and I don't make it in here. I don't see that changing in the future; honestly, I'd just as soon shut the Gitter down to remove the impression that this is super active, but if the community can help the community, awesome.
Windows Forms apps don't have any sort of built-in DI support. There's no "standard way" to handle it, there aren't any "hooks," and I haven't seen any "patterns" [that I'm aware of, anyway]. However you do end up implementing it is going to be app-specific. You're not getting a response from the Autofac folks on Stack Overflow because we don't have an answer for you - the people who need to help you are Windows Forms developers who have implemented DI. Why the Windows Forms audience isn't helping isn't something I can speak to. I'm sorry you didn't get an answer to your question; I'm afraid I don't have an answer, either. I'd recommend doing a bit of Googling on "windows forms di" - it appears there are several forum posts and blog entries that may help, but since I don't develop Windows Forms apps nor is there any specific Autofac support for them... that's the best I can offer.