Configuring Nuget pack for prerelease on VSTS - nuget

Note
If there is an easier way to create prerelease packages please let me know!
I am using Visual Studio Team Services and have setup a nuget pack and publish step.
I have a build variable called $(BuildSuffix) that allows me to tag build-specific variables onto the end of the build number format like so
$(Build.DefinitionName)_1.0.$(date:yyyy)$(date:MM)$(date:dd)$(rev:.r)$(BuildSuffix)
The idea then is that I can set $(BuildSuffix) to -beta so that my final build version might be Build_1.0.20170119.2-beta.
According to the nuget documentation here, appending -beta to a build number will create a prerelease package. The build in VSTS comes out with -beta appended but the nuget pack stage never seems to contain it. It always comes out as the exact version number but without the -beta tag.
My nuspec files look like this:
<package >
<metadata>
<id>MyCompany.Data</id>
<version>$version$</version>
My NuGet package step looks like this:

After some research and bashing my head against a brick wall I figured out how. You have to:
Configure a local Build Agent
Install Nuget CLI
On Nuget Packager Task set Path To NuGet.exe to the NuGet CLI
Set NuGet Arguments on the same screen to -suffix beta

With new NuGet task(version 2) you can specify Additional build properties and there you can pass your custom build number directly instead of using -suffix NuGet argument. Additional build properties are substituting $token$ with supplied value in nuspec and you are free to change whatever you want in there.
I also see it on your screenshot, but I never tried to use it like this with older NuGet tasks as those are deprecated now.
Maybe it will be helpful to try import NuGet Packaging Task Group definition I am using on my private projects. Check it out Here.

Related

Publishing prerelease NuGet packages with dotnet CLI in Azure DevOps

I have been playing with a pipeline but still haven't found a way to make dotnet pack in Azure DevOps create version "2021.10.22-alpha.1" (template is YYYY.MM.DD-alpha.Rev) for my library. I wasn't able to find a way to specify "alpha" at anywhere (yes, I tried everything).
I've finally found it.
Set "Automatic package versioning" to off so no Version is passed
to MSBuild. Otherwise it'd ignore any suffixes or prefixes
In
"Additional build properties" set
VersionSuffix=foo;VersionPrefix=$(Build.BuildNumber)
Adjust
BuldNumber format in the Options section of the pipeline if need
Now my package version is "2021.10.22.8-foo". It's still not ideal but I'm on the right way.

Azure DevOps keep NLog configuration on Release, when Nuget Packaging updates

I am trying to keep my NLog configurations, when I do a release from Azure Devops. The Nuget Package portion overwrites my NLog configurations and sets it back to default. I would like to know how to preserve my configurations when I release my build, but keep the Nuget Packages update to date for the other packages.
You need to remove the NLog.Config package for that.
It's documented here: https://www.nuget.org/packages/NLog.Config
Note: Unfortunately this package won't work well when using
Advised to:
download manually: https://raw.githubusercontent.com/NLog/NLog/dev/src/NuGet/NLog.Config/content/NLog.config
set "Copy To Output Directory" to "Copy if newer"

Managing nuget versions from beta to release in VS2017 for .net core2.1 when building pipeline in Azure Devops

I need to create nuget package for a .net core 2.1 as part of build and release process in Azure Devops
What I would like to do
1) In the build section build the project and then add the compiled code to artifact
2) In Release definition will have 2 deployments one for Beta release where the version will be like 1.2.3-Beat.2 and push to azure artifact nuget and another deployment to release where the version will be like 1.2.3.2 and push to azure artifact nuget.
Currently I have only one build definition which will build (nuget package gets created during build process) and push to azure artifact nuget.
Pipeline I would like to create
Use the dotnet pack task with the --no-build option, and in your pre-release stage set the VersionSuffix value.
Note: My current team uses a set of Powershell scripts to append build number data to the Major.Minor data found in the .csproj (or AssemblyInfo.cs for netFramework), but that doesn't change the answer to your question. Once you figure out what the Major.Minor.Patch[.Build] data is going to be, you can use the VersionSuffix property in a dotnet pack task with --no-build to communicate quality of the package as it moves through your pipeline.
Given a .csproj file that looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageVersion>1.0.0.1</PackageVersion>
<AssemblyVersion>1.0.1812.201</AssemblyVersion>
<FileVersion>1.0.1812.201</FileVersion>
</PropertyGroup>
<ItemGroup>
<Content Include="Assemblies\*">
<Pack>true</Pack>
<PackagePath>lib\$(TargetFramework)</PackagePath>
</Content>
</ItemGroup>
</Project>
Again, if we ignore the versioning step that we use, the dotnet pack task in the pipeline image above will produce a package with the version 1.0.0.1-Beta.
Then in your stable release stage, don't set the suffix value and let the package get its version from the .csproj file like normal (eg. 1.0.0.1).
The elements and values in the sample .csproj file above can be written as direct edits to the .csproj or they can be set using the Properties >> Package tab.
If the values are not changed in the properties menu or added explicitly, the elements and values do not appear in the .csproj and are assumed by dotnet build|test|pack commands.
Finding the right combination of these properties and values can be daunting if you aren't familiar with how they're fitted together. I found this article useful when trying to decipher the version properties.
Also, you should understand 1.0.1-b2 < 1.0.1, so your pre-release version might be 1.2.3.2-beta1 and your stable version would be 1.2.3.2.
As the package version is included the moment you perform 'nuget pack', which you would generally perform during build, it might become a bit complicated to change that version afterwards.
What may be interesting in your case is using the concept of views in Azure Artifacts, this would allow you to promote a package to the release view at a later state without having to rebuild the package.
There is a nice extension on the marketplace that would allow you to do this from within a release: https://marketplace.visualstudio.com/items?itemName=rvo.vsts-promotepackage-task
using this flow you can have the packages in the pre-release view/feed as long as you like and make them available in the release view whenever you see fit.
downside of this is that the packages are not identified as pre-release packages by Nuget as you would not be packaging them with the proper semver for that

How to remove the [warning]To connect to NuGet feeds when restoring NuGet packages

I've got a build running in VSTS which is restoring NuGet packages from both nuget.org and a custom feed in VSTS. The custom feed is in the solutions NuGet.config as a <packageSource>, along with the user name and password in <packageSourceCredentials>
The build, including the restore, is working Ok, but there is a warning ...
2016-10-12T16:18:57.6589001Z ##[warning]To connect to NuGet feeds
hosted in your Team Services account/TFS project collection with
NuGet 3.1 or below, edit your build definition to specify a path
to a NuGet.config containing the package sources you wish to use.
How can I remove this?
Based on my test, that warning remains even through using higher version of nugget (e.g. 3.3) or do not restore package from VSTS feed. (Hosted build agent has the same result).
You can’t remove it unless you custom a build task to restore package through command line.
I submit a issue here.
Update:
The issue has been updated.
I see the issue in the code coming from our transition from depending
on assets coming with the agent to being deployed with the task. You
can get around this for now until we get an official change out by
either (1) choosing to use the Nuget 3.5 version radio button in the
task config or (2) supplying a path to your nuget.config.
So, you can use Nuget 3.5 version or specify nuget.config file.

VSO Build vNext - Nuget Package Build Step - Use build number to version package

I have my build number format specified as :
$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
This creates build Numbers in the format of "BuildDefinitionName_2015.11.11.1"
Where revision seems to be the number of times the build has run for that day.
I would like to be able to use this value in further build steps.
For example I am creating a nuget package with the nuget packager step and am using the option "Use build number to version the package"
This creates me packages similar to this "PackageName.2015.11.11.1.nupkg"
I then want to use the nuget publisher build step to publish this, but the problem is that over time you get more than one package in the package folder and the nuget publisher step uses a pattern for matching packages to publish.
ie
"PackageName.2015.11.11.1.nupkg"
"PackageName.2015.11.11.2.nupkg"
"PackageName.2015.11.11.3.nupkg"
Without being explicit about the file to publish, the publisher step will publish all these files.
I don't want this, I just want it to publish the file which matches the current build number.
So I would like to be able to set the build number parts in the pattern.
ie PackageName.$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r).nupkg
But it appears that these variables do not get substituted in the search path and come through as a literal match.
It seems strange that in the nuget package step it gives you the option to create packages by build number, but then does not allow you to match this in the nuget publish build step.
Nuget Packager step use PowerShell script to get the build number. The source code is here: https://github.com/Microsoft/vso-agent-tasks/blob/84746169f19b7c3e3f67c0efa1a546c4107055fa/Tasks/NugetPackager/NuGetPackager.ps1
If you do want to transfer the build number to Nuget Publish, you can add a PowerShell step in your build process to get the build version number. Refer to the build version related code in the Source Code for details.
And in the end of the PowerShell script, add code:
Write-Host "##vso[task.setvariable variable=bversion;]$NewVersion"
This code create a variable “bversion” with build version number filled. Then you can use variable $(bversion) in your Nuget Publish step.
I would suggest to do a clean checkout of the source code in each build, which will solve the problem of having old package files lying around in subsequent builds.
Otherwise there's the $(build.buildnumber) variable which contains the expanded value of the build number, but as long as you have additionally the $(BuildDefinitionName) in the build number you won't be able to use it for the file name. See here for a list of available predefined variables.