Release 6.0.0

[jonorossi]

• [x] #615
• [x] #642
• [x] #633
• [x] #634
• [x] #635
• [x] #636

[renemadsen]

Really looking forward to this release.

[Jevonius]

I'd like to add net6.0 as a target (which I think is the last bit of updating to new Castle Core)? This is currently marred in a fight with some obsolete code (see #616). I haven't had a chance to get my teeth back into this, I'm wondering if there's a way to rip out the references to DiagnosticsLoggerFactory which ought to allow for net6.0 as a target without getting rid of the obsolete code. The main blocker for getting rid of the obsolete code is my lack of knowledge around FacilityConfig.

There's quite a lot of open issues at the moment - might be worth blasting through them and seeing if any will cause breaking changes (i,e. ideally done before bumping to 6.0.0) or if they can be handled with point releases? Maybe 🍻 over Discord sometime, rather than it being a one-person slog? 😄

[sqeezy]

Will #618 be included in this release?

[Jevonius]

I'm going to have some time to look into this again next week and it would be great to the point where a beta is available (full release might be pushing it in a week!). @jonorossi do you have any more thoughts on what should be in this release? I'm still not sure how to resolve #616 and thus get .net6 support fully working (will come at it with fresh eyes and give it some more thought), but are there other stories that need to be done too? As before, happy to hop on Discord or similar to review open issues, or just expand on the list in your first post.

619/#622 would ideally be resolved as part of the .net6 stuff.

[tasoss]

@Jevonius thank you for still caring

[tasoss]

@jonorossi are u there man?

[jonorossi]

@tasoss yes

[Katelynch20]

Hello! in Content Cloud we have this https://jira.sso.episerver.net/browse/CMS-23829 we would like to achieve that has dependencies on this package. are we good to do this now? if someone could review would be greatly appreciated :)

[Jevonius]

I've created #630 (currently in Draft) for the net6.0 work. I simplified the issue I was having with #616 by considering that separately. With the previous upgrade from netstandard1.6 to netstandard2.0, quite a few of the conditional compilation symbols are no longer required and could be removed for this release too (e.g. FEATURE_URIMEMBERS). Can we add that to the list too?

[Jevonius]

Should #631 be added to the list too ? Some of the changes could be breaking (e.g. pulling functionality out into an optional NuGet package rather than having it baked in).

[Jevonius]

616 is resolved by #636. This also tackles a couple of the tasks in #631. Going to switch over to #622 and come back to the compilation symbols once a few PRs have been merged down.

[Kermel]

Hi, may I ask what the "really soon" means in the update to the newest "Castle.Core" mentioned in the post from August? Unfortunatelly I'm getting into troubles within the sourcecode as some of the used nugets expect me to use the newest Castle.Core with their most current versions but this is not compatible with the Castle.Windsor I'm using as well.

I'm aware that this is a free library to use but now we are really considering to switch to another IoC container supporting the newer versions of .NET and I'm used to (and familiar with) Windsor's features so this is not my preference however....

There is already the .NET 7 available but Windsor doesn't even support the .NET 6 yet ... :(

Is there any light in the end of the tunnel already?

[tasoss]

I have stopped wondering anymore. Respect yourself , because others won't , and stop wondering too.

[Kermel]

Yep... looks like a dead project. Unfortunatelly we have quite large codebase depending on it and it's about time to bump the .NET version of our codebase but since the crucial component is not capable of this, it will be really painful :-/

[tasoss]

I'm aware that this is a free library to use but now we are really considering to switch to another IoC container supporting the newer versions of .NET and I'm used to (and familiar with) Windsor's features so this is not my preference however....

This is exactly my situation and i totally agree with what you said . Let's try to enjoy the pain ;)

[jonorossi]

@tasoss @Kermel I not trying to sound rude, but if you want this project to continue you have to get involved, who do you expect to work on it? The status of this library isn't new, I've been saying for years that there is no maintainer for Windsor and that I'm not maintaining it. I've been trying to kick things along every now and again hoping that someone would step up.

Yet another rude message on Sep 1st (not in this thread) pushed me to really step back from all this, I don't need that in my life after contributing to Castle for over a decade.

When I say I need someone or a group of people to step up, I don't mean you have to formally manage anything or commit to doing things for a time period, but take some charge and decide what needs to be done. If you have no free time and your boss won't give you a couple of hours a week to help get this project you rely on back on track, then you can't expect me to contribute my free time.

I'm happy to discuss how you can get involved.

Apologies @Jevonius, you got me with those pull requests at a low point with this project where I just deleted the emails without even looking at them. I'll review them now.

[jonorossi]

@Jevonius can you please rebase your 2 pull requests with merge conflicts and the NUnit one, then once they're merged rebase the logging one.

[renemadsen]

When I say I need someone or a group of people to step up, I don't mean you have to formally manage anything or commit to doing things for a time period, but take some charge and decide what needs to be done. If you have no free time and your boss won't give you a couple of hours a week to help get this project you rely on back on track, then you can't expect me to contribute my free time.

I'm happy to discuss how you can get involved.

I'm happy to help out with deciding what needs to be done, so we can move forward and make sure this good project does not die out. Let me know if you @jonorossi want help in this regard.

We use it in all of our projects, so if this dies, we are looking a replacing it with some other code = hughe refactoring of a lot of projects.

[renemadsen]

I've done a fork and removed all code related to older frameworks, so it only supports .net 7.0. In my humble opinion I would say that is the way to move forward and get rid of a lot of issues, which I see as related to old framworks.

The work can be seen here https://github.com/microting/Windsor I've also released a nuget package working with the latest castle.core for net 7.0 only if anyone is interested in it https://www.nuget.org/packages/Microting.Castle.Windsor/

DISCLAIMER: it's not tested on anything other than net 7.0 codebase.

[Kermel]

@jonorossi Please accept my apologies if my post offended you. I didn't mean to be rude, I'm aware that this is s free library and tha authors (You) work on it in your free time. Unfortunatelly currently I hardly manage all my duties at work (finishing a long-term project and steering work of many dev's around) so I'm afraid I can't contribute much myself. However I can see other members around just mentioned interesting stuff recently - @renemadsen would you consider issuing a pull request so maybe your code could be considered for merging and releasing as the new version?

[renemadsen]

@jonorossi Please accept my apologies if my post offended you. I didn't mean to be rude, I'm aware that this is s free library and tha authors (You) work on it in your free time. Unfortunatelly currently I hardly manage all my duties at work (finishing a long-term project and steering work of many dev's around) so I'm afraid I can't contribute much myself. However I can see other members around just mentioned interesting stuff recently - @renemadsen would you consider issuing a pull request so maybe your code could be considered for merging and releasing as the new version?

@Kermel I can do that. I've also added Github build actions including a nuget release part and dependabot. We internally needs to have packages up to date all the time. Our own maintained packages are getting releases multiple times pr month due to upstream dependency updates if that makes sense.

[jeme]

There is already the .NET 7 available but Windsor doesn't even support the .NET 6 yet ... :(

Just trying to get some understanding here. When you say that it doesn't support .NET 6 and .NET 7 - What exactly do you mean by that??

Should it be assumed that your talking about ASP.NET 6 and ASP.NET 7 and that it refers to the facilities that provide integration points for AspNetCore? Or are there other integration points that is broken here? Using it "Raw" in .NET 6/7 doesn't seem to be an issue.

Since these integrations are essentially decoupled from Windsor, you can always build those integration points your self, although granted it's not always straight forward to do so and it is ofc. really nice when IoC/DI Containers provide that for you. A Starting point may be: https://learn.microsoft.com/en-us/aspnet/core/migration/50-to-60-samples?view=aspnetcore-5.0#custom-dependency-injection-di-container

[jonorossi]

@renemadsen Any reason you wouldn't target .NET 6 (like has been done) rather than .NET 7 since .NET 6 is the LTS release supported until after .NET 7. I'm not saying I'm right, just trying to understand the reason. Could you highlight some of the issues supporting .NET Framework for a bit longer, again not saying it should keep doing that, just want anyone coming later to understand the reason.

@renemadsen Really keen to see you contribute at least the GitHub Actions set up by itself. Any time someone complains about the build over the last few years I've asked someone to contribute the work to move to GitHub Actions like we did for Castle Core, but just crickets. You've done most the work, or maybe all the work.

@Kermel No offence taken, it is more just the same cycle over and over. Everything built here is contributed by someone at some point, usually just people contributing something they want which is what makes sense. Even if you don't have time to write code for the project contributing to discussions is still valuable.

[renemadsen]

@renemadsen Any reason you wouldn't target .NET 6 (like has been done) rather than .NET 7 since .NET 6 is the LTS release supported until after .NET 7. I'm not saying I'm right, just trying to understand the reason. Could you highlight some of the issues supporting .NET Framework for a bit longer, again not saying it should keep doing that, just want anyone coming later to understand the reason.

Just because all new code I touch is getting targeted net 7.0 and getting updated targets as new .net versions are released. Just to keep all projects up to date and not having to maintain legacy code and build up a huge block of code depth. In my experince it's easier to maintain a lot of repositories if they all get small incremental updates and follow the release cycle of .net for framework updates.

@renemadsen Really keen to see you contribute at least the GitHub Actions set up by itself. Any time someone complains about the build over the last few years I've asked someone to contribute the work to move to GitHub Actions like we did for Castle Core, but just crickets. You've done most the work, or maybe all the work.

Glad it's a help. At least it's covering all the tests found the in the AppVeyor

[Kermel]

Just trying to get some understanding here. When you say that it doesn't support .NET 6 and .NET 7 - What exactly do you mean by that??

I probably messed up more things together (writing late at night :) ). The key problem with Windsor curently is that it doesn't cooperate with the newest versions of Castle.Core (5+) so actualizing the libraries within our codebase is now blocked by it (there are some libraries such as NHibernate that depend on the Castle.Core too)

Even if you don't have time to write code for the project contributing to discussions is still valuable.

• Yeah - I can see the discussion was quite started by it and it might result in some interesing changes - fingers crossed :-)

