PackageValidation task cannot find nuget package due to version normalization
See original GitHub issueI tried the new SDK feature following the example at https://devblogs.microsoft.com/dotnet/package-validation/#validation-against-baseline-package-version.
I am getting an error from the task complaining the nuget package has not been found:
Error MSB4018 The "Microsoft.DotNet.PackageValidation.ValidatePackage" task failed unexpectedly. System.IO.InvalidDataException: The file is not a valid nupkg. File path: bin\Debug\*******.2.0.0.0.nupkg ---> System.IO.FileNotFoundException: Could not find file 'bin\Debug\********.2.0.0.0.nupkg'.
If I look into the bin\Debug
folder I see the nuget package file, but it has a normalized version of 2.0.0
although I explicitly set <PackageVersion>2.0.0.0</PackageVersion>
.
If change the PackageVersion to either 2.0.0
or 2.0.0.1
it works as expected.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (2 by maintainers)
Top GitHub Comments
Thanks for reporting @smkanadl. I just submitted a PR that will fix this by using a similar approach as what @cdonnellytx shared.
A similar discrepancy in NuGet package filename also occurs if you are using “full” semantic versioning (e.g.
PackageVersion=1.2.3-alpha.1+2
). The package file generated (at least in Windows, by MSBuild) appears to bebin\Debug\1.2.3-alpha.1.nupkg
, not including the+
.I dug into the SDK targets for dotnet (5.0.301, win-x64) and it looks like the first entry in
@(NuGetPackOutput)
is what is desired, with target_GetOutputItemsFromPack
being responsible for what is altering the expected filename.(I discovered this by using the GitVersion.MsBuild task; the trick is to have unstaged changes out where the currently committed HEAD is not on a tag.)
Update: I found a way to extract it, assuming the output order from
GetOutputItemsFromPack
is stable and is alwaysxxx.nupkg;xxx.nuspec
:Reference