Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jerome Haltom
    @wasabii
    Multiple modules may independently invoke Populate. Each one of these has a habit of invoking, say, AddOptions as an example. That results in multiple ServiceCollections created, and dumped into the container. So multiple registrations of Options framework.
    Same with Logging. It screws stuff up in my experience. You end up configuring logging in one part of the app, only to have some random Add* call elsewhere call AddLogging a second time and supercede your stuff.
    Jerome Haltom
    @wasabii
    The way to avoid it is to put all MS DI calls in a single call to populate. But you can't do that with modules.
    Stefan Ossendorf
    @StefanOssendorf
    @wasabii Because of that I'm encouring my team to move to use MS DI for registration and autofac only as DI provider. To avoid this s... :-/ Sad but well some stuff is only available for MS DI >_>
    Jerome Haltom
    @wasabii
    I just fixed up the AF integration so you can call Populate multiple times.
    Jerome Haltom
    @wasabii

    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.

    Jerome Haltom
    @wasabii
    Like, ResolvedParameter, except applying to all parameters. Guess I could assemble the set of all interfaces up front, turn them into ResolvedParameters, and add it all to each registration.
    Kasper Toft Andersen
    @toftware
    Disregard that clicked wrong channel
    Rafael Lillo
    @lillo42
    Hi, I'm migration my ASP.NET WebAPI to Autofac/Autofac.WebAPI2 o 5.2.0 and after update I'm getting a ObjectDisposedException for HttpRequestMessage, my application is in NET Framework 4.6.1
    But basically on Activated/Prepering I'm resolver HttpRequestMessage (legacy code :( )
    This problem happen after IAuthenticationFilters are resolved
    This problem occured because of my code or it's a bug on Autofac.WebAPI? Or both? I've open a issue on Github: autofac/Autofac.WebApi#59
    Alex Meyer-Gleaves
    @alexmg
    @lillo42 I have left a comment on the issue.
    Jerome Haltom
    @wasabii
    Heh. Another wacky line in Microsoft.Extensions.Http:
            var registry = (HttpClientMappingRegistry)builder.Services.Single(sd => sd.ServiceType == typeof(HttpClientMappingRegistry)).ImplementationInstance;
            Debug.Assert(registry != null);
    Jerome Haltom
    @wasabii
    I wish Instance was exposed on ProvidedInstanceActivator.
    Rafael Lillo
    @lillo42
    @alexmg is it possible my fix go to Autofac.WebAPI release 5.x ?
    Alex Meyer-Gleaves
    @alexmg
    @lillo42 I assume you mean push the change back to an earlier version? We try to avoid having concurrent versions being updated, and there is a simple workaround in this case, as you can override the registration and mark it as ExternallyOwned until you can upgrade.
    Tiago Ribeiro
    @TrymBeast
    Hey!
    I'm having some issues using Autofac 4.9.2 where the memory consumption goes off the roof and in a dump I see lots and lots of InstanceActivator objects, anyone knows what could cause this? too many resolves?
    Would upgrading Autofac solve this? I see this class doesn't exist anymore.
    Thanks!
    Tiago Ribeiro
    @TrymBeast
    sorry, not InstanceActivator but InstanceLookup
    Vilen
    @xumix
    Hi everyone! Is it possible when resolving a component to get info about the dependent service?
    Smth in the lines of
    .WithParameter(
                           new ResolvedParameter(
                               (pi, ctx) => pi.ParameterType == typeof(IReadonlyRepository),
                               (pi, ctx) => ctx.Parent.Type == typeof(SomeType) ? ctx.Resolve<NonDefaultReadonlyRepository>() : ctx.Resolve<DefaultReadonlyRepository>())
    Vilen
    @xumix
    is this dead?
    Nicholas Blumhardt
    @nblumhardt
    @xumix Stack Overflow reaches a lot more eyes :-)
    Robert Dailey
    @rcdailey
    Nicholas Blumhardt
    @nblumhardt
    @rcdailey :-) .. still a matter of finding someone with time to reply; we're all a bit flat-out right now, sorry
    Robert Dailey
    @rcdailey
    Sure, no pressure. I understand this is all built on volunteer effort :D Just wears me out digging into the Autofac source code to figure out how to implement these corner cases lol
    Robert Dailey
    @rcdailey

    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.

    Travis Illig
    @tillig

    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.

    Blair Conrad
    @blairconrad
    (@tillig, side note: it might be useful to change the room title to indicate that official support is unlikely to be forthcoming, and that it's community-only, if that's the policy. It might take some pressure off.)
    Travis Illig
    @tillig
    @alexmg or maybe @nblumhardt will have to do that; I don't appear to have any sort of rights to change the features of the room.
    Nicholas Blumhardt
    @nblumhardt
    I think the problem is that Stack Overflow is going to be the same; we'll all try to answer wherever/whenever we can :-)
    Robert Dailey
    @rcdailey

    I realized that a singleton registered in a root container will not be able to resolve overrides in a child lifetime scope of an interface also registered at the root, even if the singleton is resolved through a child lifetime scope. But my understanding is this is only useful for lifetimes managed by a scope to begin with. InstancePerDependency isn't auto-disposed by the container, so why can't singletons pull overridden dependencies from a child container?

    Migrating from Unity this is one thing that bit me. I ended up using Multitenant to solve the issue and instead of SingleInstance I use InstancePerTenant. But even that isn't a 100% solution if you switch tenants and expect the same singleton instance between them, AFAIK.

    Wanted to open an SO question for this but this is a low-effort question on purpose.

    Stefan Ossendorf
    @StefanOssendorf
    @rcdailey Isn't every type which imlements IDisposable/IAsyncDisposable auto-disposed by the container as long as you don't tell him you want to own the instance?
    And how should a singleton pull dependencies from a childscope? This would either promote the childscope to rootscope or the singleton would be on childscope level and not root level. What should happen if Singleton A gets a Dependency B from a child scope with B: IDisposable and the child-scope gets disposed?
    Robert Dailey
    @rcdailey

    I don't view this as a singleton pulling dependencies from a child scope because I resolved the singleton through the child scope to begin with. Non-singleton types can already resolve overrides from the container that was used to resolve the original type, so I sort of feel like that should work for singletons too (for ephemeral, non-disposed instances). And even if InstancePerDependency types implement IDisposable, the container/lifetime scope will likely outlive the resolved instance, so why would it keep track of it and dispose it? Either I'm missing something or that doesn't make sense.

    Again I understand why instances must be resolved within the container of the singleton. I did enough reading on that. But I'm assuming InstancePerDependency types are not disposed by the container, since it's very likely the container will outlive them. So I'm hoping that if disposal semantics don't take place, then there's no reason for types to only be resolved in the container that the singleton was registered in (instead, we can use the registrations from the lifetime scope the original Resolve() method was called on like everything else)

    Stefan Ossendorf
    @StefanOssendorf
    Because the container is responsible for disposing IDisposable since he created them unless you tell him not to.
    It probably depends also on the container you are using. For example autofac tracks all disposals until told otherwise.
    Robert Dailey
    @rcdailey
    I'm not able to find any explanation in the docs about InstancePerDependency disposal semantics. I guess to your point: It's implying everything is disposable even those. I am curious though how it handles lifetimes that are shorter than the scope. I'll read over it again and make sure I didn't miss an explanation of that. Thank you for your help Stefan.
    Alistair Evans
    @alistairjevans
    Unless ExternallyOwned, resolved InstancePerDependency instances are tracked, and Dispose is called when the scope the instance resovled from is Disposed.