The Nuget package for System.Text.Encodings.Web v4.7.2 has the strong name of 4.0.5.1

[TimHannMSFT]

Description

Our library references System.Text.Encodings.Web v4.7.2. We had a user complain that our references are screwed up because we have something referencing System.Text.Encodings.Web 4.0.5.1.

On investigation it seems that while the registered version for 4.7.2 on nuget is correct, the strong name is 4.0.5.1. This seems like a bug to us. Is that possible to ameliorate?
https://www.nuget.org/packages/System.Text.Encodings.Web/4.7.2

This may be known or expected but I couldn't find reference in repo search or google search.

Reproduction Steps

1. Download the package from https://www.nuget.org/packages/System.Text.Encodings.Web/4.7.2
2. Note that when you open the package in NuGet Package Explorer you find that the strong name and the package version do not match
   

Expected behavior

We expect the package name and the strong name to match as it seems to in later versions of the library

(note it appears here too AssemblyFileVersion is different, perhaps that's expected)

Actual behavior

Actual behavior is as shown, there is a mismatch between package version and strong name.

Regression?

No response

Known Workarounds

We have asked the partner if they can simply reference a higher version of the library from their application and see if that can resolve for them. In our library we want to remain at the lowest secure version as we've had issues with snapping to the latest in the past (forcing downgrades and breaking some partners)

Configuration

No response

Other information

No response

[ericstj]

This is by design. We started out at 4.x in the early .NET Core days because it was evolving from the contract assemblies in .NETFramework and portable class libraries which were all versioned 4.0.X.Y. We then tried to follow semver from there - making minor version changes when API changed, making build changes for normal bugfixes, and servicing changes for servicing (until we could catch up).

We fixed the alignment as best we can in 5.0 when the product versioning could catch up with the assembly version.

Even with the alignment (and also before the alignment) - we still have to pin the Assembly version when an assembly overlaps with an inbox component like it does here. That's to ensure that we don't update the assembly version with inplace framework updates that need to be compatible. You'll notice this in the 6.0.n versions of System.Text.Encodings.Web where the assembly version of the netstandard2.0, netcoreapp, and net5.0+ assemblies remain at 6.0.0.0 while the netframework versions are 6.0.0.n.

Here are a couple related issues:
#26002
#13160

Hope this helps!