Home: NuGet pack append prerelease suffix to version
Currently, our team stores the version number within the _AssemblyInfo.cs._ All our info is in there so we just pack off the .csproj. What we'd like to do is have our CI build publish a prerelease package for testing/evaluation. (1.0.0-build2 or 1.2.0-nightly, for examples). Right now CI runs the _pack_ with a hard-configured -Version 1.0.0-build2 for that but we have to change the CI build command each time the _AssemblyInfo.cs_ is updated.
We would like to have the _pack_ able to dynamically pull the version number from the _AssemblyInfo.cs_ but allow an optionally injected suffix for the prerelease designation.
_(...or a link to where we can find documentation on how to do this. I wasn't able to find anything on my own.)_
spankr
All 22 comments
That's a nice idea. Note that we will not take versions from AssemblyInfo.cs but perhaps from the assembly version itself.
I'm moving this out beyond Update I, but if you want this coming in faster you are more than welcome to submit a PR.
Note that we are going to move nuget.core and command line into GitHub in the coming days/weeks, you might want to wait on that if you are interested in submitting a PR.
yishaigalatzer
on 1 Jun 2015
That answered my next two questions too! I'll keep an eye out for the migration and see if I can submit a PR.
spankr
on 2 Jun 2015
I like this idea. +1
petterek
on 9 Sep 2015
@spankr the command line now builds from https://github.com/nuget/nuget.packagemanagement repo, start with the home repo for build scripts
yishaigalatzer
on 9 Sep 2015
Woot! I'll start taking a look.
spankr
on 10 Sep 2015
Hrm, I seem to have issues trying to get the dev environment up and running. I've been following the instructions and most of it seems to be building from my Powershell (v5) prompt.
I am seeing a lot of _Build succeeded._ and passing tests so that's good. I just seem to be having difficulties finding the ProjectManagement namespace
IDE\NuGetAndEnvDTEProjectCache.cs(8,13): error CS0234: The type or namespace name 'ProjectManagement' does not exist in the namespace 'NuGet' (are you missing an assembly reference?)
C:\Users\Spankr\Source\Repos\NuGet.VisualStudioExtension\src\PackageManagement.VisualStudio\PackageManagement.VisualStudio.csproj]
... snip snip...
9 Warning(s)
148 Error(s)
Time Elapsed 00:00:02.10
Build failed
At C:\Users\Spankr\Source\Repos\Home\build-nuget.ps1:129 char:9
I looked through the issues on Home to see if anyone else had something similar and this issue was the closest I could find. That issue mentions using NuGet.Client (comment of @yishaigalatzer) so I may give those steps a try.
spankr
on 11 Oct 2015
Yes. Use nuget.client, we finally got good builds there.
Make sure you have aspnet 5 beta7 installed and deleted as well as vs SDK and win 10 toolset
Sent from my Windows Phone
From: Lealand Vettlesonmailto:[email protected]
Sent: 10/11/2015 1:54 PM
To: NuGet/Homemailto:[email protected]
Cc: Yishai Galatzermailto:[email protected]
Subject: Re: [Home] NuGet pack append prerelease suffix to version (#694)
Hrm, I seem to have issues trying to get the dev environment up and running. I've been following the instructionshttps://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdocs.nuget.org%2fContribute%2fSetting-up-the-NuGet-Development-Environment&data=01%7c01%7cyigalatz%40microsoft.com%7c84b860e885a4474bade208d2d27e36e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=z5w%2fOEb3HGBEWeuQN1zRkq1NGrQnOQBegBZx1oIY4iw%3d and most of it seems to be building from my Powershell (v5) prompt.
I am seeing a lot of Build succeeded. and passing tests so that's good. I just seem to be having difficulties finding the ProjectManagement namespace
IDENuGetAndEnvDTEProjectCache.cs(8,13): error CS0234: The type or namespace name 'ProjectManagement' does not exist in the namespace 'NuGet' (are you missing an assembly reference?)
C:UsersSpankrSourceReposNuGet.VisualStudioExtensionsrcPackageManagement.VisualStudioPackageManagement.VisualStudio.csproj]
... snip snip...
9 Warning(s)
148 Error(s)
Time Elapsed 00:00:02.10
Build failed
At C:UsersSpankrSourceReposHomebuild-nuget.ps1:129 char:9
I looked through the issues on Homehttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues&data=01%7c01%7cyigalatz%40microsoft.com%7c84b860e885a4474bade208d2d27e36e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MmFXUrh9kYXrLH0GBwl7QhGrrdwXGTSl0t94imR%2fDHA%3d to see if anyone else had something similar and this issuehttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f787&data=01%7c01%7cyigalatz%40microsoft.com%7c84b860e885a4474bade208d2d27e36e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=dUudPBP4ai%2bZdt44dLUkIUoyhlSX%2byz5vs6sQbAs1LY%3d was the closest I could find. That issue mentions using NuGet.Clienthttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fNuGet.Client&data=01%7c01%7cyigalatz%40microsoft.com%7c84b860e885a4474bade208d2d27e36e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LSKBim5Gpht9X2Yyf%2biD41C%2fKkD%2f9Pb0dwsqbI8o924%3d (comment of @yishaigalatzerhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fyishaigalatzer&data=01%7c01%7cyigalatz%40microsoft.com%7c84b860e885a4474bade208d2d27e36e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=M%2fLVbcjt8t5HUCJ3Haozyo%2fZHPSIUfLNLPeSUOU5%2foI%3d) so I may give those steps a try.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f694%23issuecomment-147244618&data=01%7c01%7cyigalatz%40microsoft.com%7c84b860e885a4474bade208d2d27e36e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=JTqCvRauvO%2fBUtQN%2b9FHLyGCJCPbMzb%2f%2fn3F6UTm4KA%3d.
yishaigalatzer
on 12 Oct 2015
Will do. Thanks for the help, Yishai!
spankr
on 12 Oct 2015
Okay, Nuget.Clientbuild.ps1 ran with no errors yesterday on my Win10 system so I'll use that. :+1:
_(I seem to have 18 build errors from my Win7 about not finding packagesNuGet.MsBuild.Integration.)_
To clarify, I want to use Nuget.Client for investigating the change and not the Home + PackageManagement environment?
Either way, I think this should be enough to dig around for now.
spankr
on 13 Oct 2015
Yes, some code might still be in nuget2
Sent from my Windows Phone
From: Lealand Vettlesonmailto:[email protected]
Sent: 10/13/2015 8:22 AM
To: NuGet/Homemailto:[email protected]
Cc: Yishai Galatzermailto:[email protected]
Subject: Re: [Home] NuGet pack append prerelease suffix to version (#694)
Okay, Nuget.Clientbuild.ps1 ran with no errors yesterday on my Win10 system so I'll use that. :+1:
To clarify, I want to use Nuget.Clienthttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fNuGet.Client&data=01%7c01%7cyigalatz%40microsoft.com%7cbe40bd757a2d43cce24308d2d3e20c2a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3QTFwFuYbuiIAh8dJvc0EQpx%2bzCpfkAkHyqR0agNuWk%3d for investigating the change and not the Homehttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome&data=01%7c01%7cyigalatz%40microsoft.com%7cbe40bd757a2d43cce24308d2d3e20c2a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=H79tshs%2bn4DRkVep9ILue1Ug%2fS6IlT2qBaHceGVESlA%3d + PackageManagementhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fNuGet.PackageManagement&data=01%7c01%7cyigalatz%40microsoft.com%7cbe40bd757a2d43cce24308d2d3e20c2a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=t9vzzUjvHfSFRYZ1PYQKh8gSVbeCoufo7fW7icqxBn8%3d environment?
Either way, I think this should be enough to dig around for now.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f694%23issuecomment-147748573&data=01%7c01%7cyigalatz%40microsoft.com%7cbe40bd757a2d43cce24308d2d3e20c2a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nGKM3t7N7vkJzvBKaK1g%2fi%2f6jdhQaa0iX0RmU1OMx4Y%3d.
yishaigalatzer
on 13 Oct 2015
You need win10 tools on your win7 machine
Sent from my Windows Phone
From: Yishai Galatzermailto:[email protected]
Sent: 10/13/2015 8:27 AM
To: NuGet/Homemailto:[email protected]; NuGet/Homemailto:[email protected]
Subject: RE: [Home] NuGet pack append prerelease suffix to version (#694)
Yes, some code might still be in nuget2
Sent from my Windows Phone
From: Lealand Vettlesonmailto:[email protected]
Sent: 10/13/2015 8:22 AM
To: NuGet/Homemailto:[email protected]
Cc: Yishai Galatzermailto:[email protected]
Subject: Re: [Home] NuGet pack append prerelease suffix to version (#694)
Okay, Nuget.Clientbuild.ps1 ran with no errors yesterday on my Win10 system so I'll use that. :+1:
To clarify, I want to use Nuget.Clienthttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fNuGet.Client&data=01%7c01%7cyigalatz%40microsoft.com%7cbe40bd757a2d43cce24308d2d3e20c2a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3QTFwFuYbuiIAh8dJvc0EQpx%2bzCpfkAkHyqR0agNuWk%3d for investigating the change and not the Homehttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome&data=01%7c01%7cyigalatz%40microsoft.com%7cbe40bd757a2d43cce24308d2d3e20c2a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=H79tshs%2bn4DRkVep9ILue1Ug%2fS6IlT2qBaHceGVESlA%3d + PackageManagementhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fNuGet.PackageManagement&data=01%7c01%7cyigalatz%40microsoft.com%7cbe40bd757a2d43cce24308d2d3e20c2a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=t9vzzUjvHfSFRYZ1PYQKh8gSVbeCoufo7fW7icqxBn8%3d environment?
Either way, I think this should be enough to dig around for now.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f694%23issuecomment-147748573&data=01%7c01%7cyigalatz%40microsoft.com%7cbe40bd757a2d43cce24308d2d3e20c2a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nGKM3t7N7vkJzvBKaK1g%2fi%2f6jdhQaa0iX0RmU1OMx4Y%3d.
yishaigalatzer
on 13 Oct 2015
I've started looking into this one, I can send a PR whenever.
logankp
on 30 Nov 2015
yishaigalatzer
on 30 Nov 2015
PR merged.
feiling
on 9 Dec 2015
http://docs.nuget.org/consume/command-line-reference doesn't contain info about this, the nuget.exe usage dump does.
FransBouma
on 16 May 2016
Thanks for letting us know. I will assign this to myself and mark this issue as a doc
harikmenon
on 17 May 2016
docs updated https://github.com/NuGet/NuGetDocs/pull/694
karann-msft
on 6 Dec 2016
Hello all
referencing current docs:
suffix Appends a suffix to the internally generated version number, typically used for appending build or other pre-release identifiers. For example, using -suffix nightly will create a package with a version number like 1.2.3.45-nightly.
if one does that, is the generated version number compatible with SemVer 1 (and hence with Nuget 3.5) ?
Currently our .nuspec file has <version>1.1.0</version>, then command in PowerShell script has & "nuget" pack -suffix $env:APPVEYOR_BUILD_NUMBER where e.g. $env:APPVEYOR_BUILD_NUMBER = "123".
That produces a package with version OurPackageName.1.1.0-123, with a dash separating original number from added suffix. Which in turn makes NuGet complain in a number of places, eventually preventing VS 2015 Package Manager to list that package when installed (from package manager console).
How do you use -suffix option and still manage to have a compatible version number, something like 1.1.0.123 ?
Thanks
BrainCrumbz
on 30 Jan 2017
@BrainCrumbz SemVer 1 spec allows this. I'm not sure why NuGet is complaining, but a version number of 1.1.0-123 is perfectly valid.
Per SemVer specs:
A pre-release version number MAY be denoted by appending an arbitrary string immediately following the patch version and a dash. The string MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-]. Pre-release versions satisfy but have a lower precedence than the associated normal version. Precedence SHOULD be determined by lexicographic ASCII sort order. For instance: 1.0.0-alpha1 < 1.0.0-beta1 < 1.0.0-beta2 < 1.0.0-rc1 < 1.0.0.
Thanks for quick reply @logankp . My "Not compatible SemVer 1" might be a wrong statement, if that's the case, but still Nuget has issues with that naming scheme, as found when googling around. As of now, a workaround seems to be the following:
- add some build number in .nuspec file:
<version>1.1.0.0</version> - start suffix with some text, not with a number:
-suffix "dev-$env:APPVEYOR_BUILD_NUMBER"
BrainCrumbz
on 30 Jan 2017
@BrainCrumbz Thanks for the workaround, and I'll make a small note in the suffix docs to say that the suffix should start with a letter. The nuget 4.0 RC4 CLI indicates this as a warning, in fact:
WARNING: Issue: Package version not supported on legacy clients.
WARNING: Description: The package version '1.0.0-123' uses SemVer 2.0.0 or components of SemVer 1.0.0 that are not supported on legacy clients. This message can be ignored if the package is not intended for older clients.
WARNING: Solution: Change the package version to a SemVer 1.0.0 string. If the version contains a release label it must start with a letter.
I also did some experiments with the VS2017 Package Manager Console and UI (which are v4 for NuGet) and they're both happy with numeric suffixes. (For example, the Package Manager Console will show it both with "Find-Package -IncludePrerelease -AllVersions" and with "Get-Package". Install-Package with -version 1.0.0-123 also works. Numeric suffixes appear fine in the version drop-down of the UI too.)
kraigb
on 15 Feb 2017
https://docs.microsoft.com/en-us/nuget/tools/nuget-exe-cli-reference#pack now has the note under the suffix argument.
kraigb
on 28 Mar 2017
Related issues
blackcity
·
3Comments
livarcocc
·
3Comments
dotMorten
·
3Comments
LordMike
·
3Comments
p-kaczynski
·
3Comments
Most helpful comment
https://docs.microsoft.com/en-us/nuget/tools/nuget-exe-cli-reference#pack now has the note under the suffix argument.