Wrong dependency versions in the NuGet package after 'dotnet pack' if the project hasn't been rebuilt before #4867
Labels
Resolution:Duplicate
This issue appears to be a Duplicate of another issue
From @DmitrySikorsky on March 15, 2017 22:56
Steps to reproduce
You are using VS2017 and .csproj files.
Let's say you have ProjectA version 1.1.1 that has dependency (project dependency with no version specified) to the ProjectB version 1.1.1. You rebuild them and everything is fine.
After that you remove 'bin' and 'obj' folders, open the .csproj files and change (manually, in a text editor) VersionPrefix to 1.1.2. Then run 'dotnet pack'. If you open the resulting ProjectA.1.1.2.nupkg file as the archive and look at .nuspec file you will see, that ProjectB dependency version is 1.1.1, not 1.1.2!
If you remove 'bin' and 'obj' folders again, open solution in the VS2017 and rebuild, then run 'dotnet pack' and open .nuspec file again, you will see that the dependency version is changed to 1.1.2.
Is it by design? I have created .bat files to pack and then push to nuget and I have never had this behavior before (when used project.json files). So it seems to be not obvious.
I have found this when pushed the packages to the NuGet and then got 'The located assembly's manifest definition does not match the assembly reference' exception when tried to use them. As I have found, both 1.1.1 and 1.1.2 versions are downloaded (1.1.2 are downloaded as primary dependency and 1.1.1 as secondary ones).
Thank you!
Copied from original issue: dotnet/cli#6049
The text was updated successfully, but these errors were encountered: