Support for ASP.NET Core 3.0

[robertmircea]

What is the recommended way to use Castle Windsor with asp.net core 3.0? One place where it can integrated would be the generic host towards which asp.net core 3.0 migrated, probably using UseServiceProviderFactory

Using Castle.AspnetCore.Facility is no longer possible (or at least I didn't found out how) because Startup.ConfigureServices returning IServiceProvider is no longer supported by the framework and AddWindsor cannot be used anymore. Before I used to write something like this in Startup class

public IServiceProvider ConfigureServices(IServiceCollection services)
{
    container.AddFacility<AspNetCoreFacility>(f => f.CrossWiresInto(services));
[...]
    return services.AddWindsor(container, 
        opts =>
         {
            opts.RegisterControllers(typeof(MyController).Assembly, LifestyleType.Transient);
         });
}

[jonorossi]

Probably worth getting together with @schwarzie2478 in #487.

[tasoss]

I have the same problem.
I just don't understand if there's going to be a solution soon.
Can you please let me know?
Thanks!

[robertmircea]

As it seems it looks like a dead subject unfortunately since I don't think that AspNetCoreFacility has any active maintainers.

I've managed to make it work in a .net core 3.0 app by insourcing in my project some of the classes from ASP.NET Core Facility and modifying and eliminating some stuff which I did not need like Tag helpers support whose public APIs changed in the new .net core release. The code was in WindsorRegistrationHelpers.AddApplicationComponentsToWindsor called by extension method named AddWindsor. My app is providing only web apis so fortunately I needed to register only controllers with Windsor.

[jonorossi]

since I don't think that AspNetCoreFacility has any active maintainers.

@robertmircea correct, no active maintainers as I said in #487.

[tasoss]

Thank you for the information

[River39]

I was gone use Windsor in my core 3 application until i found this. Has any progress been made on this issue? Or are there alternative solutions to integrate windosr in core 3?

[dotnetjunkie]

Here are some issues that were filed with Microsoft that concern integrating Simple Injector with ASP.NET Core 3:

• Microsoft.Extensions.Hosting.Host creates hosted services too early
• How to integrate non-conforming containers with Razor Components?
• Signalr internal types should continue to remain public in 3.0 until alternative pipeline is created in release 5. This is a breaking change from 2.2

I'm pinging you about this, because it might have impact on integrating Castle Windsor with ASP.NET Core 3 as well.

[chrisheil]

If I am reading the comments in this issue correctly, there is no official support for ASP.NET Core 3.0, and no plans to add support in the future. Is that correct?

[jonorossi]

@chrisheil Windsor today does not have first party support for ASP.NET Core 3.0, correct.

It isn't that there are no plans to add support in the future, it is just that no one has contributed it yet. Both @stakx and myself are the only active contributors to all Castle projects, we are individual contributors like most contributors have been over a long time, we are not being paid for work on Castle. Unfortunately without a contributor that is interested in both Windsor and ASP.NET Core stepping up it just isn't going to magically happen, there have been a bunch of people that have shown interest, and I've offered to review designs and code, but there has been no movement.

[marcelNgan]

As it seems it looks like a dead subject unfortunately since I don't think that AspNetCoreFacility has any active maintainers.

I've managed to make it work in a .net core 3.0 app by insourcing in my project some of the classes from ASP.NET Core Facility and modifying and eliminating some stuff which I did not need like Tag helpers support whose public APIs changed in the new .net core release. The code was in WindsorRegistrationHelpers.AddApplicationComponentsToWindsor called by extension method named AddWindsor. My app is providing only web apis so fortunately I needed to register only controllers with Windsor.

Hi @robertmircea , also trying to use Windsor here with ASP.Net Core 3.0 after using Windsor for a few years with .Net Framework. It's my first project with Core so I'm a bit confused here as well. I'm only trying to use my app for WebApis so potentially this might still work? Any chance you can offer some guidance of what you are doing?

[chrisheil]

@jonorossi Thank you for the response. I appreciate the effort your and everyone else has put into this project, and understand the situation. Would it be possible to add this disclaimer to the AspNetCore documentation to make this a little more clear to anyone else looking for this information? There is a page demonstrating how to set up in an asp.net core 2.0 environment which led to a ton of wasted time trying (and failing) before reaching this conclusion. I could create a PR for this update as well if you would prefer

@marcelNgan I have a workaround that is a little flawed, but is "workable"

Take a look at Volosoft's adapter. In your Program.cs file add the following lines

return Host.CreateDefaultBuilder(args)
    .UseServiceProviderFactory(new WindsorServiceProviderFactory())
    .ConfigureContainer<WindsorContainer>((hostBuilderContext, windsorContainer) =>
        {
            windsorContainer.Kernel.Resolver.AddSubResolver(new CollectionResolver(windsorContainer.Kernel, true));
            windsorContainer.AddFacility<TypedFactoryFacility>();
            windsorContainer.Install(
                FromAssembly.InThisApplication(typeof(Program).Assembly),
                FromAssembly.Instance(typeof(SomeOtherClassInAnotherAssembly).Assembly)
            );
        })

This seems to be working on my initial tests. The weird behavior I noticed is the same as described in this pull request where the adapter isn't properly disposing when trying to Ctrl+C out of "dotnet run" in a terminal.

The project itself was proposed to be included in Castle Winsdor itself, but I wasn't able to find documentation to see how the new version is working. The Volosoft project also does not look to be actively maintained anymore, which is also risky.

[jonorossi]

@chrisheil happy to accept a PR to add a disclaimer to the docs that the current facility does not work with ASP.NET Core 3.0.

[dquist]

Fellas this is an interesting topic!

In my scenario I am working a greenfield WPF project and was looking to leverage some of the new hosting features offered in .net core, specifically the configuration and logging management. However I wanted to stick with Windsor as an IoC container because of how capable it is.

I came up with a solution that I realize may not be the most orthodox, but it seems to do the trick. Basically I use the HostBuilder to to bootstrap a hosted service that contains the Windsor application. I then created a sub-resolver for Windsor that will cross-wire all the Microsoft provided loggers to the Windsor application. This way I can get the best of both worlds, my Windsor IoC container and all the logging goodies.

Here's my Windsor application implemented as a hosted service. The ILoggerFactory dependency is resolved by the .net DI container and is used to cross-wire the ILogger instances.

public sealed class HostedWindsorApplication : IHostedService, IDisposable
{
    private readonly IServiceProvider _serviceProvider;
    private readonly IWindsorContainer _container;

    public HostedWindsorApplication(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider ?? throw new ArgumentNullException(nameof(serviceProvider));
        _container = new WindsorContainer();
    }

    public Task StartAsync(CancellationToken cancellationToken)
    {
        // Use sub-resolver to cross-wire ILogger instances
        _container.Kernel.Resolver.AddSubResolver(new LoggerResolver(_serviceProvider));

        _container.Install(new CoreInstaller());
        var app = _container.Resolve<IMyApplication>();
        return app.Run();
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {
        return Task.CompletedTask;
    }

    public void Dispose()
    {
        _container?.Dispose();
    }
}

Then my App.xaml.cs

public sealed partial class App
{
    private IHost? _host;

    protected override async void OnStartup(StartupEventArgs e)
    {
        _host = new HostBuilder()
            .ConfigureHostConfiguration(c =>
            {
                c.SetBasePath(Directory.GetCurrentDirectory());
                c.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
                c.AddCommandLine(e.Args);
            })
            .ConfigureServices((context, services) =>
            {
                // Use the built-in DI to bootstrap the windsor application
                services.AddHostedService<HostedWindsorApplication>();
            })
            .ConfigureLogging((context, builder) =>
            {
                builder
                    .ClearProviders()
                    .AddConfiguration(context.Configuration)
                    .SetMinimumLevel(LogLevel.Trace)
                    .AddNLog("NLog.config")
                    .AddSentry(o =>
                    {
                        o.ConfigureScope(s => s.SetTag("RootScope", "sent with all events"));
                    });
            })
            .Build();
        await _host.StartAsync().ConfigureAwait(false);
    }

    protected override async void OnExit(ExitEventArgs e)
    {
        using (_host)
        {
            await _host.StopAsync(TimeSpan.FromSeconds(5)).ConfigureAwait(false);
        }
    }
}

And finally my sub-resolver to cross-wire the ILogger instances. To handle this I provide the resolver with the IServiceProvider instance and use ActivatorUtilities to instantiate the type. It uses MakeGenericType to specialize the ILogger instance to the resolving type, since the loggers categories are often set through a generic.

public class LoggerResolver : ISubDependencyResolver
{
    private readonly IServiceProvider _serviceProvider;

    public LoggerResolver(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider ?? throw new ArgumentNullException(nameof(serviceProvider));
    }

    public bool CanResolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
    {
        return typeof(ILogger).IsAssignableFrom(dependency.TargetType);
    }

    public object Resolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
    {
        // Create a generic logger using the resolving type.
        // This will work whether a ILogger<Type> or plain ILogger instance is resolved.
        var genericLoggerType = typeof(Logger<>).MakeGenericType(context.Handler.ComponentModel.Implementation);
        return ActivatorUtilities.CreateInstance(_serviceProvider, genericLoggerType);
    }
}

That's what I've got working right now for my WPF application. I've only hammered it out in the past couple days so it's probably still a bit rough around the edges but it seems to be doing the trick.

Edit: It looks like my LoggerResolver is very similar to the LoggerDependencyResolver that's part of the AspNetCore Facility, however that one will only resolve pure ILogger instances, not ones specialized to a specific type.

Edit 2: After reading many of the old 2016 discussions between David Fowler and @dotnetjunkie, it looks my my approach of having two separate contains is actually the recommended approach for non-conforming containers. I guess I'm not crazy after all.

[generik0]

Hi All.

I helped @Fir3pho3nixx with the original aspnetcore2.x implementation (@Fir3pho3nixx did most of the work, this was the way he wanted it).

Does anyone know yet, if we are in a start, to make a 3.x facility for AspNetCore. I will be needing something because EF Core 3.x requires netapp3.x
I can start up in march on looking at this again.

Before that, is anyone interested in grouping up with me, and figuring this out?
We also need a solution for the generic host.

[rvdginste]

@dotnetjunkie

From: dotnet/aspnetcore#14585

During my research I found a way to circumvent the behavioral difference between
Host and WebHost in a way that doesn't require the use of IServiceProviderFactory.

Can you tell something more about that?

@generik0

Do you still plan on working on this?

[generik0]

Hi @rvdginste.
Yes, thanks. I want to give it a shot. I worked a bit with Gavin on the aspnetcore 2 facility, where we stole @dotnetjunkie 's idea about cross registering, so I hope I can work it out.

I am a little worried that nobody else has come forward with intentions for assistance, makes me a little worried that the facility is not needed.

But please, and links/advice you have are more than welcome!!!

[dotnetjunkie]

@rvdginste,

Let me first summarize the problem with ASP.NET Core 3:

ASP.NET Core 3.0's new Microsoft.Extensions.Hosting.Host creates hosted services between Startup's ConfigureServices and Configure methods, where the 'old' Microsoft.AspNetCore.WebHost creates the hosted services only after the Configure method has run. This behavior difference between Microsoft.AspNetCore.WebHost and Microsoft.Extensions.Hosting.Host is significant, because it disallows users of non-conforming containers (like Simple Injector, Castle Windsor, and Ninject) to resolve hosted services from their container, because the configuration of those containers needs to be finished in the Startup.Configure phase, while resolving hosted services from that container before that configuration is finished, can lead to problems. Simple Injector, for instance, blocks any registrations made after the first resolve (which will be a resolve for MyHostedService if you assume the hosted service to be added using p => container.GetInstance<MyHostedService>()). But even if the container doesn't block registrations, the early request for hosted services can cause trouble, because the hosted service's dependencies might not be registered at that point.

The way we were able to circumvent this problem is by adding an ContainerLocking event to the container that signals when the container is about to get locked. This happens, for instance, when the first call to GetInstance is being made, but just before the instance is being resolved and before the container is being locked. The ASP.NET Core integration packages hook onto that event in order to do their last-minute registrations. This works around the problem because all registrations need to (obviously) be done before the container gets locked (which is when the first service is being requested), the first resolve might happen between ConfigureServices and Configure in the case of the new Host, while it would always happen after Configure in the old model.

Perhaps unsurprisingly, but this change was a time-consuming endeavor. We needed a lot of discussions, developing, testing, and documenting to get this fix out the door.

[generik0]

@dotnetjunkie I like your point in dotnet/aspnetcore#14585 (comment).

Personally, I wish you had kept on the discussion with @davidfowl regarding the IServiceProviderFactory and aspnetcore3.0 issues with non-conforming DI. I would have loved to give you any backing I could (but I doubt you needed).

My thoughts are, once again, if we want the aspnetcore facility to work in Windsor, we need to look to simple injector for guidance.

[rvdginste]

@dotnetjunkie Thank you for the explanation!

@generik0 I am willing to help in whatever way I can, but personally I am only interested in support for controllers. So I made a test project that includes the existing facility code to see how the current facility works (using asp.net core 3 with the old WebHost), but I threw out the code related to TagHelpers and ViewComponents.

[davidfowl]

I think this is the cleanest way to plug in both a conforming and non-conforming container into the system:
dotnet/aspnetcore#14585 (comment)

It's a way to give you a a chance to create your own builder (whatever that may be) and it gives you a chance to return a service provider (it a clean way to plug into the lifecycle of the system).

[generik0]

@rvdginste that sounds great! can you share it in e github repo?

[dquist]

Can confirm that using @davidfowl's approach works. I've successfully used this approach with
https://github.com/volosoft/castle-windsor-ms-adapter

to 'cross-wire' the DI registrations.

It is sightly unintuitive because the services registered in ConfigureServices aren't actually registered with Windsor - they're registered to the IServiceCollection and then re-registered with Windsor afterwards, but it is doable.

[robsonj]

We have a large suite of code that utilizes Castle.Windsor. We looking to move our web framework over from being NancyFx based to ASP.Net Core. I'm wondering if it makes sense to start this with the WebHost still given the issues I've read through above? It's not completely clear to me (due to my nativity with ASP.Net Core) if there is any way to bridge the gap between asp.net core and Castle.Windsor yet? We're using Castle.Windsor v5.0.1

[chrisheil]

@robsonj I made a similar migration last year, only the added joy of going from WCF to asp.net core endpoints. The suggestions above are working just fine for us now, we have not encountered any issues yet related to Castle.Windsor on dotnet core 3.

Outside of figuring out the appropriate Lifestyles of course

[robsonj]

@robsonj I made a similar migration last year, only the added joy of going from WCF to asp.net core endpoints. The suggestions above are working just fine for us now, we have not encountered any issues yet related to Castle.Windsor on dotnet core 3.

Outside of figuring out the appropriate Lifestyles of course

My confusion was with regard to which solution to utilize from the conversation above, looks like a couple of solutions in this thread, along with some other referenced solutions for other DI frameworks, so I wasn’t sure which way to go. I’m new to asp.net core , so pardon my ignorance etc

[chrisheil]

@robsonj I would recommend trying the solution dquist provided here first

If that does not work for you, I can verify my solution is usable for now, but with the issue I linked to above.

[robsonj]

@robsonj I would recommend trying the solution dquist provided here first

If that does not work for you, I can verify my solution is usable for now, but with the issue I linked to above.

Thank you, I’ll give it a shot, thanks for the help!

[robsonj]

Ok, got a bit further. I followed the example above, but I was expecting the Microsoft.Extensions.Logging.ILogger<> dependency in my Razor page .cs (Index.chtml.cs) to result in a call on the LoggerResolver CanResolve() being invoke to determine its actual implementation, that doesn't seem to be the case though? I also tried having the Razor page depend on the Castle ILogger, but that just results in a runtime error.

I'm I doing something wrong, or are my expectations incorrect?

Cheers
Jonathan

PS Let me know if this is the wrong place to be asking these questions.

[dquist]

@robsonj My initial implementation above is pretty rough and I wouldn't recommend it. It uses two separate containers, the Microsoft provided one and Windsor. The sub-resolver allows the Windsor container to resolve instances from the Microsoft container, but not the other way around. That's the biggest drawback is that you have to depend on the Windsor container itself.

I ended up using the https://github.com/volosoft/castle-windsor-ms-adapter project which works well enough and follows Microsofts design for an ASP.NET Core container.

Hope that helps.

[jonorossi]

I also just remembered that Castle.Windsor.MsDependencyInjection would conflict with the existing volosoft package with the same name.

[ltines]

@generik0 i'll move the code as PR here (once i figure out how to do it)

@jonorossi @robsonj
Castle.Windsor.MsDependencyInjection would be beautfiul. So i still think the closest is Castle.Windsor.Extensions.MsDependencyInjection. It's an extension to .NET Core

[generik0]

@ltines that's perfect! Let me know when you have a pre-release or something ready. FYI, The castle project builds a little funny (to a build folder), so from what I remember your dll/nugets land there (just a hint).

Regarding name. I vote for "Castle.Windsor.Extensions.DependencyInjection", Don't like the MS prefix, as you will need to change the name if MS changed the name of there repo, (or gave the whole .net core away to a foundation, like Oracle did for apache)... Thats just my thoughts. Do as you feel best @ltines

Either way, looks like I can just sit back and play the tester in a bit, and that is nerver a bad role :-).
Let me know when you have a fork ready with the code please @ltines.

Looking forward to hearing more. Great work everyone. Great work @ltines :-)

[ltines]

Any update guys?

[jonorossi]

Any update guys?

Sorry for not getting to this yet, been busy but will make time on Sunday.

[robertmircea]

In which state is the nuget package? Was it published?

[jonorossi]

I was last to comment on #517 10 days ago, not sure where @ltines is at.

[jonorossi]

Published v5.1.0-beta001:
https://www.nuget.org/packages/Castle.Windsor.Extensions.DependencyInjection/

Please log any problems in new issues.

Thanks everyone.

[robsonj]

5.1.0-beta001 working fine for me. Is there any thought on an approximate release timeframe, i.e 1week, 1month, 1quarter away?

[generik0]

I have a rather large aspnetcore project with many integrations (e.g. including node services). I would like to try the beta.
Just need a little time to get time and do a update prototype...

Has anyone tested the EF Core integration security integration with the package?

[chrisheil]

Great work! Thank you all for putting in the hard work to get this added.

One question, what would the proper setup be for this update? The documentation still mentions using the old Castle.Facilities.AspNetCore package

[generik0]

@chrisheil please look here:

https://github.com/castleproject/Windsor/blob/master/docs/net-dependency-extension.md

@ltines did a great job. The aspnetcore facility has been improved with the net dependence extension for dotnet+

[jonorossi]

5.1.0-beta001 working fine for me. Is there any thought on an approximate release timeframe, i.e 1week, 1month, 1quarter away?

@robsonj All depends on when you all are happy for it to go out after bugs are ironed out. So the more use now will likely speed up people's confidence.

One question, what would the proper setup be for this update? The documentation still mentions using the old Castle.Facilities.AspNetCore package

@chrisheil @generik0 I've just edited the warning on the old ASP.NET Core 2.x facility page. Feel free to send pull requests to improve the documentation.

[chrisheil]

@generik0 That did the trick, thank you.

I have been running this in our test servers for a couple days and experiencing no issues. I did have to find a workaround for replacing the Volosoft MsScopedLifestyleManager with ScopedToNetServiceScope on one of my registrations. In case anyone else runs into a similar problem here's how I worked around it.

Original code:

container.Register(Classes
    .FromAssemblyContaining<IFoo>()
    .BasedOn<IFoo>()
    .WithServiceBase()
    .LifestyleCustom<MsScopedLifestyleManager>()); // From the Volosoft nuget package

Updated code

container.Register(Classes
    .FromAssemblyContaining<IFoo>()
    .BasedOn<IFoo>()
    .WithServiceBase() // <== Cannot use ".Lifestyle.ScopedToNetServiceScope()"
    .Configure(component => component.LifeStyle.ScopedToNetServiceScope()));

[robertmircea]

I am trying to inject IHttpClientFactory as a constructor parameter to one of my classes and I receive the following exception when using Castle.Windsor.Extensions.DependencyInjection

DefaultHttpClientFactory is an internal class which is registered by Microsoft for supporting IHttpClientFactory.

Previously, I was using Volosoft with no issues.

Any idea on how to solve this?

Castle.MicroKernel.ComponentNotFoundException: No component for supporting the service Microsoft.Extensions.Http.DefaultHttpClientFactory was found
   at Castle.MicroKernel.DefaultKernel.Castle.MicroKernel.IKernelInternal.Resolve(Type service, Arguments arguments, IReleasePolicy policy, Boolean ignoreParentContext)
   at Castle.MicroKernel.DefaultKernel.Resolve(Type service, Arguments arguments)
   at Castle.Windsor.WindsorContainer.Resolve(Type service)
   at Castle.Windsor.Extensions.DependencyInjection.WindsorScopedServiceProvider.ResolveInstanceOrNull(Type serviceType, Boolean isOptional)
   at Castle.Windsor.Extensions.DependencyInjection.WindsorScopedServiceProvider.GetRequiredService(Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
   at Microsoft.Extensions.DependencyInjection.HttpClientFactoryServiceCollectionExtensions.<>c.<AddHttpClient>b__0_0(IServiceProvider serviceProvider)
   at Castle.Windsor.Extensions.DependencyInjection.RegistrationAdapter.<>c__DisplayClass4_0`1.<UsingFactoryMethod>b__0(IKernel kernel)
   at Castle.MicroKernel.Registration.ComponentRegistration`1.<>c__DisplayClass84_0`1.<UsingFactoryMethod>b__0(IKernel k, ComponentModel m, CreationContext c)
   at Castle.MicroKernel.ComponentActivator.FactoryMethodActivator`1.Instantiate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)
   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.ScopedLifestyleManager.<>n__0(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.ScopedLifestyleManager.<>c__DisplayClass4_0.<Resolve>b__0(Action`1 afterCreated)
   at Castle.Windsor.Extensions.DependencyInjection.Scope.ExtensionContainerScope.GetCachedInstance(ComponentModel model, ScopedInstanceActivationCallback createInstance)
   at Castle.MicroKernel.Lifestyle.ScopedLifestyleManager.Resolve(CreationContext context, IReleasePolicy releasePolicy)
   at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden)
   at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context, Boolean instanceRequired)
   at Castle.MicroKernel.Handlers.AbstractHandler.Resolve(CreationContext context)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernelByType(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernel(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.TryResolveCore(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency, Object& value)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.Resolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.CreateConstructorArguments(ConstructorCandidate constructor, CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.Instantiate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)
   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.SingletonLifestyleManager.Resolve(CreationContext context, IReleasePolicy releasePolicy)
   at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden)
   at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context, Boolean instanceRequired)
   at Castle.MicroKernel.Handlers.AbstractHandler.Resolve(CreationContext context)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernelByType(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernel(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.TryResolveCore(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency, Object& value)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.Resolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.CreateConstructorArguments(ConstructorCandidate constructor, CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.Instantiate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)
   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.SingletonLifestyleManager.Resolve(CreationContext context, IReleasePolicy releasePolicy)
   at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden)
   at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context, Boolean instanceRequired)
   at Castle.MicroKernel.Handlers.AbstractHandler.Resolve(CreationContext context)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernelByType(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernel(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.TryResolveCore(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency, Object& value)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.Resolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.CreateConstructorArguments(ConstructorCandidate constructor, CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.Instantiate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)
   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.SingletonLifestyleManager.Resolve(CreationContext context, IReleasePolicy releasePolicy)
   at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden)
   at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context

[generik0]

Hi @robertmircea
Did you register it?

[robertmircea]

I didn't have to register it when using Volosoft's adapter. DefaultHttpClientFactory was automatically registered when calling services.AddHttpClient() in Startup.cs to register my http clients. However, after switching to Castle.Windsor.Extensions.DependencyInjection, the same code (no modifications) no longer works.

[generik0]

I see, so you have services.AddHttpClient() which should register it, but just using the castle container.
Did you use the other package with net core 3 also? Because it might be changes in net core 3?

Maybe the default factory needs to be registered first with “IncludeNonPublicTypes”?

Maybe find the code for the default factory aspnetcore lib? Also check what the “AddHttpClient” is doing in the github repo, and try doing it yourself with castle registrations?

[robsonj]

I was wondering what the current thoughts are on non beta Castle release to include this feature?

[jonorossi]

@robsonj there are a couple of new issues open, no idea if they are blockers.

[generik0]

Hi @ltines @jonorossi , this might be a stupid question. But the "WebHost" does not allow the extension to register castle Windsor as the service provider- only "Host".
Any thoughts? Shouldn't there be an extension to WebHost?

I know it is "Web Host, which remains available only for backward compatibility"

@ltines ie:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/web-host?view=aspnetcore-3.1

[jonorossi]

@generik0 It is best to create new issues to track things since this is already closed and released (as a beta).

[rmszc81]

hello everyone,
is there any date for release the final version of this component? for now it's still in beta, :(
thanks!

[generik0]

Hi @rmszc81 have you been using the Beta?
We are almost through the issues We know about, but still need more beta testers to make sure all configurations are Working

[rmszc81]

Yeah, I have been using the beta and it's working fine for me, so, in short:

it's an asp.net core 3.1 web api application, including:

• automapper
• serilog
• castle dynamic proxy,
• castle windsor (obviously)

injections are mostly done by constructors, a few by properties.

no known issues, it's running properly and performance is good too.

[chrisheil]

@generik0 We upgraded our application the day the beta came out, and have been cleared in QA and UAT after several months of testing. In fact, this beta resolved some issues we had faced with the workarounds we had introduced with the earlier solutions before the beta

We are running on asp.netcore 3.0 web api with the following:

• automapper
• castle dynamic proxy
• graylog
• Entity Framework Core 2.2
• FluentValidation

We are also upgrading another product to use this beta with similar dependencies, and early signs are positive

[generik0]

Good news @chrisheil. Thanks!!!!