Dependencies via project reference are not having versions updated when performing a dotnet pack

[livarcocc]

From @KallDrexx at https:/dotnet/cli/issues/5984

Steps to reproduce

1. Go to a directory
2. mkdir test1
3. mkdir test2
4. cd test1
5. dotnet new classlib
6. Edit test1.csproj and add <VersionPrefix>1.0.1</VersionPrefix>
7. dotnet restore then dotnet pack
8. cd ../test2
9. dotnet new classlib
10. vim Class1.cs
11. Change class definition to public class Class1 : test1.Class1
12. Edit test2.csproj and add <VersionPrefix>1.0.0</VersionPrefix>
13. Edit test2.csproj and add:

  <ItemGroup>
    <ProjectReference Include="../test1/test1.csproj" />
  </ItemGroup>

14. dotnet restore then dotnet pack
15. Edit test1.csproj and change version to 1.0.2, then build and repack it
16. go back to test2 folder and update the version to 1.0.1
17. In test2 folder do dotnet restore then dotnet pack
18. Extract the test2.1.0.1.nupkg
19. View the .nuspec file

Expected behavior

Dependency should be listed as:
<dependency id="test1" version="1.0.2" exclude="Build,Analyzers" /> so that any nuget package built against the test2 library auto-restore test1 to 1.0.2

Actual behavior

Dependency is outdated and listed as

<dependency id="test1" version="1.0.1" exclude="Build,Analyzers" />

This is impacting us heavily right now as any time we build a nuget package it has outdated dependencies, which when restored on other projects causes FileLoadExceptions due to dotnet restore restoring an older dll.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/1.0.1

[emgarten]

@rohit21agrawal is pack reading the dependency version from the assets file or from the project directly?

[rohit21agrawal]

From the assets file

[emgarten]

@KallDrexx I'm not able to repro this, can you provide further steps?

The nuspec I get is:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>test2</id>
    <version>1.0.0</version>
    <authors>test2</authors>
    <owners>test2</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Package Description</description>
    <dependencies>
      <group targetFramework=".NETStandard1.4">
        <dependency id="test1" version="1.0.2" exclude="Build,Analyzers" />
        <dependency id="NETStandard.Library" version="1.6.1" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
</package>

Is it possible you missed the dotnet restore on test2 before packing?

Also, if you are still seeing the issue please provide the project.assets.json files from test1 and test2

[KallDrexx]

I will test again in a bit but looking back at your comment and the steps I think I wrote step 17 down wrong and it was probably only a dotnet pack and not a restore. A 2nd dotnet restore after changing a version number not common in my workflow after editing sub-projects in the same solution.

[KallDrexx]

yes I was correct, I did not run dotnet restore in step 17. The following shell script reproduces the issue for me:

#!/bin/bash

rm -rf /tmp/CodeTest
mkdir /tmp/CodeTest
cd /tmp/CodeTest/
mkdir test1
mkdir test2
cd test1
dotnet new classlib

echo '<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard1.4</TargetFramework>
    <VersionPrefix>1.0.0</VersionPrefix>
  </PropertyGroup>

</Project>
' > test1.csproj

dotnet restore
dotnet pack

cd ../test2

dotnet new classlib

echo 'using System;

namespace test2
{
    public class Class1 : test1.Class1
    {
    }
}
' > Class1.cs

echo '<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard1.4</TargetFramework>
    <VersionPrefix>1.0.0</VersionPrefix>
  </PropertyGroup>

  <ItemGroup>
  	<ProjectReference Include="../test1/test1.csproj" />
  </ItemGroup>

</Project>
' > test2.csproj

dotnet restore
dotnet pack

cd ../test1
echo '<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard1.4</TargetFramework>
    <VersionPrefix>1.0.1</VersionPrefix>
  </PropertyGroup>

</Project>
' > test1.csproj

dotnet pack

cd ../test2

echo '<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard1.4</TargetFramework>
    <VersionPrefix>1.0.1</VersionPrefix>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="../test1/test1.csproj" />
  </ItemGroup>

</Project>
' > test2.csproj

dotnet pack

cd bin/Debug/
unzip test2.1.0.1.nupkg
chmod +r test2.nuspec
cat test2.nuspec

The thing is, this workflow is natural to me. If you assume that this is a single solution with multiple projects (one being a common library and the other being an SDK/implementation library) when a code change facilitates changing something in both libraries I naturally increment the version in both projects after testing the change out. I then go into each folder and dotnet pack to create the nuget packages, upload them then commit the solution's changes to source control.

It doesn't make sense to me that I would have to dotnet restore test2 just because I changed the version number of test1, especially since it requires any developer to remember that they did indeed change the version of the referenced project.

Edit:
I just want to add that I never had this problem with project.json because project.json didn't seem to have direct project references and gave me warnings when versions were mismatched within the same solution. This isn't the case with the new csproj tooling.

[emgarten]

project.json didn't seem to have direct project references and gave me warnings when versions were mismatched within the same solution

With csproj there is no longer a version range associated with the reference since projects are referenced separately, you get the project you referenced and the version of it is discovered at restore time when all dependencies are walked.

This is also the reason why a restore is needed, all dependency resolution, including discovering dependency projects happens at this time.

[KallDrexx]

Sure logically that makes sense. Pragmatically it is extremely error prone.

What if dotnet pack performs a restore automatically before it builds all the nuget package? That way it is guaranteed to have the latest information when building the nuget package.

[reinaldoarrosi]

I agree with @KallDrexx, it makes no sense to have to run dotnet restore prior to dotnet pack just to make the nuget package point to right versions.

Since all references are ProjectReferences they should respect the Version that is defined in .csproj, just like ProjectReferences can immediatelly "respect" code changes in referenced projects.

[emgarten]

Duplicate of #4790