NuGetVersion produces incorrect System.Version if repeated zeroes are used

[JustinGrote]

Workaround: JustinGrote/ModuleFast#59

NuGet Product Used

NuGet SDK

Product Version

Nuget.Versioning 6.8.0

Worked before?

No

Impact

It's more difficult to complete my work

Repro Steps & Context

Using PowerShell but relevant in C# as well:

([NuGet.Versioning.NuGetVersion]'1.2.0.1').IsLegacyVersion
True #Correct

([NuGet.Versioning.NuGetVersion]'1.2.0.0').IsLegacyVersion
False #Should Be True

([NuGet.Versioning.NuGetVersion]'1.2.0').IsLegacyVersion
False #Correct

([NuGet.Versioning.NuGetVersion]'1.2.0').Version.Revision
0 #Should be -1

Verbose Logs

No response

[nkolev92]

IsLegacyVersion is defined as a non-0 revision.

NuGet treats "1", "1.0" and "1.0.0" as equivalent. Same applies to "1.0.0.0".

We explicitly normalize when the 4th part is 0.

[JustinGrote]

The problem here is when a package needs an install path that matches its version, e.g. 1.2.0.0, you provide no way to detect that outside of original string.

I don't see how you could make the argument that "1.2.0.0" isn't a legacy version when it explicitly has a 4th octet which does not exist in semantic versioning.

[nkolev92]

@JustinGrote

There's normalization at place to "minimize" the number of these 4 part versions. Instead of treating the 4th part as a legacy immediately, it's only used if the last part is non 0.

1.2.0.0 gets normalized to 1.2.0 at installation time.
1.2.0.0 will also get normalized at pack whenever possible.

The normalizations have been in place for a while.

[JustinGrote]

Some nuget consumers (PowerShell) don't see it that way. 1.2.0.0 and 1.2.0 are different. I will keep my workaround logic in place however given that this isn't going to change. Thanks for your time.