[jeme]

Just because all new code I touch is getting targeted net 7.0 and getting updated targets as new .net versions are released. Just to keep all projects up to date and not having to maintain legacy code and build up a huge block of code depth. In my experince it's easier to maintain a lot of repositories if they all get small incremental updates and follow the release cycle of .net for framework updates.

While it is true that it often is easier to keep up with the newest version of .NET in general, it's not always the case, when your a library author you have to consider where your audience/"customers" is as well.

If you wish for wide adoption and in turn chance to get contributors there is a balance to be struck here - which is also why you see many bigger projects targeting multiple versions of .NET. in line with what is official supported by Microsoft.

[tasoss]

@jonorossi I really really don't want to be rude or sound bad but i must reply because you said a few things.

@tasoss @Kermel I not trying to sound rude, but if you want this project to continue you have to get involved, who do you expect to work on it?

Well if you behave like you did on @Jevonius then no one :) 13 July 2022 https://github.com/castleproject/Windsor/issues/612#issuecomment-1183604759

Is there any way to help with this one? @Jevonius

No reply from anyone

If you mean that my message was rude then i believe telling ppl "really soon" (but knowing that you don't believe it) or saying that you didn't see all the pull requests from @Jevonius because you deleted the emails without viewing them( come on , you can do better than that). I remember @Jevonius calling you to talk over at slack (or whatever) and discuss the issues with no reply from your part.

BUT i have to admit something. I didn't know that you have already said , that you are not maintaining the project! Of course i am grateful for 10 years of development and i totally respect that. But i believe it's time to pass the project to someone who may want to get involved.

Anyway i don't want to continue this discussion. I can see from the replies that some ppl are working on their forks and made serious changes. So this is enough for me.

Thank again @jonorossi for all your hard work (really). I'm sorry if i was rude at you. I just felt that you were fooling us. And don't let anyone make you feel bad for something great that you have achieved through your work.

[renemadsen]

While it is true that it often is easier to keep up with the newest version of .NET in general, it's not always the case, when your a library author you have to consider where your audience/"customers" is as well.

I understand that, but tend to lean towards we need to move forward and kind of nudging people into updating their own codebase in order for them to stay up to date.

Feel free to downgrade to .net 6 or netstandad, but I'm just not going to put the work into supporting older platforms.

[jonorossi]

@tasoss

then i believe telling ppl "really soon" (but knowing that you don't believe it)

That "Update to new Castle Core (coming really soon)" text was referring to the next version of Castle Core, version 5.1.0 which was released later that day on August 2nd, master had already been updated to support Castle Core 5.0.0 in July. I've edited the issue description to add the version number.

because you deleted the emails without viewing them( come on , you can do better than that). I remember @Jevonius calling you to talk over at slack (or whatever) and discuss the issues with no reply from your part.

No explanation to that, yes I should have done better, sorry @Jevonius. I too must have missed the request for Slack, I don't have time for that sort of immediate discussion, way too much going on in my work and personal life.

But i believe it's time to pass the project to someone who may want to get involved.

I've always tried to weigh up the pros and cons for changes to Castle libraries for all users. The problem with projects that have been around a long time is that there are a lot of features, just because one person doesn't see value in a feature doesn't mean it should be removed. There has been a number of people contribute to this project in more recent years, however the more disruptive the changes the more chance you alienate existing users and block them upgrading. If I don't have some confidence of the project not being ripped to pieces to remove everything one individual doesn't use like I had happen a few years back then the Nancy option is more likely.

Good discussions, but can we get this issue back to Windsor 6.0 so we can get the changes released. The current list is in the issue description.

[Kermel]

As for the current list and the posted question "Update to Castle Core 5.1.0 or leave the minimum at 5.0.0?"

• I would vote for update to the latest version, when updating after such a long time, then completely :)

[jonorossi]

Could someone submit a pull request to bump to Castle Core 5.1.0.

[renemadsen]

Could someone submit a pull request to bump to Castle Core 5.1.0. @jonorossi

https://github.com/castleproject/Windsor/pull/641 including all the github actions etc. But it's for net 7 only, so old legacy code for webapi, aspnet, wfc is not tested, but it's still in the codebase if one wants to fix it.

[Jevonius]

No apology needed to me, totally get dealing with projects like this can be a bit thankless at times! Plus, life often gets in the way too :) I was having a look back through at the commit history at one point, this project (+Castle as a whole) has been around for a long time, with lots of different maintainers over the years. As you point out, people generally only tend to care about the bit they need/use, so hard to get full coverage, and clarity, on what's still needed.

