Update target frameworks

[Joy-less]

Changes the target frameworks from (netstandard1.3, netstandard2.1) to (netstandard2.0, netstandard2.1, net8.0, net9.0).

Targeting netstandard1.3 is no longer recommended by Microsoft since the frameworks compatible with netstandard1.3 but not by netstandard2.0 are long out-of-support.

Targeting net8.0 and net9.0 should give performance benefits.

Also updates the test project packages.

[mqudsi]

Thanks for the initiative, but the target frameworks have been carefully chosen.

netstandard1.3 is the newest target that is supported for UAP apps (deprecated but still in use by many). I'm not aware of any benefits in targeting net8.0, net9.0 when the code doesn't take advantage of any of the apis exclusive to those targets; the netstandard2.1 target would be compiled and uploaded to nuget using the latest version of the sdk and should see the same codegen benefits that a net9.0 target would, if I'm not mistaken.

[mregen]

I tried to test your library and I am getting errors due to transitive vulnerabilities, I presume because of the dependency on netstandard1.3 which is out of support:

Restoring packages for ***.Tests.csproj...
  CACHE https://api.nuget.org/v3/vulnerabilities/index.json
  CACHE https://api.nuget.org/v3-vulnerabilities/2025.11.19.23.31.42/vulnerability.base.json
  CACHE https://api.nuget.org/v3-vulnerabilities/2025.11.19.23.31.42/2025.11.21.05.31.46/vulnerability.update.json
NU1903: Warning As Error: Package 'System.Net.Http' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-7jgj-8wvc-jh57
NU1903: Warning As Error: Package 'System.Text.RegularExpressions' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-cmhx-cq75-c4mj
Package restore failed. Rolling back package changes for '***.Tests'.
Time Elapsed: 00:00:00.3968220
´´´
I think it would be a good idea just to target more frameworks, as suggested. Thanks!

[drewnoakes]

Is there any upside to having net8.0 and net9.0 targets? I wouldn't expect there to be given there are no code changes here to use newer features.

[Joy-less]

In this case, because there are no dependencies and no conditional compilation, probably not much benefit, but not much drawback either except for a larger nupkg file. I can remove them if you like.

[drewnoakes]

Also slower builds when working in the repo, as internally MSBuild invokes itself for all target frameworks.

[drewnoakes]

Also slower builds when working in the repo, as internally MSBuild invokes itself for all target frameworks.

[mregen]

As a sidenote, the transitive vulnerabilities happen only because I build my test project also for .NET Framework. The best fix were to have a net462 build target.
I think there is a misperception regarding netstandardx.x These were API definition so technically there is no end of life. Problem starts only when .NET Framework starts to pull in netstandard1.x/2.0 libraries, I guess using a compatibility layer.

[mqudsi]

I tried to test your library and I am getting errors due to transitive vulnerabilities, I presume because of the dependency on netstandard1.3 which is out of support:

Visual Studio/nuget/dotnet/etc don't look at the netstandard1.3 target unless that is the most recent version of the api that your target framework supports. I believe there is some misunderstanding here.

[Joy-less]

@mqudsi I don't know about whether the test packages have vulnerabilities for .NET Framework, but it could arise if there are packages that are built for .NET Standard 1.3 in certain versions but in later versions only support a minimum of .NET Standard 2.0.

If my pull request will not be accepted as-is then I suggest the following targets:

• netstandard1.3 - If you would like to support UWP apps. Although I would think they probably support .NET Standard 2.0.
• netstandard2.0 - The de-facto "support everything" standard that supports both .NET Framework, .NET, and source generators.
• net10.0 - Optional but might be ideal after removing the netstandard2.1 target. There is no reason to target .NET Standard 2.1 instead of .NET Standard 2.0 and .NET 5+ anymore.