/t:Pack /p:Version not handling dependency versions

[nguerrera]

From @dazinator on June 8, 2017 14:8

Given a solution with two projects, "Foo.csproj" with a project reference to "Bar.csproj"

When doing an msbuild My.sln /t:Pack /p:Version="1.0.0-alpha"

Foo produces a nuget package version "1.0.0-alpha"
Bar produces a nuget package version "1.0.0-apha"

Inside the nuget package for Foo is a nuspec file, with Bar listed as a dependency (correct). The version of that dependency shows as 1.0.0. This is incorrect. When these nuget packages are published to a feed, and Foo is then installed by a client - the client will complain that Bar version 1.0.0 doesn't exist on the feed, or perhaps it does exist by coincidence and it will be downloaded even though it's not actually the correct version for the dependency.

The dependency package (bar) was produced with a Version number, and therefore when a dependency element is generated in foo's nuspec, for the 'bar' package, that element should honour that version number, not be left as 1.0.0 which is incorrect.

Do you have any other suggestions as to how to overcome this limitation in the short term? Perhaps there is something I am missing? I would prefer not to have to manually create and maintain nuspec files to fix this as that's quite a big overhead for some of our solutions that have upwards of 50 projects each.

Copied from original issue: dotnet/sdk#1320

[emgarten]

@dazinator you need to pass the same additional parameters to restore and build.

msbuild My.sln /t:Restore /p:Version="1.0.0-alpha"
msbuild My.sln /t:Pack /p:Version="1.0.0-alpha"

Pack reads version and dependency information from project.assets.json which is created by restore.

Going forward this will be fixed in dotnet CLI 2.0.0, pack will automatically call restore with the same properties.

[bording]

@emgarten What about the following scenario:

• Something like GitVersion is used, which adds a target to dynamically determine version numbers during Build
• The projects are using <GeneratePackageOnBuild>true</GeneratePackageOnBuild>

Will the restore happen correctly between the build and the pack so that the newly updated version will correctly be picked up?

[emgarten]

@bording no, dependency packages are not allowed to change the identity of the project being restored or it's dependencies since this would cause the 2nd restore to give different results than the first restore. GitVersioning is a common request, we're looking at ways for packages to plug in and contribute before restore to solve this.

#4790

[bording]

@emgarten Thanks, I'll follow that issue for additional progress. This is definitely an important scenario to support!

[rohit21agrawal]

also, closing this as dupliacte of : #4337