Targeting new .NET features

[Code-Grump]

I've seen some good ideas floating around for taking advantage of features in newer versions of .NET:

• https://github.com/orgs/reqnroll/discussions/212
• https://github.com/orgs/reqnroll/discussions/138

Naturally, the .NET ecosystem moves forwards and we're going to see more things appear that users would want out-of-the-box support for.

Should we consider making Reqnroll target newer .NET versions to give us access to those newer APIs and be able to support these features directly? I would propose a multi-targeted library build, keeping support for .NET Framework (and others) via continuing to target .NET Standard 2.0 and adding specific targets for the currently supported .NET versions.

NuGet packages already support bundling multiple runtime target assemblies into a single package; I don't forsee complication here.

My only concern here is how it affects tests and CI. Our tests can also be made multi-targeted to run tests for each target platform, but that does add an increase in the volume of tests that will be run for builds. Parallel execution means no real increase in running time, but it will consume a lot more total time. Is that a problem or something of concern? Are there any other issues with multi-targeted tests?

Obviously sticking to a single target is a much simpler model, but .NET Standard 2.0 is getting old now, and there are new things developers are going to want to have available. I suppose there is a path forward where we stay single-target and target the oldest in-support version of .NET (version 6 until November 2024) and there's a two-year lag for new features to become supported, and the .NET Framework people are out of luck.

Are there other alternatives to this problem? Is there an aspect of multi-targeting I have missed?

[ajeckmans]

To take full advantage of the multi-targeting and new features of the newer versions you'd have to start ifdef a lot of code. For instance nullability is one that will start to impact your code in the negative if you try to support both .net framework as well as the newest .net 6+ (although we kind of have that issue already with using netstandard 2.0).

I think in some other discussion we already came to a conclusion that any support for .net framework would be best effort for any new features. And I think you came to that conclusion yourself as well?

[Code-Grump]

Speaking for nullability, I think you're referring to nullable reference types, which is fortunately a C# language feature, rather than part of a platform target: you can have nullable reference analysis enabled/disabled independently of platform targets. It shouldn't be a factor in this decision.

Absolutely agree about needing to have #if blocks to include/exclude code for specific targets. In my experience, you don't need much, because most of the code runs on every target, but there will be places where we will want to exclude something (like a class that handles the new DateOnly type) from being included in .NET Standard 2.0 build.

Support for .NET Framework is definitely relegated to "best effort", and I interpreted that to mean still producing new versions, but maybe not every feature is available there. If we decided to only target .NET 6 (for example) there would be no new versions compatible with .NET Framework - a situation I'd personally feel bad about.

[ajeckmans]

That is not entirely true. Some of the methods and types have gained nullability annotations in later .net versions. Once you start multi-targeting you will come across them. Even from 6.0 to 8.0 you will get slight differences that will require you to ifdef your way out if you have nullable turned on.

We have two in-house nuget packages where we came across just that btw. They target net472, 6.0 and 8.0.

See also https://www.roji.org/nullable-reference-types-with-old-tfms for just one example.

[Code-Grump]

Ok, I've not personally encountered this issue in my projects. Worth bearing in mind if we plan to enable nullable analysis in the future, multi-targeting will make that more complex.

[gasparnagy]

We had another related problem with the cucumber messages and the System.Text.Json cucumber/messages#237. So there are several problems now related to this.

