dotnet pack - ProjectReference loses version information #3953

Closed
jgoshi opened this Issue Nov 15, 2016 · 21 comments

Comments

Projects
None yet
6 participants
@jgoshi

jgoshi commented Nov 15, 2016

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

This comment has been minimized.

Show comment
Hide comment

jgoshi commented Nov 15, 2016

Related to
dotnet/cli#4725

@jgoshi

This comment has been minimized.

Show comment
Hide comment
@TheRealPiotrP

This comment has been minimized.

Show comment
Hide comment
@TheRealPiotrP

TheRealPiotrP Nov 15, 2016

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

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

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Nov 15, 2016

Contributor

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?

Contributor

rrelyea commented Nov 15, 2016

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?

@rrelyea rrelyea added the Area: Pack label Dec 8, 2016

@rrelyea rrelyea added this to the 4.0 RC3 milestone Dec 8, 2016

@rrelyea rrelyea added the Investigate label Dec 8, 2016

@rohit21agrawal

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Dec 14, 2016

Contributor

@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.

Contributor

rohit21agrawal commented Dec 14, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Dec 15, 2016

Contributor

@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

Contributor

rohit21agrawal commented Dec 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Dec 15, 2016

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)

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

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Dec 21, 2016

Contributor

@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.

Contributor

rohit21agrawal commented Dec 21, 2016

@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 rrelyea added Type:Bug and removed Investigate labels Dec 30, 2016

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Dec 30, 2016

Contributor

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.

Contributor

rrelyea commented Dec 30, 2016

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.

@rrelyea rrelyea modified the milestones: 4.0 RTM, 4.0 RC3 Jan 10, 2017

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jan 13, 2017

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.

image

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.

image

natemcmaster commented Jan 13, 2017

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.

image

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.

image

@rohit21agrawal

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 14, 2017

Contributor

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?

Contributor

rohit21agrawal commented Jan 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jan 14, 2017

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

natemcmaster commented Jan 14, 2017

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

@rohit21agrawal

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 14, 2017

Contributor

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

Contributor

rohit21agrawal commented Jan 14, 2017

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

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jan 14, 2017

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

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

@rohit21agrawal

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 14, 2017

Contributor

@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?

Contributor

rohit21agrawal commented Jan 14, 2017

@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

This comment has been minimized.

Show comment
Hide comment

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

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jan 14, 2017

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.

natemcmaster commented Jan 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 14, 2017

Contributor

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

Contributor

rohit21agrawal commented Jan 14, 2017

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

@rohit21agrawal

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 19, 2017

Contributor

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

Contributor

rohit21agrawal commented Jan 19, 2017

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

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jan 19, 2017

Without the workaround of calling restore AND pack in one MSBuild invocation #3953 (comment), item 3 in OP description still repros. It's the version-suffix on project reference issue we've been discussing.

Without the workaround of calling restore AND pack in one MSBuild invocation #3953 (comment), item 3 in OP description still repros. It's the version-suffix on project reference issue we've been discussing.

@rohit21agrawal

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 19, 2017

Contributor

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

Contributor

rohit21agrawal commented Jan 19, 2017

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

@gareth-horstmann gareth-horstmann referenced this issue in GitTools/GitVersion Sep 1, 2017

Open

Project Nuspec References #1286

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment