codebude
[WIP/QRCoder2] Which frameworks and language version to target
Note: This issue is part of the planning of version 2 of the QRCoder. The meta-issue can be found here. These comments have been copied into this issue here, with the comments marked as such. If comments on the topic of this issue already exist in the meta thread, they have been copied here, naming the authors.
Topic
The current version of the QRcoder (1.X) supports a whole range of target frameworks. Among them also quite old versions like .NET3.5. Which frameworks do we want to target in QRCor version 2 and why (pro/contra)?
For QRCoder 2.x, I would target no less than .NET Standard 2.0. This is in line with Microsoft's example (most of their libraries are still .NET Standard 2.0 compatible) and their stated recommendation:
https://learn.microsoft.com/en-us/dotnet/standard/net-standard#when-to-target-net80-vs-netstandard
Having a target of .NET Standard 2.0 as a minimum allows near-maximum compatibility with both .NET Framework and other targets, such as the Wilderness Labs Meadow F7 system-on-a-module (which now runs .NET Standard 2.1 code).
I would also have a minimum of testing for currently supported and the last couple unsupported LTS versions of .NET. For instance: .NET Framework, .NET Core 3.1, .NET 6.0, .NET 7.0, .NET 8.0.
Personally I would retain compatibility with older frameworks, until if/when we run into problems developing. For instance, if the next version of Visual Studio cannot compile for .NET Framework 3.5, then I would drop it. QRCoder v1.x works well and can be used for .NET Framework 3.5. I also would be fine dropping testing on these older frameworks.
I also would be fine dropping testing on platforms that do not have a compilation target. As an example, if .NET Core 2.1 and 3.1 both use the same .NET Standard 2.0 compilation target/output, we really shouldn't need to test on both platforms. But if it's easy to test on more platforms, it doesn't cost anything, so why not?
I would mark the assembly as trimmable and add some very basic testing for NativeAOT, if we can. This should require almost no effort (as the project does not use reflection) and allows for QR codes to be generated on NativeAOT compilation targets, webassembly / Blazor, and so on.
Originally posted by @Shane32 here.
I suggest upgrading to the latest C# language features via <LangVersion>latest</LangVersion>. This means that we need to be careful to not to use features like init-only properties which will break older targets. But some things like file-scoped namespaces are very nice to use and do not change the compiled code at all.
Originally posted by @Shane32 here.
For which .NET version to target, I think we should always target the latest version of .NET just like Microsoft does with all their nuget packages. You want to use version 8 of Entity Framework Core, you need .NET 8. I also think their nuget verisoning makes the most sense. All the package go together, like that you know that there was a change.
Originally posted by @emorell96 here.
Version 1.x will retain compatibility with:
- .NET Framework 3.5
- .NET Framework 4.0 and newer
- .NET Standard 1.3 and newer
The above implicitly include all .NET Core versions. Version 1.x does not include renderers where underlying support is not available, such as ArtQRCode on Linux. You may be required to target a Windows variant (e.g. net8.0-windows) to have access to all renderers.
Version 2.x will be compatible with .NET Standard 2.0. This includes:
- .NET Framework 4.6.2 and newer
- .NET Core 2.0 and newer
Version 2.x will split renderers into separate NuGet packages, so that both Linux and Windows support is available for all renderers.
Version 2.x will be designed with trim support in mind, enabling use in both NativeAOT and WebAssembly scenarios.