Thinking it over once more: In my opinion, we should try to get a stable version with all the super important features we need (living doc, roslyn code gen, redesign conversions) and then we can stop supporting .NET Fw with newer versions (but only release bug fixes). Hopefully this is finished by the end of the year latest, so from 2025 on, we can switch to support .NET 6+.
(So we don't waste our energy with workarounds, #if-s and multi-target issues.)

[gasparnagy]

Yes, that makes sense, but at least from .NET Core, the official support periods are much shorter than .NET Fw ones. So for example, the .NET 6 support period ends in Nov 12, 2024 (.NET 7 ended already in May). So essentially in 2025, the minimum we can support is .NET 8.

It can happen that we still need to find some better solution for this ongoing problem, but the situation will be easier for sure.

[ajeckmans]

For some things like the dateonly converters we can make a plugin or some kind of regular nuget package to add support for the latest framework.

That way we can still target the latest LTS whilst also supporting the newer features.

[Code-Grump]

I feel like multi-targeting is less effort than maintaining plugins for new language features, and has a much more natural maintenance lifecycle: at some point the conditional blocks aren't needed any more.

I definitely don't feel great about simply stopping the release of .NET Framework-compatible versions either. If we need to push out bug-fixes, is that going to be a separate project, like a fork?

These feel like things that multi-targeted builds were explicitly intended to solve and I'm surprised at the push-back.

[ajeckmans]

I'm not against multi-targeting. I am proposing alternatives and listing some of the drawbacks so we can compare all of the choices and come to the right conclusion.

And there definitely are some drawbacks or gotchas involving multi-targeting. BTW we're already multi-targeting in the verify plugin, because of what Verify itself does, so it won't be totally new for this codebase.

[gasparnagy]

We were multi-targeting for long time (also SpecFlow was) and I killed that a few months ago. 😎

Besides the longer compilation time, the main problem with multi-targeting is that all plugins that depend on Reqnroll has to be multi-target too, and this causes an quite some additional complexity, as the plugin providers have to somehow manually ensure that the right platform version is copied. It was a real pain and it blocked people of writing plugins or caused extra support efforts to help them.

So if I would need to choose between maintaining a plugin for DateOnly until 2025 (afterwards we can deprecate it) or switching back to multi-targeting, I would choose the first. (But of course the users can make their converter for DateOnly in a few minutes for themselves anyway, so even the need for a plugin is questionable for me.

We should be careful when planning for future changes. Currently we talk about minor childhood-issues (like lack of DateOnly or not correctly annotated nullable classes). These seem to be one-time problems, so it can happen that from .NET 8 on there will be less platform changes that are relevant for Reqnroll. So would be good to see more before getting back to the complexity of multi-targeting.

BTW: can't we just register a converter for DateOnly using reflection? I mean like checking if that type exists (or even checking if runtime is .NET 6+) and register the converter that calls DateOnly.Parse or whatever method is needed. Once we are .NET 8+, we can revert this code to use direct method calls.

[obligaron]

Dropping .NET Standard / .NET Framework support can affect users of the library, not just plugins.

For example, a .NET Standard library that needs to run under .NET 8 and .NET Framework runtime.
It uses Reqnroll for testing and has a multi-configuration test project that compiles to .NET 8 and .NET Framework.
This ensures that the library works correctly with both runtimes.
If Reqnroll drops .NET Standard support, these libraries would have to stick with the old Reqnroll version or stop testing the .NET Framework runtime.

[Code-Grump]

That's a great point - there are plenty of class library projects that target .NET Standard 2.0 and want to test against .NET Framework. We have to remember they're included in the impact of stopping releases that are compatible with .NET Framework.

[gasparnagy]

Finding the right time for this step is pretty hard and we have to be very careful with that indeed.

[Romfos]

Multitargeting works if you have mostly consistent codebase, probably with some 1-2-3 #Ifdef, but for reqnroll case this will be hard to support, because it will be massive and we still will have a lot of limitations with latest feature support

I don't recommend go this way

I would recommend to do it in a following way:

1. Define latest version with .NET Framework support (for example 3.x version)
2. Continue support version 3.x in a separate branch
3. In main branch switch to net8.0 tfm for the most projects and update version (for example 4.x version)

What problem solves this approach:

1. No massive #ifdef problem. We have single and consisted code
2. We can support all new .NET features without limitations
3. No problems like 'we don't want to use system.text.json (or user old version) because this is external dependency and could affect NET Frameowrk consumers and bla-bla-bla'
4. We can track via nuget statistic - how much users are really using net framework supported versions versus never version, by tracking download statistic by version filter.

Support flow for 3.x branch:

1. We accept bugfixes, dependency updates if needed, security fixes, new visual studio support updates via PRs
2. Update minor version
3. Release to nuget new minor version

My expectation is that year by year downloads will go down comparing with current version. We can track popularity for this via nuget statistic and probably after some years we can make a decision to drop this completely

[gasparnagy]

@Romfos thx for the insight. This is also the strategy that I have imagined. For me the big question is what is the right time to do this.

Most of the SpecFlow users have not migrated yet and I expect a few more migration related issues that would be easier to fix before the big branching. On the other hand, we are ready to move on with interesting new features, like the Roslyn based generation and for these targeting .NET 6+ would make the things easier.

There are also third party Reqnroll plugins, so they would need to follow the same branching strategy in order to support the .NET Framework users.

Also the note from @obligaron earlier is pretty important: if anyone want to use Reqnroll to test a .NET Standard library for both .NET 8.0 and .NET Framework, they can only do this if we also target .NET Standard.

My point here is to wait until end of 2024 and review our usage statistics after that. By that time probably more of the SpecFlow projects will migrate.

[Romfos]

This table represent happiness for arch category of users:

Solution	.NET Framework user(up to 20% users)	.NET Core user(80% users)	Multitarget user(up to 20% users)	Plugin developer	Reqnroll developer
Target .NET Standard 2.0	100%	50%	100%	100%	100%
Target .NET 8	5%	100%	5%	100%	100%
Multitargeting: .NET 8 + .NET Standard 2.0	100%	75%	100%	75%	25%
Branching: .NET 8 + .NET Standared versions	50%	100%	50%	25%	75%

In case of @obligaron case - need to use this version with .NET Standard from branch.

@gasparnagy
Sound like a plan. No need to rush with it

[Romfos]

Some insights about this topic:

This is Automapper nuget package statistic for last 6 week
https://www.nuget.org/stats/packages/AutoMapper?groupby=Version

Points:

1. Latest version 13 target .NET 6 => don't support .NET Framework
2. Version 11 and 12 targets .NET Standard 2.1 => also don't support .NET Framework
3. Version 10 is the latest that targets .NET Standard 2.0

as you can see - most downloaded version - version that support .NET 6. Still have some popularity version with .NET Standard 2.1 (.NET Core 3+ runtimes).

Version with .NET Framework support (has .NET Standard tfm) is around 20% downloads (comparing with 11+12+13 versions)