Why do we need to complile Reqnroll to multiple platform targets and not only .NET Standard 2.0?

[gasparnagy]

@SabotageAndi maybe you know the answer for this...

[SabotageAndi]

Two reasons:

1. NuGet.org
   NuGet.org displays the direct supported .NET Frameworks and gets this information out of the files in the package.
   

We didn't wanted to put .NET Standard 2.0 Assemblies in the net462 folder.

2. Package References:

Because of assembly loading issues and I think newer packages dropped .NET Framework support, we needed different References and PackageReferences for .NET Framework and .NET Standard.

[gasparnagy]

Thanks for the quick info.

Based on that, I would reconsider this with the current state of the frameworks. We definitely need to keep the .NET Framework support for a while, but it will slowly fade out. I can even imagine that at some point we will add features only to the .NET "core" version and support the .NET Framework version only with bug fixes. We need to measure the usage stats carefully to see when is the good time for this, but not in the next 6 months for sure.

Having the core package compiled to multiple targets causes an extra panalty for testing (all framework combination has to be tested), but even more importantly, any packages that depend on the SpecFlow core (e.g. "Actions") has to be multi-targetted. It is a kind of avalanche of complexity.

Of course this would need to be tested carefully and rewise if there is a technical issue (e.g. assembly loading).

What do you think?

[SabotageAndi]

At SpecFlow we always said we support that what Microsoft is supporting.

[SabotageAndi]

As our resources are limited
@gasparnagy which ones?
Do you run out of GitHub Actions minutes?
The 10 build agents we got on Azure DevOps were always sufficient.

[gasparnagy]

No, I mean the time of the contributors.

[SabotageAndi]

Ok, that's your decision. We spend a lot of time that SpecFlow works in all the possible combinations (.NET Frameworks, Program Languages, Test Runner, OS), because it was used in that way by the end users.
All contributions (features, bugfixes) had to work also on all combinations.

[gasparnagy]

@SabotageAndi I think there is a misunderstanding here. I didn't say that we don't want to support the .NET framework. But as @Code-Grump very well said, the question is whether we provide a "first-class" support vs. "best efforts".

For example, let's imagine we drop framework support from v6. Still, we can keep a v5 product line (separate branch) and provide the framework users with security patches and framework updates. I see this as a win-win, because we are not hindered by the double framework problem for feature development, but still the framework users get the security. And of course, if there is someone who want to port back a feature to v5 - feel free. I don't see any problems with this and it is easy to cummunicate.

This is exactly the same BTW what Microsoft did. They realized that they cannot turn the framework to portable, so they made a new product line with .NET Core and since then the rapid development is only available there, the framework only gets the "best efforts".

Sorry for repeating this mantra again and again (don't worry, I keep repeating this to myself as well), but it is a different situation now, and we have to learn that things that we considered as "unquestioned" have to be questioned now. We don't have a company in the background who get marketing benefit with supporting all the different combinations (or get marketing loss if we don't). Our most important value is the time the contributors put in, and we have to be very careful of how we use this value.

I hope this made it clearer.

[DomZZ]

Why not asking to users to move to .NET, it should not be very hard !?
I did it myself and it just a matter of hours !
If you want that this project go for long time, then you need to make it simple !

[gasparnagy]

@DomZZ I don't think there is a generic answer for this, but the concrete examples I have seen of upgrade issues were related to dependencies that were not upgraded yet. For regulated systems, such change automatically triggers a re-audit of the whole system, that might take very long time. So it is not (only) laziness... This is why MS keeps providing support for these old frameworks.

[SabotageAndi]

@DomZZ: My team and I work on a lot of projects for various public sector organizations and about 3/4 are still on .NET Framework.
And they will never migrate to .NET (Core) because of budgeting.
The applications work for them and there is simply no reason to switch to .NET. So there is no money for this migration.
New stuff is .NET, but all the old stuff will stay on .NET Framework for ever.

[ajeckmans]

Well that is not the reason. The reason is that .NET Framework is a component of Windows 11 and thus follows the same support lifecycle (Mcrosofts Modern Lifecycle Policy). What does that mean? Well.. Whenever Microsoft releases a new version of Windows 11 the support end date is moved up by approximately two years (they have a one year advanced notice to drop support).
As it stands now, when 24H1 is released in April this year, the support end date for .net framework 4.8.1 will be set to April 2026 as I doubt Microsoft will continue development under the 11 flag, and likely will end support when 12 is a year or so underway.

So in short, Microsoft supports it because it needs it in Windows and thus obligated itself to supporting it. But where it used to guarantee 10 years of support in the past, they stopped doing that with .net 4.5 or so (and with good reason).

[DomZZ]

Well I understand your arguments, but those companies will move on if they have to.
Another option is to support .NET Framework only for customers that pay for it ...

• One repo for Reqnroll for .NET
• One private repo for Regnroll .NET framework

So they have the choice to move on .NET or to pay to have .NET framework support.

I'm just afraid that you will be tired to do and drop the project because it is too much work for you :)

[gasparnagy]

@DomZZ Thx for the concern. This is absolutely valid and it is clear that the overall project sustainability is more important than the support of the .NET Framework. So let's keep this in mind and come back to that when the first problem comes up that causes significant efforts for supporting .NET Framework (or would not work on .NET Framework).

For me the initial question was not about whether we keep the .NET Framework support, but whether we need the multi-target project compilation for that (that is definitely an overhead). So far it seems that in principle the single target compilation (to .NET Standard) would be enough, so I will make this as one of my next task to try.

[gasparnagy]

I did the hard work of cleaning up all the dependencies and the project compilation targets and the result is much simpler now. You can find more details at the PR: #130

[robertcoltheart]

To tag onto this, could you also consider supporting net6.0 or similar as a separate TFM? That would allow the use of things like DateOnly, TimeOnly as value comparers etc. For now, we have to recreate all of these comparers/converters in each of our projects. It would be nice to have those baked into the main framework.

[gasparnagy]

@robertcoltheart This is a good point. I have just removed the multi-targeting and really enjoy the simplicity of the single target 😀, so I would keep this as it is now. However, we could make an extra package for net6-only comparers until we need to support .NET 4. Could you please create a separate topic for that here in the ideas section of the discussion board so that we will not forget that?

[gasparnagy]

The PR #130 was merged, so I close this discussion topic for now.