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

New Castle.Windsor package that is compatible with Castle.Core 5.* #623

Closed
WenningQiu opened this issue Aug 12, 2022 · 5 comments
Closed

Comments

@WenningQiu
Copy link

The latest Castle.Windsor package (5.1.2) appears to be outdated w.r.t consuming the latest Castle.Core. Should a new version be released?

image

@jonorossi
Copy link
Member

What installed Castle Core 5.1.0? We added the constraint in Windsor 5.1.2 (#614) because it isn't compatible.

We are planning a new release, but NuGet should handle the dependency constraint so you can use the most recent compatible version.

@jeme
Copy link
Contributor

jeme commented Nov 16, 2022

Man this is a mess >.<... Hope you manage to get a new Windsor out soon that supports the latest castle core. Considering that there is a strong relation between Castle.Core and Castle.Windsor in people's mind from an external perspective, I can fully understand why this causes confusion. (Although I also fully understand that internally Windsor may introduce breaking changes more often and therefore have to bump the major version more often than the core project, .NET is a platform among many where this is unfortunately problematic :(... )

I interestingly enough find my self in a odd situation where I need to stick to the 5.1.1 so that we can use Castle.Core 5.1.0 in our tests as we are using Mock frameworks that depends on that package, yet stick to 4.4.1 in production. Normally that would put me at unease, but since we run hundreds of automated API and UI tests on top of things, then any problems from that should show them self there.

In test, we don't really use Castle.Windsor though, it just comes in as a dependency as our production code uses it (A package often provides a Root installer that registers components in windsor), as such we never run code paths that cause this error to happen in tests and can accept that our Mocking framework bumps Castle.Core to 5x...

But Whenever I do a round of "Let's bump all packages in our solution" I run into this and have a "Ohh, that's right" moment... Really annoying...

Anyways, that means Castle.Windsor 5.1.2 is actually turns out to be more problematic for us right now, and we would have to refactor quite a few bits before we are back to "safe ground", but that certainly becomes a consideration with this... :S

@jonorossi
Copy link
Member

Man this is a mess >.<... Hope you manage to get a new Windsor out soon that supports the latest castle core. Considering that there is a strong relation between Castle.Core and Castle.Windsor in people's mind from an external perspective, I can fully understand why this causes confusion. (Although I also fully understand that internally Windsor may introduce breaking changes more often and therefore have to bump the major version more often than the core project, .NET is a platform among many where this is unfortunately problematic :(... )

Windsor has been versioned separately to Castle Core for over a decade.

@jeme
Copy link
Contributor

jeme commented Nov 30, 2022

Man this is a mess >.<... Hope you manage to get a new Windsor out soon that supports the latest castle core. Considering that there is a strong relation between Castle.Core and Castle.Windsor in people's mind from an external perspective, I can fully understand why this causes confusion. (Although I also fully understand that internally Windsor may introduce breaking changes more often and therefore have to bump the major version more often than the core project, .NET is a platform among many where this is unfortunately problematic :(... )

Windsor has been versioned separately to Castle Core for over a decade.

I fear that you may have taken this to close at heart, as in understanding " Man this is a mess " to much as targeted at Windsor as in " Man Windsor is a mess ", but that was not the case, it was targeted at the situation you end up in when you combine things. I won't go into a lengthy explanation of that, just understand that it was not meant as attack on the project or it's maintainers, i apologize if it was perceived as that.

The last part was the most important to bring into light, that Castle.Windsor 5.1.2 in restricting to Castle.Core 4.x causes a new set of problems for us as explained. I don't specifically have any good idea on how to solve this elegantly, but it was actually better for us with 5.1.1.

@jonorossi
Copy link
Member

@jeme no harm, thanks for the explanation. I think I've gotten so used to snarky comments on closed issues over the years I likely read yours with a certain preconceived bias.

It does suck the position things are in now with Windsor partly spread into Castle Core, a lot of history there from 15+ years. Definitely no clean line between the two, means that DynamicProxy isn't an optional feature.

If you're keen to help plan Windsor's future please do continue to contribute to discussions as there are others that are heavily using Windsor too.

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