Can we retire this project in favour of Castle.Facilities.AspNetCore?

[ghost]

We have found a way that avoids "cross wiring" with automated provisioning of framework dependencies.

Please see: castleproject/Windsor@fb79330

• This avoids mutation of lifestyles.
• Avoids "Captive Depedencies" as per: Integration for Microsoft.Extensions.DependencyInjection (ASP.NET Core) castleproject/Windsor#120 (comment)
• Avoids "Torn Lifestyles" as per: Integration for Microsoft.Extensions.DependencyInjection (ASP.NET Core) castleproject/Windsor#120 (comment)

What do you think?

[hikalkan]

Surely, we can retire this one once Castle officially support it :)

[ghost]

Heads up, we have a production ready facility here: castleproject/Windsor#394

I seriously envy you gentleman for going through the pain you have done. You guys were also credited in the docs. What a crazy journey huh?

@generik0 also helped out. Thanks.

[hikalkan]

Thank you @fir3pho3nixx for your great effort and mentioning in the docs :)

[ghost]

Please see: danielpalme/IocPerformance#81

We hope to address this soon.

[andreasohlund]

Is this facility tied to asp.net core?

Reason I ask is that we (NServiceBus) is contemplating to use Microsoft.Extensions.DependencyInjection as our DI abstraction but we can't take a dependency on any AspNet package since our endpoints can be hosted anywhere. Ie we can't rely on middleware etc.

Thoughts?

[hikalkan]

See dependencies:

castle-windsor-ms-adapter/src/Castle.Windsor.MsDependencyInjection/Castle.Windsor.MsDependencyInjection.csproj

Lines 25 to 31 in b24d527

	<ItemGroup>
	<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="2.0.0" />
	<PackageReference Include="Microsoft.Extensions.Options" Version="2.0.0" />
	<PackageReference Include="Castle.Windsor" Version="4.1.0" />
	<PackageReference Include="Castle.Core" Version="4.2.1" />
	<PackageReference Include="SourceLink.Create.CommandLine" Version="2.4.0" PrivateAssets="All" />
	</ItemGroup>

So, it does not depend on any asp.net core package.

[andreasohlund]

Sorry I was unclear, I meant https://github.com/castleproject/Windsor/blob/master/src/Castle.Facilities.AspNetCore/Castle.Facilities.AspNetCore.csproj

Ie that facility can't replace this project since it has a dependency on AspNetCore.

In short: It can't replace this project, at least for my purposes. Would that be correct?

[hikalkan]

Hmmm.. you are correct. Castle.Facilities.AspNetCore should be layered, so the lower layer should not depend on aspnet core.

We will not retire this project without see Castle's official packages does everything this package does, don't worry :)

[andreasohlund]

Great, that was the answer I was looking for

[mbp]

This is the related issue in Castle Windsor, adding more generic support instead of depending on ASP.NET Core: castleproject/Windsor#412

Since there is no progress in that, I wonder if this project will be updated to support Castle Windsor 5?