Dependent packages version numbers are not updated correctly.

[nguerrera]

From @livarcocc on February 7, 2017 0:50

from @niemyjski at https://github.com/dotnet/cli/issues/5596

I was running my build with dotnet build -f net46 Foundatio.sln /p:VersionPrefix="$($env:APPVEYOR_BUILD_VERSION)" /p:VersionSuffix="$($env:VERSION_SUFFIX)" to update the predefined version properties (https://github.com/exceptionless/Foundatio/blob/73b8ee68d611d1521e48eadac1101ea054115e6c/build/version.props). This seemed to create the nuget packages with the correct version numbers but I noticed that packages (project references) didn't have the correct version numbers.

You can see it here (https://www.nuget.org/packages/Foundatio.Redis/4.3.1280), once I started updating the version.props file on disk as a pre build task and stopped updating the properties as a parameter the issue went away as you can see here https://www.nuget.org/packages/Foundatio.Redis/4.3.1282

Copied from original issue: dotnet/sdk#824

[nguerrera]

From @piotrpMSFT on February 7, 2017 10:4

Since it's a bit hidden, @niemyjski's project uses the <GeneratePackageOnBuild> feature.

That feature comes from the NuGet.Build.Tasks.Pack package [so the issue belongs in the NuGet repo] but I took a quick look and found:

  <Target Name="_PackAsBuildAfterTarget"
          AfterTargets="Build" 
          Condition="'$(GeneratePackageOnBuild)' == 'true' AND '$(IsInnerBuild)' != 'true'"
          DependsOnTargets="Pack">
  </Target>

Note the second clause of the condition. This only triggers when we're doing an outer build which has two implications:

• If -f is specified then I'd not expect the packages to be produced. Are we sure we're not seeing packages from some other build?
• Doing partial package builds via this mechanism doesn't seem like it should work

We'll need to run a /v:diag build to see what's really going on...

[nguerrera]

From @neilhuiz on February 8, 2017 18:18

Not sure if this counts as a hack or not, but you can use dotnet pack mysolution.sln "/t:Restore;Pack" "/p:Version=$($env:APPVEYOR_BUILD_VERSION)-$($env:VERSION_SUFFIX)" to get all the packages in a solution to use the same version number. This also makes the references between packages agree as to the version and suffix. I'm not sure what to do if you have multiple versions within your solution.

Be aware that this will produce packages for all projects in the solution so even your test projects or the like will get packaged.

[nguerrera]

From @niemyjski on February 8, 2017 18:26

@neilhuiz @piotrpMSFT I have a even bigger problem since updating to the latest RC... Now when I run this same build command dotnet build -f net46 Foundatio.sln doesn't build any packages with GeneratePackageOnBuild.

I need to figure this out asap.

[nguerrera]

From @piotrpMSFT on February 13, 2017 3:14

@rohit21agrawal take a look

Looking at the targets, <GeneratePackageOnbuild> only takes effect if we're doing an outer build so no -f is specified.

@niemyjski I think you are trying to take advantage of a scenario that is not designed for in the NuGet targets. I would open an issue on nuget/home describing why you need to build packages for specific frameworks and perhaps @rohit21agrawal + team can help out.

[nguerrera]

From @rohit21agrawal on February 13, 2017 15:45

as i said earlier, having both TargetFrameworks and TargetFramework set would not trigger a Pack because it considers it to be an inner build. To workaround this, use : dotnet build /p:TargetFrameworks=net46 Foundatio.sln

[nguerrera]

From @rohit21agrawal on February 13, 2017 15:46

As far as dependent packages are concerned, Pack reads the project references version from the assets file. So whatever is written out to the assets file is what is written out in the output nuspec as well. @neilhuiz gave the right way to get the right package versions for your project references.

[nguerrera]

From @hrannzo on March 16, 2017 10:35

I'm having a similar issue when using GitVersionTask to calculate the version (2016.1.3 in this case) I manually converted .net 4.6 class library to the new CSproj format.

Project A has a PackageReference on project B msbuild /t:pack produces A.2016.1.3.nupkg and B.2016.1.3.nupgk, the assemblies are also stamped with the correct version information

When I look at the nuspec in A.2016.1.3 the dependecies look like this:

<dependencies>
  <group targetFramework=".NETFramework4.6">
    <dependency id="B" version="1.0.0" exclude="Build,Analyzers" />    
  </group>
</dependencies>

The lock file (project.asset.json) behind A has the following library reference on B

"B/1.0.0": {
      "type": "project",
      "path": "../ProjectB/B.csproj",
      "msbuildProject": "../ProjectB/B.csproj"
    }

And the dependencies

"projectFileDependencyGroups": {
    ".NETFramework,Version=v4.6": [
      "GitVersionTask >= 4.0.0-beta0011",
      "B >= 1.0.0"    
    ]
  }

Since msbuild /t:pack reads the lock file as-is when generating the nuspec, shouldn't it be updated to reflect the newly generated versions for project references after build?

[rohit21agrawal]

@hrannzo i am not seeing the discrepancy here. the lock file says the version of package to be >=1.0.0 and the nuspec file says the same thing. am i missing something?

[hrannzo]

@rohit21agrawal - My issue was that the packages themselves where versioned correctly with the generated GitVersion (A.2016.1.3.nupkg and B.2016.1.3.nupkg) but A's dependency on B did not reflect B's version. I would have expected the dependency version should have been >= 2016.1.3

[Galad]

Isn't it a duplicate of #4790 ?

[emgarten]

Duplicate of https://github.com/NuGet/Home/issues/4790