-
Notifications
You must be signed in to change notification settings - Fork 458
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
Comments
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. |
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 |
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. |
@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. |
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?
The text was updated successfully, but these errors were encountered: