Why is not the version of a NuGet published library enforced to be the same as the version in the assembly?

[TomasJohansson]

I have checked some assemblies I retrieved with NuGet.
The version number published at NuGet seem to usually correspond to the version you can see in windows explorer when rightclicking the DLL file, or when programmatically checking the assembly version (with 'typeof(someClass).Assembly.GetName().Version' and its properties Major/Minor/Revision).

However, for some reason, it does not seem to always be like that, for example not when you look at this library:
https://www.nuget.org/packages/MightyLittleGeodesy/1.0.2
The version at NuGet is 1.0.2 but when you look at the DLL file's properties, or using the above mentioned Assembly reflection, the version is instead displayed as 1.0.0.

I think this mismatch of versions should have been possible to prevent, i.e. in this example when the user pushed that "1.0.2" version to NuGet, it should have been possible to retrieve the actual assembly version "1.0.0" from the file but since there already was a version "1.0.0" published and with another file size and hash (e.g md5, sha256) then it should have been rejected with an error message saying that the version in the DLL must be updated with a higher number.

Maybe I have misunderstood something about version numbers.
Is the published version number at NuGet supposed to be the same as the version number in the assembly?
If so, then why is it not enforced? Not possible for some reason?

[zivkan]

Perhaps we can turn the question around and ask why should NuGet enforce the assembly version to be the same as the package version? What problem would it solve?

As for reasons why NuGet shouldn't enforce it, I can think of a few possibilities:

Some people create packages of other people's code. If they find an issue with their package and want to create a new package with the same assembly, how could they do that if they're limited to using the 3rd party assembly version as the package version?

Some package authors, Newtonsoft.Json is the most popular, intentionally use the same assembly version across multiple package versions. For example, all 13.0.x packages use assembly version 13.0.0.0, all 9.0.x packages use assembly version 9.0.0.0. This helps reduce assembly load errors from missing binding redirects on .NET Framework, when different projects in the solution reference different versions of Nuget. Things are a lot better now with PackageReference and automatic binding redirect generation. But (non-Core) ASP.NET uses a web.config in the project directory, not a generated file in the bin\ directory like all other projects, which limits it to packages.config to use nuget's install-time attempt at binding redirect generation. It's not uncommon for ASP.NET developers to have to resort to manual binding redirect editing when NuGet's tooling can't handle whatever situation they're in. Newtonsoft.Json's approach of using the same assembly version for all releases with the same major version makes this a lot less problematic.

Assembly versions are strictly a.b.c.d, with each of these 4 segments being integers, while package versions are SemVer2 extended to be compatible with System.Version's 4 segments (so 1.2.3.4-abcdef.7.8.9.whatever is valid). If NuGet was to enforce package version == assembly version, would this mean we should not allow SemVer prerelease versions any longer? Or if we do, what should the assembly versions of 1.0.0-beta, 1.0.0-beta.2, 1.0.0-rc be?

Some packages contain multiple assemblies. Should all of the assemblies be forced to have the same version? That really wouldn't work for .NET tools. If my tool depends on Newtonsoft.Json, it's going to be a huge problem if my assembly and package version must match Newtonsoft.Json's version, especially when I want to implement new features, or fix a bug, while using the same version of that dependency. Having more than one dependency would become impossible.

Anyway, while I've been frustrated in the past, and I'm sure I will again in the future, when someone is using NuGet in a way I would argue it was never designed for, and therefore when we change something for a feature or bug fix, this introduces a problem for this customer's custom solution, the point is that customers are solving their business and/or technical problems using tools like NuGet in creative, non-standard ways. If we add restrictions without good reasons, it will make those people's lives more difficult, as they'll have to find a different, possibly more complex, way to solve their problem. So, I think there would need to be a very good reason to add restrictions, such as package/assembly versions, and prevent everyone else from doing something that I haven't imagined they'd want to do.

[TomasJohansson]

I thought it was confusing with mismatching version numbers, but no I can not provide very good reasons to add restrictions which would outweigh the opposite considerations you have written about above.
Thank you for your comprehensive answer.