Home: dotnet pack - ProjectReference loses version information

[jgoshi]

dotnet --info
.NET Command Line Tools (1.0.0-preview4-004094)

Product Information:
Version: 1.0.0-preview4-004094
Commit SHA-1 hash: fc4eb2108c

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64

Repro steps:

1. Using the attached PackTestPJ project
2. dotnet.exe restore
3. cd TestApp
4. dotnet.exe pack --version-suffix 00

If you open up the generated nuspec file you will see the correct version numbers for both TestApp and the dependent TestLibrary project.

1. Using the attached PackTestMsBuild project
2. cd TestApp
3. dotnet restore
4. dotnet build
5. dotnet pack --no-build --version-suffix preview-00

Note the following bugs:

1. If you try to pack without the --no-build argument the pack will fail
2. If you open up the generated nuspec file you will see that the dependent TestLibrary project has the wrong version number (it defaulted back to 1.0.0).
3. Because of the change where --version-suffix now requires the non-numeric part, even if we preserved the version number from the dependent TestLibrary project you would lose the "rc-" part.
4. In the generated nuspec file we no longer have a range for version for the dependencies

[jgoshi]

Related to
https://github.com/dotnet/cli/issues/4725

[jgoshi]

PackTestMsbuild.zip
PackTestPJ.zip

[TheRealPiotrP]

Quick feedback here will be appreciated. If we need to do something in migration we need to know :)

[rrelyea]

rc2 has this fixed (the part about all proj refs end up as 1.0.0). we need to integrate into CLI this week.
@joelverhagen - anything else here we need to deal with?

[rohit21agrawal]

@jgoshi @piotrpMSFT 1) & 2) seem to have been fixed in latest versions of pack and sdk. Would appreciate if you could verify it.

as for 3) and 4) seem to be expected behavior, still discussing if we need to fix them.

[rohit21agrawal]

@jgoshi 4) is definitely the right behavior going forward. There is no change in behavior functionally, and this way we are consistent with nuget.exe pack

[natemcmaster]

seem to have been fixed in latest versions of pack and sdk.

Which versions? I can verify this is still happening in CLI 1.0.0-preview4-004233 (RC.2)

[rohit21agrawal]

@natemcmaster latest build from dev branch of nuget. if you are interested in trying it out , i can help you patch the DLLs correctly to give it a try.

[rrelyea]

first issue and second issue in OP are fixed, awaiting next integration into CLI.
third issue is a complicated one...let's talk with joel and find the other issue tracking that.
fourth issue is by design - dotnet pack in preview2 started writing out version ranges, which we consider a bug that we've fixed.

[natemcmaster]

RC.3 fixes part of the problem (all version used to be set to 1.0.0), but has introduced others, primarily, that the 'version' of package references is resolved _at restore_, not _at pack_. This means --version-suffix can only apply to the currently-packed project, not its references.

Repro:
Create two projects:
Project.Abstractions
Project.Console --> depends on Project.Abstractions

Goal:
Pack Project.Console with a pre-release label that includes a build number

Comparison:
In project.json, if I do dotnet pack --version-suffix build20170113, project references with '-*' versions, version of the package I'm packing and the project it references both receive build20170113 as the version suffix.

With 4.0.0-rc3, if I have the same setup, running the same pack command (dotnet pack --version-suffix build20170113, the ProjectReference loses the version suffix value.

[rohit21agrawal]

AFAIK --version-suffix wasn't meant to replace '-' in Package References, it was only meant to replace the '-' in the version of the package being packed.

CC: @rrelyea @emgarten thoughts?

[natemcmaster]

If so, it's a significant breaking change from project.json behavior and will make builds difficult for anyone with multiproject solutions.

[rohit21agrawal]

@natemcmaster why cant you just use package reference version= 3.0.0-$(VersionSuffix) instead of putting a "*" ?

[natemcmaster]

@rohit21agrawal a little confused by your question. PackageReference and ProjectReference are not the same thing. Can you clarify what you were asking?

[rohit21agrawal]

@natemcmaster oh i thought you were referring to the behavior of PackageReference, i misread your OP.

can you attach your project's assets file here?

[natemcmaster]

Here's a gist with the repo:
https://gist.github.com/natemcmaster/2eb494cf07771f70825ba72a3e15c444

Here is the project.assets.json file:
project.assets.json.txt

[natemcmaster]

One possible workaround: if you set version suffix during restore, it get's baked into the project.assets.json file, and shows up in nuspec:

dotnet restore /p:VersionSuffix=build20170113
dotnet pack --version-suffix build20170113

This is still less than ideal, and I suspect will go wrong when the build runs NuGet restore within Visual Studio.

[rohit21agrawal]

feel free to file a separate bug on this, but i feel this workaround is the only solution going forward.

[rohit21agrawal]

@natemcmaster any other bugs from the OP that still repro for you?

[natemcmaster]

Without the workaround of calling restore AND pack in one MSBuild invocation https://github.com/NuGet/Home/issues/3953#issuecomment-272586454, item 3 in OP description still repros. It's the version-suffix on project reference issue we've been discussing.

[rohit21agrawal]

@natemcmaster could you open another bug which specifically tracks that issue, and close this one please?