I've rebased all the PRs that needed it, but unfortunately nearly all of them change the same line, so they're probably going to keep conflicting as each gets merged down. Oh well! I'll try and find time to have a look at #622 too - would be good to figure out what of this might be a breaking change before 6.0.0, but appreciate it would be good to get something out the door. Currently concerned we might need to consider dropping targeting netstandard2.x to avoid the risk of a run-time error.

[jonorossi]

@Jevonius thanks

I've rebased all the PRs that needed it, but unfortunately nearly all of them change the same line, so they're probably going to keep conflicting as each gets merged down.

I've got them all merged except the logging one.

I'll try and find time to have a look at #622 too - would be good to figure out what of this might be a breaking change before 6.0.0, but appreciate it would be good to get something out the door.

Sounds good. I'll add it to the list for now, we can always change it later.

[thibnes]

Really looking forward to this release too! And Happy New Year \o/

[Kermel]

Happy New Year to all :) @jonorossi & @Jevonius - is there possibly anything new in solving the last issues so the release can be launched ?

[jonorossi]

@Jevonius if you can get #636 ready to merge, I'm happy to publish the release at that point. Do you have the time to get it finished?

[Jevonius]

Hi, as posted elsewhere I'm trying to get back into this now. Will look at #636 first, then hoping to fully understand #622 to know if it might cause breaking changes. The conditional compilation bits (#631) generally aren't breaking, so can wait for a point release; will park the rest for now. Need to change the changelog - think I've forgotten to update that for a few of the now-merged PRs 😟

[thibnes]

Hi there, thanks again for diving back into the project and working on this. I'm using AspnetBoilerplate and I can't migrate our product to .Net 7/8 without this release. So I greatly appreciate your efforts, and I'm sure many others in the community will benefit from your hard work. Keep up the good work, Thank you

[marcoz-tsn]

Hi there, thanks again for diving back into the project and working on this. I'm using AspnetBoilerplate and I can't migrate our product to .Net 7/8 without this release. So I greatly appreciate your efforts, and I'm sure many others in the community will benefit from your hard work. Keep up the good work, Thank you

@thibnes thank you so much for putting into words my own hopes and encouragements !

[thibnes]

Is there a possibility of seeing this implemented prior to the release of .NET 8, in your opinion?

[marcoz-tsn]

Is there a possibility of seeing this implemented prior to the release of .NET 8, in your opinion?

Well, time (months) passes: now I would say: "at least before World War III is officially declared?" Aaaand no, I'm not sarcastic.

I mean, there are a lot of more serious and pressing problems out there, but here it shouldn't be so complex to say a decisive word about the elephant in the room: are we at a dead-end? If so, please stop keeping us all to hope that this empasse is just a couple of PR merge far from resolution...

[jonorossi]

No need to be snarky, no one is being paid to complete this work.

please stop keeping us all to hope that this empasse is just a couple of PR merge far from resolution...

The silly thing is it literally is just one pull request from resolution. I've removed the milestone off #622, anyone is free to finish #636.

[renemadsen]

No need to be snarky, no one is being paid to complete this work.

please stop keeping us all to hope that this empasse is just a couple of PR merge far from resolution...

The silly thing is it literally is just one pull request from resolution. I've removed the milestone off #622, anyone is free to finish #636.

What is missing in #636 so we can move on? Maybe I can help, but needs to know what is missing?

[thibnes]

Anyone to help @renemadsen ? @jonorossi or @jonorossi would you know what's missing in #636?

[Toxantron]

I am currently in the process of removing the Windsor depedency in our industrial project. But before putting any more effort into that, we are discussing to put the hours into Windsor instead. We have used it for over a decade now and did contribute some years back.

We would like to get involved again and if @jonorossi has some patience left, he could point me in the right direction to pick up.

[jonorossi]

Just merged the last pull request for 6.0.0. Sorting out the changelog now.

[jonorossi]

• Tagged v6.0.0
• Confirmed successfully pushed 9 packages to nuget.org including manually uploading of new package Castle.Windsor.Extensions.Hosting

Thanks everyone that contributed. I'm keen to see some contributions to modernise Windsor.