Support for .NET Core

[jonorossi]

No one active on the Castle team is looking at this so I thought I'd log an issue to see if anyone wants to contribute to this work. It should follow the way we've done things with Castle Core.

[BMarques]

I forked the project just so I have "fun" to add support for .NET Core, No promises I'll ever finish doing it, but it's a good exercise to learn more .NET features.

Before doing anything and because Castle Windsor will be upped to version 4, I was wondering if it's a good idea to remove support for Silverlight and old versions of .NET, and the oldest .NET supported would be 4.5.2.

From what I saw the most common error is the Serializable attribute, which is not supported in .NET Core. Did this happen with Castle Core project? What's the recommended plan of action ? Create an attribute to do the same as previously or do something else?

[jonorossi]

@BMarques yes, we'll drop Silverlight support here too (no choice, I removed it in Castle Core 😄 ), however the Silverlight conditional compilation was useful while doing the port, so just remove the SL project from the solution in your fork and don't worry about it.

.NET Framework versions is a different story. I decided I wanted to keep older versions for Castle Core to allow the mocking libraries to support older frameworks, however we don't need to do that here so for now just ignore older frameworks in your fork. We can make a decision in the future if we need older frameworks.

Yes, SerializableAttribute came up in the Castle Core port. I decided not to shim a fake attribute in as it functionally does nothing, however it looks like the attribute will be back by the end of the year in .NET Core so do whatever you need to get something going. I originally did two PRs on Castle Core master for serialization (attributes and other code) and reflection (deprecation of old APIs) to simplify our netcore branch, however it sounds like all the old APIs are coming back soon.

I'd recommend taking a look at the actual Castle Core code, especially the list of conditional compilation symbols in the README we've defined to opt-in functionality for .NET Framework.

[BMarques]

After you mentioned that Serializable will be back later, I saw that indeed .NET Core 1.1 will be closer to .NET Framework, so I think for the moment I'll wait and use .NET Framework 4.6.1 and using Castle.Windsor.MsDependencyInjection

[jonorossi]

@BMarques no problem. If you weren't already aware, note that the Castle.Windsor.MsDependencyInjection package isn't published by the Castle Project.

[ParagMeshram]

Excited to see .NET Core support as Windsor is most popular, matured and robust IoC with many more other capabilities

[alinapopa]

Hi @jonorossi ,
I'd like to help with the porting to .NET Core. I see that in Castle.Core the old projects/solution were kept and a new solution and projects was created for .NET Core; do you plan the same for Castle.Windsor?

[jonorossi]

@alinapopa we did that for Castle Core because the .NET Core tooling was in a massive state of flux back then when it was still really early DNX builds, however there is no requirement to do it that way. Now that .NET Core is going back to MSBuild I'd actually like to see a single set of csproj files.

I don't see any problem with Windsor being .NET Standard 2.0 either if that makes it heaps easier, if we have to conditionally compile code out I'd like us to use feature-based symbols (like we've done with Castle Core) so it is clear when reading the code why the code can't work. For example, FEATURE_REMOTING or FEATURE_WCF.

It is up to you, but I think a good first step would be to get a build script set up (maybe like our Castle Core one) that we can set up on TeamCity even if the .NET Core build fails compilation, then submit smaller PRs working towards a working build rather than one giant PR which really slowed things down last time and made code review difficult.

This is what TeamCity is currently running for the .NET Core build for Castle Core:

$ buildscripts\Set-VersionInfo.ps1
$ build NETCORE

Let me know if you've got any questions, feel free to submit a WIP pull request and we can discuss things on the code. Nothing is set in stone, don't be afraid to ask any questions or make any suggestions on how to do things, there is heaps of history here but that doesn't mean those opinions are still valid.

[alinapopa]

@jonorossi having a single set of csproj files means the solution can only be opened with Visual Studio 2017 RC. The existing csproj files need to have many changes, it not just adding a new target framework. It's probably better at this time to do the porting in the same manner as it was done for Castle.Core.
Using .NET Standard 2.0 would make things significantly easier, but the test project which needs to use dotnet-test-nunit is not compatible at this time.

[Kralizek]

Are you guys going to target .NET Core 1.1 or 1.0?
If possible, I'd suggest 1.0 because it's the current LTS, whilst 1.1 is just Current.
For example AWS won't use Current releases of .NET Core runtime, but only the LTS ones.

[jonorossi]

@alinapopa sounds like a good way forward. Once all the tooling settles with a VS RTM we'll have a better idea of how things need to work and will hopefully be able to consolidate the project files here and in Castle Core at that point.

@Kralizek what do you mean by "AWS won't use current releases", can't you just deploy your own version of .NET Core to EC2? What AWS service are you referring to?

[Kralizek]

@jonorossi I'm referring to AWS Lambda. They now support C# by leveraging .NET Core runtime. Specifically, they will only use LTS versions of it.

[ghost]

Hi All,

I have been working with @jonorossi to move us closer to making this happen. Not having Windsor on Core with Linux quite simply does not feel right :)

We are actively clearing out the technical facets of legacy frameworks so we can better position ourselves to leap to core(whilst minimising the distance). The goal right now is to get a build going.

#What have we done so far?

• Removed build support for SILVERLIGHT, NET35, NET40, CLIENTPROFILE and MONO.

#What do we need?

• Remove build flags for the above(please don't remove SILVERLIGHT!). I have started on NET35 @ PR Removed DOTNET35 build flags from code #195.
• Create build infrastructure for NETCORE intently observable @ The Castle Build Server (please register).
• Make build pass(hopefully with first class Linux & Mac support, @jonorossi is this possible?)!
• Supporting AWS Lambda is a 'must have' for me. My team is crossing over from Azure Fucktions(good shout @Kralizek).

@alinapopa - I have had a look at your WIP #160. There are some great learning's there you could help us with. I must say doing it all in one hit is a bit too much change in one go. It also means @jonorossi has to keep polling the PR for commits. We need to do this using baby steps by raising multiple PR's whilst keeping an eye on tests. This will help @jonorossi because he will get a notification each time we raise a PR without having to monitor things manually. To give you an idea, I first forked the project and used a 'brute force' approach to get Windsor compiling on Core just to understand the problems involved. I can honestly say I would not merge this in one hit. I urge you to rejoin this thread :)

[jonorossi]

Make build pass(hopefully with first class Linux & Mac support, @jonorossi is this possible?)!

Linux is easily do-able, the Castle Core builds on TeamCity currently run against Mono however the .NET Core one only tests against Windows. macOS is harder because it can only run on Apple hardware, so the cost of getting a macOS machine in the cloud is very expensive.

[ParagMeshram]

Hi all,

I have seen a lot of traction in recent weeks and I would like to take a moment to applaud you guys for the time and efforts you have been putting. No doubt that Castle Core & Windsor are most matured open source projects I have seen. Long live the Castle !!!

Cheers,
Parag Meshram

[ghost]

OK, NET35, NET40, CLIENTPROFILE and MONO are gonners. We are keeping SILVERLIGHT build flags(not build process) because this is going to be very useful going forward.

[ghost]

@jonorossi - How do you want to tackle the project.json issue?

To quote @MaximRouiller from dotnet/aspnetcore#1433

[jonorossi]

How do you want to tackle the project.json issue?

How do you feel about skipping over project.json and using VS2017 RC and the new csproj tooling especially since VS2017 should RTM today?

[alinapopa]

@jonorossi @fir3pho3nixx please let me know how I can help. For smaller PR's, are you thinking of something like splitting the PR in smaller ones, or having an entirely different approach? Also, what would be a reasonable size?
I vote for using csproj and VS2017.

[jonorossi]

@alinapopa it is not so much the size of the PR but the number of different somewhat unrelated changes all at once. It is important that we don't inadvertently introduce regressions because things were overlooked with a massive PR where it can sometimes be hard to know the intent/reason behind each change and to know if there could be better ways to do things.

I think the first step should be to add the new csproj and get a CI build going even if it doesn't compile. We can then start getting some of the reflection usages updated so both platforms compile (maybe GetTypeInfo as one PR, other PRs can have more than one reflection method change), then keep stepping in the direction to reduce compilation errors.

I'm not directly working on the code so it is best to decide with @fir3pho3nixx who is going to do what.

[ghost]

@alinapopa - Welcome back! Start by getting the project setup going, I still have bits and bobs to take care of with the PR's for removing the build flags(also have to install VS Next). It does not matter if the build does not pass just yet for Core. As long as the build/tests pass for the NET45 related stuff.

@jonorossi - Should we do it as a separate solution just like in Castle.Core?

[MaximRouiller]

"Shits on fire, yo" guy reporting in for duty.

Don't waste time on project.json. It was loved. It was fun. It ended up dead in a ditch.

[jonorossi]

Should we do it as a separate solution just like in Castle.Core?

To be honest I don't know, I suspect we'll probably want to get rid of the current csproj files that specify each file, especially since the new tools can target .NET 4.5 via .NET Standard, and we aren't targeting those old frameworks anymore. I'd be interested to know if we could get rid of all those MSBuild customisations and the targets file that hooks in.

For now though it might be best to create another project side by side until it is building and we can verify all the functionality of the old build scripts is migrated/obsoleted.

[hikalkan]

I was about to leave Caslte Windsor because of not supporting .netstandard (even I love it), but I see that you are working on it. Do you have any time estimation, at least for a beta?
Thanks a lot.

[jonorossi]

PR #268 is the last one to get the main Castle.Windsor project to build on .NET Standard.

#268 merged 🎉

Castle.Facilities.EventWiring and Castle.Facilities.FactorySupport projects can be easily ported.

👍

Castle.Facilities.Logging project has heavy dependency on Castle.Services.Logging.Log4netIntegration and Castle.Services.Logging.NLogIntegration which are not available for .NET Standard.

log4net 2.0.8 supports .NET Standard however we haven't got around to fixing the Castle integration code since APIs are missing in the .NET Standard build (castleproject/Core#201).

NLog 5 is still in beta so we can't add support yet (castleproject/Core#200).

The logging facility shouldn't have a heavy dependence on those, other than some unit tests I'd have only expected the LoggerImplementation enum and the weak reference with the assembly types in LoggingFacility. @fir3pho3nixx definitely agrees with me that all this logging stuff is overly complicated, he is just more vocal 😉 , however let's try to get what we can get building for now and we can redesign things in a future release.

Castle.Facilities.Synchronize project has dependencies on Windows UI, I assume it doesn't make sense to port it to Core.

Yep, no need on .NET Core.

The tests would need to be split in separate projects, since the tests that use Castle.Facilities.Logging and Castle.Facilities.Synchronize will not be built for .Net Core.

I think we'd be better off just using DOTNET45 to exclude the unit tests for those facilities for now, I can see us simplifying things and depreciating some more facilities in the medium term.

[ghost]

@alinapopa - top work!!! :)

If you want we can steal the logging facility from fortress. @hikalkan helped me port this.

[Kralizek]

@alinapopa great job! :)

About the logging, why don't we migrate so that we use Microsoft.Extensions.Logging infrastructure? It's pretty well done and it lets the final user to decide which logging facility to use.

[jonorossi]

About the logging, why don't we migrate so that we use Microsoft.Extensions.Logging infrastructure? It's pretty well done and it lets the final user to decide which logging facility to use.

@Kralizek I'd rather prefer we just not port the current logging facility to .NET Core and get this release out at this stage. There are thousands of package downloads for the current logging facility for .NET Framework so we can't just drop it, I think it would be best not to hold up getting the Windsor core out with discussions about or thrash with a new logging facility.

[Kralizek]

Fair enough. My suggestion was to spare some migration work and to take advantage of the major version change. But i see your point :)

[ghost]

@Kralizek - We have an issue raised by @alinapopa on the project board @ https://github.com/castleproject/Windsor/projects/1 which is to do with removing SILVERLIGHT build symbols. Want to have a go?

[Kralizek]

@fir3pho3nixx I'm away until the 18th of June. I might give a look at it if it's still available when I'm back :)

[ghost]

I'd like to contribute in my spare time. Anything I can help with?

@Kralizek - just giving you an idea of what is in play.

PS: Enjoy your holiday!

[jonorossi]

Since we've now merged our netcore branch into master I'm going to close this issue as it'll be in v4.0 which we'll release very soon.

[ghost]

Added deprecation notice @ https://github.com/cryosharp/fortress#-deprecation-notice

[Kralizek]

Hi everybody! Super happy to see the merge in master branch.

Just a quick question. I already pointed out the limitations for platforms like AWS Lambda to execute .NET Core 1.1 code and marking the package as .NET Standard 1.6 is a step in that direction.

On the other hand, I noticed that the new project file ( https://github.com/castleproject/Windsor/blob/master/src/Castle.Windsor/Castle.Windsor.csproj ) references the 4.3.0 version of many packages. This could lead to indirectly referencing .NET Core 1.1 again.

Would it be possible to downgrade those packages to 4.0 or 4.1?

[jonorossi]

@Kralizek could you please create a new issue with the details, we definitely have time to make the change if possible, a pull request would be great if you can. We had to go with .NET Standard 1.6 to use Microsoft.Extensions.DependencyModel until we move to .NET Standard 2.0 in the future.

[alinapopa]

@Kralizek Castle.Windsor tests are run on netcoreapp1.0
https://github.com/castleproject/Windsor/blob/master/src/Castle.Windsor.Tests/Castle.Windsor.Tests.csproj
Which package is incompatible to .NET Core 1.0 ?

[ghost]

@Kralizek - Raised an issue here #299

[Kralizek]

Sorry guys for not having replied earlier. I should be able to post a sample sometimes this week.