QUESTION: What is the future of this project?

Hi,

To start, I absolutely swear by this project. It has been my go to place for IoC. I absolutely hate all other containers as a result. They suck for many reasons. This one totally does not. That said please take the following with a pinch of salt.

I would like to propose a redux but before that can happen I need to know where you guys are heading. There is a moving target when it comes to dotnet core, it is hard to anticipate. I can also see someone has had a go at porting the project which is great, although it might be a bit premature to try (happy to be told off for thinking this).

After forking the project, I noticed a couple of things:

• WCF is a thing. Does it have to be? Can we delete this facility? It adds weight to contributions in terms of ramp up and does not make sense given the momentum in dotnet core. WCF is playing catch up and let’s face it nobody cares about it anymore. IoC containers should not be marred by things like running netsh.exe and enabling port sharing using sc.exe config NetTcpPortSharing to make tests pass. Can we drop this and get back to basics in anticipation of developments in core? With the advent of DevOps and PaaS we honestly don’t give a monkeys undies.

• Silverlight is a thing. Does it really, really have to be? I mean really? RIA is deadskies. Can we remove this pretty please! 😃

• Prescription of logging is a thing. In dotnet core there might be a revolution when it comes to logging. In cloud there already is. In Azure we delete most logging frameworks and implement Application Insights(which I must say is the one thing Microsoft did right). In AWS we use CloudWatch. There are also a multitude of log shipping vendors based on this. Why oh why are we tied down to log4net and NLog? If we remove this and substitute it with extensible lambda based extentions or leverage sub dependency resolvers better, surely we can get rid of this and anticipate core better? Docs become lighter …

• Tests are failing in master(apart from all the crap to do with WCF). FluentRegistrationTestCase.Can_publish_events_via_AllTypes, would fix it if I new where we are going. AllTypes has been marked as obsolete. So should we delete this and start thinking about getting rid of obsolescence?

• Test have been ignored or are made explicit. Is this a change of direction? Specifically scope resolution and convention validation. Wwwwwwwhhhhhhhhyyyyyyyyyyy? Master should be kept pristine. Always!

So, now that you hate me, how do I help?

Gav

[jonorossi]

@fir3pho3nixx thanks for your direct questions Gav, no hate at all, the opposite actually. I’ve had “addressing the future of the whole Castle Project” on my TODO for a few months so this is a good start, my opinion is that the Castle Project is no longer the great relevant projects we made in the glory days and each project (including Castle Core) is carrying way too much baggage. We no longer maintain MonoRail or ActiveRecord as well as many other projects and I’ve planned an idea of an attic for obsolete projects to make a clear indicating that they are unmaintained (i.e. they can come back from the attic only if someone is going to maintain them).

Let’s keep this issue to just Windsor, all the other topics I’m planning to raise one by one once I finish with my current contract and I’ve got a little bit more time to try sorting things out from the overarching level.

Windsor definitely needs people like you to bring it back alive, I’m sure it is apparent that I’m doing the bare minimum to keep it operating. The Castle team over more than a decade has changed many times (as your would expect), however we’ve had very few new people stick around for any length of time over the last few years which has resulted in there not being any active contributors.

• Yes .NET Core is in a state of flux with .NET Standard 2.0 looming. It took quite a while to get Castle Core ported, it is really up to those interested whether they see .NET Standard 1.x support worthwhile. The current WIP pull request is good, however as I requested in the GitHub issue (and following from learning after doing Castle Core) the only sane way to get the changes merged is in smaller pull requests not ones with 3000 lines of code changed.
• WCF… yes I agree it isn’t really a thing anymore and I’ve personally never used the facility. I see absolutely no reason to support in on .NET Core, however there have been quite a number of people using it in the past and Windsor has such a long history that dumping it might not be the best idea. Seriously though this is something we need to discuss and try to get feedback from active users (i.e. mailing lists and GitHub), there might be less push back than I’m expecting. If we are maintaining/supporting it I’d prefer it to be in the Windsor repo rather than separating it into its own as it’ll go stale, which means it isn’t really supported. However if decided to obsolete it, moving to its own repo would work fine. There are other facilities that are in the same camp, I know 2 facilities that still have source code in the git repo but aren’t built or shipped.
• Silverlight is dead. It cannot be supported as I removed support in Castle Core 4.0.
• I’m not sure why you think Castle’s logging is tied to log4net and NLog (it also supports Serilog by the way), yes the enum in the logging facility has those hardcoded for really easy one line configuration, but you can implement a logger really easily, check out how simple the one is we ship for Serilog (https://github.com/castleproject/Core/tree/master/src/Castle.Services.Logging.SerilogIntegration). Maybe the registration API for setting up the facility could be better and the enum could be obsoleted in favour of something that works better with the Castle logging services.
• I’m not sure what unit tests you are seeing failing in master but when I released 3.4.0 the other day everything passed on our build server. Might be an environment thing, I know the MSDTC needs to be running for some tests.
• Things marked obsolete probably should be dropped, as you can imagine the roadmap for most OSS projects don’t set a deadline to remove obsoleted code especially when removing it annoys some people too lazy to change usages. Yes, we should be looking at when things were marked obsolete and planning to remove them when enough time has passed and version numbers are right.
• Yes master should stay clean, I’d argue that pragmatically though a few ignored tests aren’t the end of the world, but again most people that have worked on Windsor have done it out of love of the project with limited time meaning that not everything can be perfect, this is the opportunity to help out even though you won’t know the history which is the case if I looked into those unit tests, try looking at the commits that modified them to get an idea.

Where do you help… that is completely up to you and how much time you’ve got to contribute, maybe start with some tidy up of some of the items you highlighted if you like. The open issues on GitHub definitely need addressing, i.e. are they defects, etc. If you take a look at the Castle Core ones I’ve triaged and labelled their status or type.

Looking forward to your contributions.

Jono

[ghost]

Got tests separated out nicely.

build - Defaults to build NET40 RunAllTests

build NET40 RunAllTests - Still includes all the WCF facility tests.

build NET40 RunUnitTests - Only runs the tests marked with the UnitTestAttribute. This is passes in a cmd.exe that does not have admin privs.

Next I think work should start on the build NETCORE feature @jonorossi started in https://github.com/castleproject/Core/blob/master/buildscripts/build.cmd.

If we have one for Windsor, then we can start thinking about porting the unit tests to core.