QUESTION: What is the future of this project?

[ghost]

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]

Hi

Will send you a couple of PR's :)

Once you create the attic and we flag the WCF facility, that will help get people going easier. It will also help the migration to dotnet core on linux.

Will send you a separate PR in the near future for following items:

• Removing silverlight

• Removing obsolescence.

  At the moment just getting the project going and raising PR's that I think could be useful for anyone else exploring the same journey.

Would also like to look at getting this running on ubuntu linux using core.

[TaviTruman]

We have dozens of projects in production that use the WCF facilities and we continue to write application using it as well; at the Enterprise level we see no reason to stop doing so. The Windsor support for WCF works very well and we've had not any problems with it going on 5 years now.

[jberezanski]

Same here. The WCF facility is very handy and takes care of much of the boilerplate code required for robust WCF usage, making writing WCF applications a pleasure.

(And WCF still remains a powerful, flexible and reliable communication framework, with a very convenient programming model.)

[ghost]

Might have closed this prematurely.

WCF, do you guys (@jberezanski and @TaviTruman) know of an upgrade path to dotnetcore?

Found this: https://blogs.msdn.microsoft.com/webdev/2016/06/26/wcf-connected-service-for-net-core-1-0-0-and-asp-net-core-1-0-0-is-now-available/

But I don't think it is an answer. Anything I am missing?

[jberezanski]

Frankly, at my place we aren't interested in dotnetcore right now. We don't need to run on other platforms than Windows and we're actively using features unique to that platform, such as Windows authentication and named pipes for intra-machine communication. We'll probably consider migrating to dotnetcore once (if?) it gains more sophisticated communication abilities than REST over HTTP (which does not appeal to us at all).

From what I've read, dotnetcore currently implements many (most?) of the client-side WCF features. I'm not sure if there are any concrete plans to implement the server side (there have been talks in the dotnetcore repos, but no firm commitments). The dotnetcore port of the facility could perhaps start by disabling server-side features, with the possibility of lighting them up in the future.

[TaviTruman]

I don't know it to be an upgrade path but rather the ability to use your WCF services on other platforms; I have two teams porting Azure Web App and WCF-Relayed Services to Linux Suse and Mac OSX (Clients) and they are using WCF Connected Services - and - we sorely miss the Windsor WCF Facility. This is a prototype effort but so far it is going well. I wrote a small prototype for my teams to follow as an example and it was very easy; not hard at all.

[TaviTruman]

Yeah we also have not interest in REST/HTTP either and we are also using a number of protocols and security via WCF. WCF Rocks and has been for a long time now.

[ghost]

I guess where I was coming from, the last thing you expect is the build process for an IoC framework to have tests/dependencies on WCF. Seems a little weird to me.

That said, it can definitely still be supported for DesktopCLR(net4.X). Just wont be a thing on core to start with?

[jberezanski]

That would be fine by me. Once the container is ported, some day we could look at determining how much work it would be to port the client half of the facility, too.

[jonorossi]

Once you create the attic and we flag the WCF facility, that will help get people going easier. It will also help the migration to dotnet core on linux.

Maybe you misunderstood what I said in my reply, removing features like the WCF facility that people may be heavily using can't just be an off the cuff decision just because you or I don't use them, Windsor has a long history and a lot of users so things like this have to be discussed to allow others the ability to weigh in, glad to see others have jumped in and shown this is a feature still being used.

I've said this before quite a number of times with Castle Core that the .NET Core version of the library doesn't have to have the full API surface area or featureset which was my driver for using heaps of conditional symbols so we could enable features much easier as the underlying functionality becomes available, take a look at the big list of symbols used in Castle Core listed in the README, my preference is to go away from platform specific symbols which just cause maintenance pain.

Removing silverlight

Yes Silverlight should be removed, however I'd leave all SILVERLIGHT and SL3 symbols in the codebase until the .NET Core port is done because they greatly help as there are quite a lot of similarities with Silverlight. Feel free to submit a PR to remove the project files and other surrounding gunk like the StatLight testing framework and build script support.

[ghost]

It is great guys have climbed on board with this discussion. I understand it cannot be removed. That is perfectly OK. It will stay. For the other guys on the thread, I don't have the power to delete it anyway so you are safe :)

It is also well understood there is no path to core for it either(yet ...), so that is also good.

My motives here are to try and find a way perhaps achieving the following:

1. Is it possible just to pull the source, build it and make tests pass without having to worry about administration tasks around WCF? Honestly was the last thing I expected when I got a fresh cut of master.

2. Having to run things without Admin Privs would be great!

If the answer is "on you're bike Gav" ... then I will accept it also. Was just pondering if there is a better way of doing this ...

[TaviTruman]

@fir3pho3nixx I totally get where you are coming from and where you want to go; it would seem to me that as this IoC has so may "Capabilities" attach to it the build and test needs to be, must be, more modular so that you aren't forced to build the whole thing at once. We are dealing with our internal product assemblage issues as well. Later on via Survey as capabilities or modules fall out of usage then they just get migrated to the archive and that module is removed from the "active build process." - Just a thought.

[ghost]

@TaviTruman can this could be applied to Castle Windsor?

[TaviTruman]

@fir3pho3nixx I think it can - just a few weeks ago I orchestrated our migration from using Unity IoC with PRISM 6.x for WPF/UWP to Castle/Windsor and there were lots of pieces to fix and restructure. FYI - we did excludes parts that we done need like Silverlight.

I had to physically restructure the PRISM 6.x and Castle/Windsor so that our extensions to both libraries worked and use our custom "Test Project" and Azure Based "Test Harnesses." I'm working out some of the bumps in UWP but for the most part via PowerShell and Nuget Build Profiles/Packages I got it to work.

I have two of my Build Engineers documenting the process with the intent of sharing it with bot the Castle and Prism Open Source communities. Our Production Source Code Repository is managed via Visual Studio Team Services and TFS but we like give back to Open Source.

I will share the procedure as soon as it clean.

[ghost]

Good stuff, look forward to it.

[ghost]

Been participating on Fake.AzureRm which we intend to run on FAKE eventually. If you use Paket as your package manager, you can do pretty much anything. Paket does garbage collection of outdated nugets.

[TaviTruman]

Cool

[jonnii]

I think the goal should be to get something working on .net core, if this means foregoing nice to have features like the wcf facility or the transaction facility then so be it. If there's a desire for those features they can always be ported at a later date.

I think 4.0 is an opportunity to take a critical look at what comes out of the box with windsor and strip it back to the basics, if you're on the full framework and using the 3.x series of windsor you're not going to get any benefit from upgrading to 4.0, and the major version bump should be an indication that there will be breakages.

An example of this is things like:

http://hammett.castleproject.org/index.php/2007/02/windsor-container-and-environments/

We have relied on this feature heavily to manage differences between environments, but over the last year or so we have moved instead away from that and to a single .json file for configuration. This little known (and otherwise undocumented as far as I know) feature is the kind of thing that we should deprecate, not because i personally don't use it any more but because it's a relic of the past.

[jonorossi]

Is it possible just to pull the source, build it and make tests pass without having to worry about administration tasks around WCF? Honestly was the last thing I expected when I got a fresh cut of master.

@fir3pho3nixx I'd be more than happy for those few WCF facility unit tests that require admin access to only run on the build server, it would ease development for something we are unlikely to break, while still allowing us to get the benefit of them being run somewhere. Thoughts?

it would seem to me that as this IoC has so may "Capabilities" attach to it the build and test needs to be, must be, more modular so that you aren't forced to build the whole thing at once.

@TaviTruman we tried different approaches over more than the last 10 years, and one approach I know won't work well with an under-resourced team is breaking things up even more, those separated projects will get no love and will be an even bigger headache. We should decide whether we are going to support these more fringe features and do so, or depreciate them by moving them out declaring they are unsupported but the source code is still available if people want to do something with it or copy the code into their project.

I think the goal should be to get something working on .net core, if this means foregoing nice to have features like the wcf facility or the transaction facility then so be it. If there's a desire for those features they can always be ported at a later date.

@jonnii definitely, and this has been my position since starting on .NET Core in Castle Core, ignore all facilities and just get the core container running.

@fir3pho3nixx I'm not sure this issue has much relevance anymore, happy to be proven wrong, but I think we'd be better served by people (i.e. anyone) creating issues about a specific topic to form some common ground, make a plan to move forward and start executing. To be clear, I think it is time to close this issue and for discussion to happen in new specific issues.

[ghost]

@jonorossi - Making them unit tests might be the way forward, or we could just add a build flag include them if they detect the right framework on the environment they are in.

By all means, let's raise new issues. I would reference this issue as background reading.

[TaviTruman]

Proceed as best you know how to; I have what I need. No disrespect in anyway is intended - all of those that created Castle/Windsor have done a great job, a great feat of collaboration and engineering.

[jonorossi]

@fir3pho3nixx I've logged #174 if you'd like to dig in.

@TaviTruman no disrespect taken at all, it is great to hear from more people. No dictator here, happy to have others get involved in the project and start making decisions, I'm just trying to lead people in what I believe is the right direction.

[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.