Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ghost opened this issue Jan 27, 2018 · 10 comments
Open

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

ghost opened this issue Jan 27, 2018 · 10 comments

Comments

@ghost
Copy link

ghost commented Jan 27, 2018

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

Please see: castleproject/Windsor@fb79330

What do you think?

@ghost ghost changed the title Can we retire this project in favour of https://github.com/castleproject/Windsor/pull/376? Can we retire this project in favour of Castle.Facilities.AspNetCore? Feb 19, 2018
@hikalkan
Copy link
Member

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

@ghost
Copy link
Author

ghost commented Apr 18, 2018

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
Copy link
Member

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

@ghost
Copy link
Author

ghost commented Aug 29, 2018

Please see: danielpalme/IocPerformance#81

We hope to address this soon.

@andreasohlund
Copy link

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
Copy link
Member

See dependencies:

<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
Copy link

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
Copy link
Member

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
Copy link

Great, that was the answer I was looking for

@mbp
Copy link
Contributor

mbp commented Mar 1, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants