.NET Target Frameworks for Castle Core v5.0

@stakx

We've made changes to our target frameworks for our next major version but none of this has been released yet. With so much time passed and the .NET Core landscape changing I think we need to re-evaluate our target frameworks before releasing.

.NET Core notes:

".NET Core 2.1 reached end of life on August 21, 2021".
According to the .NET Support Policy only .NET Core 3.1 and .NET 5 are currently supported.

.NET Framework notes:

"The .NET Framework versions 4.5.2, 4.6, and 4.6.1 will reach end of support on April 26, 2022"

Our set up:

<!-- v4.4.1 -->
<TargetFrameworks>net35;net40;net45;netstandard1.3;netstandard1.5</TargetFrameworks>

<!-- master -->
<TargetFrameworks>net45;netstandard2.0;netstandard2.1</TargetFrameworks>

What do we support for v5.0? I don't think we should be supporting any .NET Core versions that are now end of life, there is no reason for people to expect we support new versions of Castle Core on end of life runtimes. Do we continue with any .NET Standard TFMs? Even though DynamicProxy might not work on some .NET Standard-based runtimes, Windsor depends on Castle Core and so we shouldn't restrict Windsor unnecessarily.

/cc @stakx

Sorry, please ignore my above post. I misread some relevant parts of the top post.

TL;DR: I think the targets we have now are still fine. I understand the desire to only target supported versions, but OTOH when it's easy for us to support older versions (no code changes needed), why shouldn't we? We'll otherwise force downstream libraries to update their targets, and I'm not sure we need to do so. What are the actual downsides to targeting unsupported older versions?

This isn't the same situation now as when we dropped support for .NET 3.5 and .NET Standard 1.x; dropping those allowed us to simplify our code and conditional compilation. This time, by dropping netstandard2.x we likely wouldn't gain anything significant.

Re: exchanging .NET Standard, citing from here:

When to target net5.0 vs. netstandard

For existing code that targets netstandard, there's no need to change the TFM to net5.0. .NET 5.0 implements .NET Standard 2.1 and earlier. The only reason to retarget from .NET Standard to .NET 5.0 would be to gain access to more runtime features, language features, or APIs.

I'm not sure we need any new APIs just now. The major one we've been waiting for is probably AssemblyBuilder.Save, AFAIK that still hasn't arrived.

Do we know any dates when Castle Core v5.0 will be released? We are waiting for .netstandard 2.0 support as a step forward for migration to .net 6 from .net 4.8.

Seems it is the latest item for this release

@talenor

@talenor Does netstandard1.5 not work on .NET 6, or does the big list of BCL packages cause other problems?

@jonorossi

@jonorossi Well... we haven't dived deep into netstandard1.5 because netstandard 2.0 exists quite a long time and we checked only 2.0 so I can't provide a reasonable answer.
However, in my opinion, 2.0 brings more stable and solid support. Especially if we are talking of an application with ~500k lines of .net code

@talenor

@talenor Are you just using Castle.Core (maybe via a mocking library), or other Castle libraries too?

@jonorossi

@jonorossi only Castle.Core (directly, via some ninject extensions, and via Moq)

We are also waiting for this because we want to get rid off these old assemblies that come from old version of netstandard libraries #602

When there is newer target framework defined then those assemblies dont get installed. This is why .net6 target framework would be good

Also since .net5 that is the recommended way forward from microsoft. https://docs.microsoft.com/en-us/dotnet/standard/frameworks

.net 5 and .net 6 TFMs should be included in next major IMO

Is there any reason why castle core cannot just add netstandard 2+ / net5 / net6 target frameworks and reduce the big number of unnecessary dependencies for those target frameworks https://www.nuget.org/packages/Castle.Core/ This way modern applications can get rid off possible security vulnerabilities #602 and reduce installation size?

What are the actual downsides to targeting unsupported older versions?

I know that with .NET Framework the target framework affects things at runtime (e.g. default SSL/TLS protocols enabled is a big one until you upgrade to 4.6.2), but that could only apply to the executable and not a library.

@stakx

@stakx's quote from Microsoft Docs is still there regarding whether we need net5.0 or net6.0 now under the "When to target net5.0 or net6.0 vs. netstandard" heading.

Any one with a concrete reason for wanting the target frameworks to change for v5.0? Otherwise I'll close this by the end of the week.

@jonorossi

Hi @jonorossi, what would you define as a concrete reason? We bounced a couple of messages in #602 relating to transitive references, and that's probably one reason I'd push for including net6.0 as a target.

Reviewing the Microsoft Docs page from above, there is this in the same section under Reusable libraries:

Most widely used libraries will multi-target for both .NET Standard 2.0 and .NET 5+. Supporting .NET Standard 2.0 gives you the most reach, while supporting .NET 5+ ensures you can leverage the latest platform features for customers that are already on .NET 5+.

It doesn't seem entirely unreasonable to assume that having a net6.0 (and net5.0 for that matter, despite it being out of support) target would allow modern consuming projects that don't otherwise reference anything netstandard to streamline their dependency trees (and build quicker, with less transient older dependencies).

There's also less chance of subtle bugs, such as breaking changes causing issues, where older versions are used because of Castle pulling them down. I had an issue recently with Kestrel, where my project was pulling in an older version because of a dependency, but other code was using newer shared DLLs that built fine, but then broke at runtime because of changed functionality.

while supporting .NET 5+ ensures you can leverage the latest platform features for customers that are already on .NET 5+

A net50 application referencing a netstandard2.x library will be able to use .NET 5 features. Only the library itself will be limited to the .NET Standard 2.x feature set... right? So if that feature set actually suffices for the library, what would it gain by adding a net50 TFM? (I fail to see the benefit.)

Or does the lack of a net50 TFM in the library somehow "downgrade" the referencing net50 application? (I don't think so, but I may not be up to date with NuGet's sometimes weird versioning algorithm.)

As suggested, I've created a PR (#614) moving the minimum version up to 4.6.2. First attempt at contributing, but I've tried to be guided by previous PRs/commit structures so hopefully all in order. If happy with this, I'll take a look at the changes for net6 now that I've got a better grasp of how things are structured.

@jonorossi

Leave .NET Standard 2.0

You are proposing .NET Standard 2.0, if we drop .NET Standard 2.1 [...] I'm not seeing any difference in common.prop between the .NET Standard 2.0 and 2.1 builds.

Just for reference, the netstandard2.x targets were discussed in detail back in #407. IIRC, the main reason why we have netstandard2.1 is our dependency on System.Reflection.Emit (which .netstandard2.0 never officially supported, but got to work nevertheless through some magic extra FCL NuGet package). Other than that, netstandard2.1 and netstandard2.0 are pretty much exchangeable for this project.

Quoting from @jonorossi's decision from #407 (comment):

likely no one really cares that .NET Standard 2.0 doesn't really support reflection emit, and we should [...] add .NET Standard 2.0 to get rid of all the cruft of every BCL package being listed. At the same time add .NET Standard 2.1 because that is the target we want people to use, as we'll drop .NET Standard 2.0 in a couple of years.

Since it now looks like we're going to drop support for ancient framework versions, perhaps we should drop netstandard2.0 instead, and keep netstandard2.1?

@Jevonius

Just for reference, the netstandard2.x targets were discussed in detail back in #407. IIRC, the main reason why we have netstandard2.1 is our dependency on System.Reflection.Emit (which .netstandard2.0 never officially supported, but got to work nevertheless through some magic extra FCL NuGet package). Other than that, netstandard2.1 and netstandard2.0 are pretty much exchangeable for this project.

Ah yes, I had completely forgotten about that. Cheers.

as we'll drop .NET Standard 2.0 in a couple of years

"commented on 28 Apr 2020"... that's right now 😆

Since it now looks like we're going to drop support for ancient framework versions, perhaps we should drop netstandard2.0 instead, and keep netstandard2.1?

That'll drop support .NET Core 2.1 which we currently support through .NET Standard 1.x, but I'm good with that since it was end of life August 21, 2021. .NET Standard 2.1 supports .NET Core 3.1 which is still in support. And we support .NET Framework via the netfx target rather than .NET Standard anyway.

Sounds good to me. @Jevonius do you agree?

I'm a little wary of suggesting removing netstandard2.0, mainly because of projects that consume Castle and what they target; my perception is that most projects tend to target netstandard2.0 rather than netstandard2.1; the exception in the top 10 from https://www.nuget.org/stats/packages is AutoMapper (which only targets netstandard2.1).

Given the only difference I can see between Castle builds for 2.0 and 2.1 is the inclusion of the PackageReference for System.Reflection.Emit, it feels like dropping 2.0 is not really of much benefit from a maintenance perspective, but does penalise those stuck with older frameworks. Then again, given this is going to be a major version jump, perhaps now is the right time to drive things forward.

it feels like dropping 2.0 is not really of much benefit from a maintenance perspective, but does penalise those stuck with older frameworks

Despite my above post, and despite having argued against netstandard2.0 in the past, I tend to agree with this reasoning... if preserving the netstandard2.0 TFM doesn't overly complicate things in this project here.

For me, the more important thing would be to not drop netstandard2.1 in favor of netstandard2.0.

One argument against having too many TFMs was that we'd need to cover all of them in the CI test runs (thus making the CI setup more complex and slower). How about keeping netstandard2.0, but not running extra CI tests for it? A test configuration for netstandard2.1 should sufficiently cover the netstandard2.0 target, too. That would allow us to keep both of them (as is).

Then again, given this is going to be a major version jump, perhaps now is the right time to drive things forward.

Also agree with that one. I think it's fine either way, with or without netstandard2.0.

@Jevonius

Good reasoning @Jevonius.

I think to keep things moving we just take the path of least resistance and go with both (since we've already got them) and leave it running tests on both targets as the CI build is pretty quick (5 minutes) anyway. We might find by the time we get to v6 no one is using .NET Standard targets anymore 😉 .

So we do: <TargetFrameworks>net462;netstandard2.0;netstandard2.1;net6.0</TargetFrameworks>

For the unit tests we've currently got:

<TargetFrameworks>net462;netcoreapp2.1;netcoreapp3.1</TargetFrameworks>

There is no point testing on end of life .NET runtimes, do we change this to:

<TargetFrameworks>net462;net6.0</TargetFrameworks>

3.1 is in support until December 2022, so I'd be tempted to say:

<TargetFrameworks>net462;netcoreapp3.1;net6.0</TargetFrameworks>

This then covers the netstandard2.X targeting too, which would otherwise be missed/excluded. As noted, the CI process time is negligible, so doesn't seem like there's any real advantage to excluding it.

3.1 is in support until December 2022, so I'd be tempted to say:

Ah yer, 3.1 is an LTS release too. Yep go with your proposed list.

Have just opened a PR (#616) for adding net6.0; had a bit of a fight with the build pipelines and NUnit but have something that builds and passes tests now.

@stakx

Coming back to dropping netcoreapp2.1 from the test side, if we do that the netstandard2.0 build won’t get tested. Arguably that’s already the case since 2.1 tests aren’t executed. Is that ok? Alternatively, @stakx if we were to drop netstandard2.1 as a target, the 3.1 tests would then consume the 2.0 packages, and everything would still be in support.

@stakx

Alternatively, @stakx if we were to drop netstandard2.1 as a target

That would, IMHO, be the wrong move, as I commented elsewhere recently. If we decided to drop any of the netstandard2.x TFMs at all, it should be netstandard2.0 instead.

If it's important to you guys to set the test coverage issue aright, then by all means go ahead and remove netstandard2.0 (or alternatively set up a netcoreapp2.x test run). I personally certainly won't insist on it; these days, I care much more about finally seeing v5 released than I care about the perfect, squeaky clean project setup. :-)

That would, IMHO, be the wrong move, as I commented elsewhere recently. If we decided to drop any of the netstandard2.x TFMs at all, it should be netstandard2.0 instead.

netstandard2.1 is not compatible with older xamarin and .NET framework, but as people are including .net45 for example I don't this think this really matters. https://dotnet.microsoft.com/en-us/platform/dotnet-standard#versions

Adding new target frameworks is not breaking change... so if anybody ever comes with an issue about those they can be added in 5.0.1 and so on... Just hurry up with the release of v5 please

Not having a modern target framework is bigger issue than having some old target framework as they can always be added later without breaking changes...

@Jevonius

Thanks to @Jevonius we've now got a .NET 6 target in master (#616).

Here are the final TFMs for Castle Core v5.0.0:

<!-- v4.4.1 -->
<TargetFrameworks>net35;net40;net45;netstandard1.3;netstandard1.5</TargetFrameworks>

<!-- master / v5.0.0 -->
<TargetFrameworks>net462;netstandard2.0;netstandard2.1;net6.0</TargetFrameworks>

Navigation Menu

Repository navigation

.NET Target Frameworks for Castle Core v5.0 #597

When to target `net5.0` vs. `netstandard`

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

.NET Target Frameworks for Castle Core v5.0 #597

Description

Activity

stakx commented on Sep 4, 2021

stakx commented on Sep 4, 2021

When to target net5.0 vs. netstandard

talenor commented on Dec 7, 2021

jonorossi commented on Dec 7, 2021

talenor commented on Dec 7, 2021

jonorossi commented on Dec 7, 2021

talenor commented on Dec 7, 2021

Havunen commented on Dec 15, 2021

Havunen commented on Dec 16, 2021

Havunen commented on Dec 28, 2021

jonorossi commented on Apr 5, 2022

jonorossi commented on Apr 5, 2022

Jevonius commented on Apr 6, 2022

stakx commented on Apr 6, 2022

12 remaining items

Jevonius commented on Apr 6, 2022

stakx commented on Apr 7, 2022

jonorossi commented on Apr 7, 2022

Jevonius commented on Apr 7, 2022

stakx commented on Apr 7, 2022

jonorossi commented on Apr 7, 2022

jonorossi commented on Apr 7, 2022

Jevonius commented on Apr 7, 2022

jonorossi commented on Apr 7, 2022

Jevonius commented on Apr 9, 2022

Jevonius commented on May 1, 2022

stakx commented on May 1, 2022

Havunen commented on May 2, 2022

jonorossi commented on May 9, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

When to target `net5.0` vs. `netstandard`