Castle Windsor Ms Adaptor Core 2.0 Implementation

Question

Could someone expand upon the directions Halil Kalkan (@hikalkan) provided here: https://github.com/volosoft/castle-windsor-ms-adapter

ORIGINAL - works using standard Microsoft DI

public void ConfigureServices(IServiceCollection services)
    {
        services.AddAutoMapper();
        services.AddMvc();
        services.AddApiVersioning();

        services.AddDbContextPool<CIDMSContext>(options => options.UseSqlServer(""));
        services.AddScoped<IBuildingRepository, BuildingRepository>();
        services.AddScoped<IComponentRepository, ComponentRepository>();
    }

NEW - does not work. trying to use Castle.Windsor.MsDependencyInjection

public IServiceProvider ConfigureServices(IServiceCollection services)
    {
        services.AddAutoMapper();
        services.AddMvc();
        services.AddApiVersioning();

        services.AddDbContextPool<CIDMSContext>(options => options.UseSqlServer(""));
        //services.AddScoped<IBuildingRepository, BuildingRepository>();
        //services.AddScoped<IComponentRepository, ComponentRepository>();

        return WindsorRegistrationHelper.CreateServiceProvider(
            new WindsorContainer(), services);
    }

I am getting the error:

Unable to resolve service for type '...Repositories.Buildings.IBuildingRepository' while attempting to activate ...Controllers.BuildingController'

My ultimate goal is to not have to DI every single repository that I ever create. I would like Castle Windsor to DI it by convention. If there are other options to doing this for .Net Core 2.0 then I am open to those options as well.

I am using Visual Studio 15.4.1 .Net Core 2.0 API project.

EDIT: CastleWindsor - ASP.NET Core Facility

Answer 1

I would advise against using such adapter. Creating a good (fully compatible) adapter on top of the new .NET Core DI abstraction has proven to be a far from trivial task for most DI Containers. Some Containers are simply not compatible with the way Microsoft built their DI Container and Castle Windsor is a good example.

The Castle Windsor maintainers have tried for quite some time to build such an adapter, but even after consulting Microsoft about this, Microsoft acknowledged ( copy ) Castle Windsor is incompatible to how MS views the world of containers.

Castle isn't the only container that falls into this category. Contains such as Simple Injector, Ninject, Unity and StructureMap have proven to be incompatible with the new .NET Core DI Abstraction as well. Although StructureMap actually has an adapter, their adapter isn't 100% compatible with the abstraction, which might obviously lead to problems when the ASP.NET Core framework, or a third-party library, starts to depend on that incompatible behavior. And even for other containers with an adapter, like Autofac and LightInject, problems with their adapters seem to keep popping up, which proves (IMO) the the underlying model is flawed.

So at this moment in time there is no compatible adapter for Castle Windsor, and the Castle Windsor maintainers haven't decided yet whether they should or even could adapt.

But the absense of a compatible adapter is not a problem at all . Windsor (and other containers) can quite easily be integrated with ASP.NET Core without the use of an adapter, as fir3pho3nixx stated on the Windsor forum here . In its basics, it's just a few lines of code to get things running.

UPDATE: Windsor has now a Facility (integration package) for ASP.NET Core, the documentation for which can be read here . Note that the Windsor maintainers chose not to create an adapter implementation. The Facility works by keeping the built-in DI system in place instead of replacing it. From a consumer's point of view, however, how the Facility works is not that interesting.