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
    Thanks.
    Jerome Haltom
    @wasabii
    @alexmg 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.
    Jerome Haltom
    @wasabii
    Oh, and also, I'm actually replacing the WebHost hosting service provider with Autofac, instead of leaving it in MS DI.
    Jerome Haltom
    @wasabii
    Any hope of supporting ByRef ctor parameters?
    Jerome Haltom
    @wasabii
    Clarity: I mean for 'in' parameters.
    Alex Meyer-Gleaves
    @alexmg

    Hey @wasabii

    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

    Jerome Haltom
    @wasabii
    I believe I do require it, yes. It's the only way to get Modules to work right with MS DI.
    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