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

volosoft / castle-windsor-ms-adapter

Castle Windsor ASP.NET Core / Microsoft.Extensions.DependencyInjection Adapter

https://www.nuget.org/packages/Castle.Windsor.MsDependencyInjection

MIT License

85 stars 29 forks source link

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

Open ghost opened 6 years ago

ghost commented 6 years ago

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

Please see: https://github.com/castleproject/Windsor/commit/fb7933087bb54eb15c9a9364b4335316d2936658

This avoids mutation of lifestyles.
Avoids "Captive Depedencies" as per: https://github.com/castleproject/Windsor/issues/120#issuecomment-339606576
Avoids "Torn Lifestyles" as per: https://github.com/castleproject/Windsor/issues/120#issuecomment-339606576

What do you think?

hikalkan commented 6 years ago

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

ghost commented 6 years ago

Heads up, we have a production ready facility here: https://github.com/castleproject/Windsor/pull/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 commented 6 years ago

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

ghost commented 5 years ago

Please see: https://github.com/danielpalme/IocPerformance/issues/81

We hope to address this soon.

andreasohlund commented 5 years ago

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 commented 5 years ago

See dependencies:

https://github.com/volosoft/castle-windsor-ms-adapter/blob/b24d5279875395451ab029cd28ae573c72327818/src/Castle.Windsor.MsDependencyInjection/Castle.Windsor.MsDependencyInjection.csproj#L25-L31

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

andreasohlund commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Great, that was the answer I was looking for

mbp commented 5 years ago

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

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