Remove unnecessary System.Text.Encoding.CodePages ref from NET 6+

[lahma]

Types of Changes

Prerequisites

Please make sure you can check the following two boxes:

• I have read the CONTRIBUTING document
• My code follows the code style of this project

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• Breaking change (fix or feature that would cause existing functionality to change)
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

Description

NET 6+ doesn't need explicit reference to System.Text.Encoding.CodePages as it's part of runtime libraries. This trims down dependencies. I've changed minimum from NET 4.6.1 to 4.6.2 as it's the oldest supported FW platform and even Microsoft libaries aren't guaranteed to work with 4.6.1 (like Unsafe).

[FlorianRappl]

I am not sure this is part of the runtime / correctly handled if its removed. In the past we explicitly added it as not having the dependency resulted in some more exotic codepages not found; this is nothing that can be directly seen - you need to have a dependency on such a codepage to have the one missing.

I would be all for removing, but I first need confirmation that this fully and reliably works when we remove it. Unfortunately, .NET is not really well thought out in that area.

[lahma]

I am not sure this is part of the runtime / correctly handled if its removed. In the past we explicitly added it as not having the dependency resulted in some more exotic codepages not found; this is nothing that can be directly seen - you need to have a dependency on such a codepage to have the one missing.

I would be all for removing, but I first need confirmation that this fully and reliably works when we remove it. Unfortunately, .NET is not really well thought out in that area.

Older platforms will get 6.0.0 (explicit reference), NET 6.0.x will get 6.0.x - NET 7 will get 7.0.x - NET 8 will get 8.0.x - as they are inbox.

[FlorianRappl]

Well, that unfortunately does not answer my concern. As mentioned (and please use the search for this) we had the situation beforehand. There have been bug reports and other issues - these all went away when we have the dependency explicitly mentioned.

If its part of the framework / of the existing assemblies then I don't see any problem here; NuGet should not download the dependency.

Just to re-iterate: I would love to remove it, but I need confirmation that no bugs will occur due to that.

[lahma]

Yes so far what I've read/understood from searching the issues it's always on full framework where you naturally need to have a package reference with a version minimum of what is supported. The explicit separate nuspec file can make things harder to understand compared to running dotnet pack -c Release which will then validate that the code compiles with given references and produces a nuget package that is valid:

[FlorianRappl]

The thing with dotnet pack is that it unfortunately does not cover the full range of spectrum that a nuspec does. It's another issue in .NET that I would think they should have fixed right away. Why have multiple ways if they are all providing different pros and cons? Just having a csproj and making the NuGet based on this (either via dotnet pack or by having the package created automatically at build) is just much better.

[lahma]

I could also investigate if it would be possible to produce identical nuget package via csproj approach (removing the separate nuspec), I think this would make things more discoverable and easier to understand.

[lahma]

I could also investigate if it would be possible to produce identical nuget package via csproj approach (removing the separate nuspec), I think this would make things more discoverable and easier to understand.

Looking at the current nuspec files, I would argue that they could quite easily be replaced with csproj configuration, if wanted.