VSTS - Version NuGet using AssemblyInfo and appending build number - nuget

I'm trying to set up a CI deployment for my NuGet package on VSTS so that when a new commit is made, a package is packed and sent to my feed. Unfortunately I'm not sure where to start; most of my experience with versioning has been manually updating a file that sits within the solution, hence this question, so if there is a better way to do this let me know.
I would like the name to be the version number in the AssemblyInfo.cs file ("0.0.1") with the build number of the automated build appended. So the final result would look something like "0.0.1.35".I would like to also avoid using date/time in my naming; a lot of the suggestions are to use this but I really wish to keep the version number clean so that I can release the packages.
I'm using the 'NuGet pack' task so I only have the options 'Use date-time', 'Use environment variable' or 'Use the build number'.
Date/time means I have to manually input a major, minor and patch which I would prefer to be automatic.
Environment variable, sounds like this could be it but I think I'm missing what I should put in this field.
I set my build name to be "$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)"but not getting the result I hoped.
Any help would be greatly appreciated!

Do you have the desire to have the file version match the NuGet package version? If so, you can use the following solution.
By default, the NuGet pack command will use the file version as the Package Version. To use this functionality to get the expected output that you want, you will need to update the file version during the build. This can be done easily with the Update Assembly Info task from the VSTS marketplace. There are a number of other similar tasks, but this one allows you to only modify the revision part of the file version independently of the Major, Minor, and Build versions.
Add the Update Assembly Info task to your VSTS account
Modify your build definition and add the 'Update Assembly Info' task to the build. Ensure that it is before your Visual Studio Build or MSBuild Task as you need to change the assembly info before the build occurs
Set the values in the Update Assembly Task to match what you need for your assemblies. By default it sets Revision to $(Build.BuildId) which is what you want based on your requirements
Turn 'Automatic Package Versioning' off in the Nuget Pack task
Add the 'Update Assembly Info' task to you build process and ensure that it is before your Visual Studio or MSBuild task.
Your build should now create a Nugetpackage of 0.0.1.{Build.BuildId}
Note: this was tested with version 2.* of the NuGet Task and Version 2.* of Update Assembly info task.

The simple workflow is using environment variable:
Add new variable to build definition (e.g. packageVersion)
Add PowerShell task to get version in AssemblyInfo.cs (you can refer to the code in Use a PowerShell script to customize your build process)
Update variable value in PowerShell script (step 2) by calling Write-Host "##vso[task.setvariable variable= packageVersion;]xxx" (Logging Commands)
Add NuGet pack task (Automatic package versioning: Use an environment variable; Environment variable:packageVersion)

I wrote this PowerShell script to do that:
param
(
[parameter()][string] $FolderPath,
[parameter()][string] $FileExtension
)
$RegularExpression = [regex] 'AssemblyInformationalVersionAttribute\(\"(.*)\"\)'
$path = Get-Location
# Get the files from folder that ends in $FileExtension content
$assemblyInfoFile = (Get-ChildItem -Path $FolderPath -Force -Recurse -File -Include *$FileExtension).Name
# Get the Content of the file and store it in the variable
$fileContent = Get-Content $FolderPath/$assemblyInfoFile
foreach($content in $fileContent)
{
$match = [System.Text.RegularExpressions.Regex]::Match($content, $RegularExpression)
if($match.Success) {
$version = $match.groups[1].value
}
}
# Check if variable has content
if ($version)
{
Write-Host $version
Write-Host ##vso[task.setvariable variable=packageversion]$version
}
To run the script locally:
.\powershellScriptName.ps1 -FolderPath "c:\Git\" -FileExtension "AssemblyInfo.cs"
FolderPath: the path to output build solution
FileExtension: part of the name where we gonna search the version
VSTS steps:
Build a task to build the solution and save de output directory in a variable;
Add PowerShell task to call your script with FolderPath and FileExtension as parameters;
In the end, packageversion should have the correct version
** Project technology: .netcore

Related

how to brake the pipeline if the nuget package is not up to date?

I have a build pipeline at azure DevOps with the following tasks:
-Pack .net core
-check nuget dependencies
-publish artifact
The first task packs the nuget and the second one checks if their versions and shows the existent last version.
What I need to do is that the pipeline stop in case the nuget packages are not up-to-date.
Any idea how I could set it up?
As a suggestion, you could define a global variable about your current nuget package latest version, also your current nuget package version.
Create two variable as LastVersion and NewVersion variable.
LastVersion is the last version of your nuget package on the package source, you should search for it and give a value for it.
NewVersion is the current nuget version you want to pack.
After that, use a powershell task with the condition of '$(LastVersion)'-eq '$(NewVersion)' to cancel the job. You can refer to this link about the steps.
Or you could use exit 1 under powershell task with the below command to cancel this:
#if LastVersion is the same as NewVersion, cancel the job
if( '$(LastVersion)' -eq '$(NewVersion)')
{
exit 1
}
else
{
exit 0
}

How to to produce both release and pre-release packages from one nuspec in VSTS?

Currently my build produces both packages having a newer version every time:
Release: Automatic package versioning = Use the build number
Pre-release: Additional build properties = Version=$(user.BuildFullVersion)-beta
And the only one nuspec has a placeholder to version:
<version>$version$</version>
I want to increment version manually, that it - repetitive build would produce same version until I increment it manually.
How can I achieve that still having single nuspec?
Can I adjust package version in the pack tasks like this:
Release: $(PackageVersion) = $(PackageVersion)
Pre-release: $(PackageVersion) = $(PackageVersion)-beta
Or something similar.
To produce two packages by a nuspec, you can use two NuGet tasks (NuGet custom instead NuGet pack):
NuGet task:
Command: custom
Command and arguments:
pack $(Build.SourcesDirectory)\Package.nuspec -Version $(Build.BuildNumber) -OutputDirectory $(build.artifactstagingdirectory)
NuGet task:
Command: custom
Command and arguments:
pack $(Build.SourcesDirectory)\Package.nuspec -Version $(Build.BuildNumber) -Suffix beta -OutputDirectory $(build.artifactstagingdirectory)
If you set the $(Build.BuildNumber) as the format like MyProject-Daily_1.0.94.0 while you want to add the version for nuget package as 1.0.94.0, you can define a variable in your build definition and set the value by cutting the substring of $(Build.BuildNumber). detail steps as below:
In Variables Tab, add a variable (such as version) with any value (such as temp).
Add a PowerShell Task before NuGet tasks with the settings,
Type: Inline Script
Inline Script:
$s1=$(Build.BuildNumber).split('_')[1].split(' ')
Write-Host "##vso[task.setvariable variable=version]$s1"
Then in the NuGet Custom tasks use $(version) to replace $(Build.BuildNumber) for -version option. Such as nuget pack -version $(version).

nuget tfs build 2015

I am trying to use NuGet to package and publish the package with TFS Build 2015 to local NuGet Server. I am getting error , I am not sure what am i missing. Thanks for Help.
Here is Error
Starting task: NuGet Packager
Set workingFolder to default: C:\Lucky\agent\tasks\NuGetPackager\0.1.58
Executing the powershell script: C:\Lucky\agent\tasks\NuGetPackager\0.1.58\NuGetPackager.ps1
Checking pattern is specified
No Pattern found in solution parameter.
Found files: 1
--File: "C:\Lucky\agent_work\1\s\Dev\FabrikamFiber.CallCenter"
The property DirectoryName does not exist or was not found.
Creating Nuget Arguments:
--ARGS: pack "C:\Lucky\agent_work\1\s\Dev\FabrikamFiber.CallCenter" -OutputDirectory "C:\Lucky\agent_work\1\s" -Properties Configuration=Release
Invoking nuget with pack "C:\Lucky\agent_work\1\s\Dev\FabrikamFiber.CallCenter" -OutputDirectory "C:\Lucky\agent_work\1\s" -Properties Configuration=Release on
C:\Lucky\agent\agent\worker\tools\NuGet.exe pack "C:\Lucky\agent_work\1\s\Dev\FabrikamFiber.CallCenter" -OutputDirectory "C:\Lucky\agent_work\1\s" -Properties Configuration=Release
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
Please specify a nuspec or project file to use.
Unexpected exit code 1 returned from tool NuGet.exe
Finishing task: NuGetPackager
Task NuGetPackager failed. This caused the job to fail. Look at the logs for the task for more details.
According to the error info:
Please specify a nuspec or project file to use. Unexpected exit code 1
returned from tool NuGet.exe
You may specified a wrong argument in nuget package task ,please double check you have followed below requirements:
Specify .csproj files (for example, **\*.csproj) for simple projects. In this case:
The packager compiles the .csproj files for packaging.
You must specify Configuration to Package (see below).
You do not have to check in a .nuspec file. If you do check one in, the packager honors its settings and replaces tokens such as $id$ and
$description$.
Specify .nuspec files (for example, **\*.nuspec) for more complex projects, such as multi-platform scenarios in which you need to
compile and package in separate steps. In this case:
The packager does not compile the .csproj files for packaging.
Each project is packaged only if it has a .nuspec file checked in.
The packager does not replace tokens in the .nuspec file (except the element, see Use build number to version package,
below). You must supply values for elements such as and
. The most common way to do this is to hardcode the
values in the .nuspec file.
Please double check your arguments , more details please refer this tutorial-- Pack NuGet packages.
Besides you could also enable verbose debug mode by adding system.debug=true to get a more detail build log info for troubleshooting.

VSO using Nuget packager build agent fails with invalid properites

I'm using VSO to package a simple DLL and the publish it to an internal feed, unfortunately during the packaging stage build it reports success but I get no artifact to publish
In the log file on for the publish it states the packing includes invalid arguments (Log 2016-02-27T09:07:35.8808468Z) as a result the publisher can't file any .nupkg file to publish.
I'm not sure where I'm going wrong. Its as if the nuget.exe is the wrong version or do it need to include anything in my solution
this is just a basic .enter image description herecsproj library with one static function for testing the process.
packager log
2016-02-27T09:07:35.2714664Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetPackager\0.1.57
2016-02-27T09:07:35.2714664Z Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetPackager\0.1.57\NuGetPackager.ps1
2016-02-27T09:07:35.4277177Z Checking pattern is specified
2016-02-27T09:07:35.4433431Z No Pattern found in solution parameter.
2016-02-27T09:07:35.4433431Z Found files: 1
2016-02-27T09:07:35.4589718Z --File: "C:\a\1\s\NugetTestLibrary\NugetTestLibrary.csproj"
2016-02-27T09:07:35.4589718Z Creating Nuget Arguments:
2016-02-27T09:07:35.4589718Z --ARGS: pack "C:\a\1\s\NugetTestLibrary\NugetTestLibrary.csproj" -OutputDirectory "C:\a\1\a" -Properties Configuration=${BuildConfiguration};Platform any cpu
2016-02-27T09:07:35.4589718Z Invoking nuget with pack "C:\a\1\s\NugetTestLibrary\NugetTestLibrary.csproj" -OutputDirectory "C:\a\1\a" -Properties Configuration=${BuildConfiguration};Platform any cpu on C:\a\1\s\NugetTestLibrary
2016-02-27T09:07:35.4747124Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\agent\worker\tools\NuGet.exe pack "C:\a\1\s\NugetTestLibrary\NugetTestLibrary.csproj" -OutputDirectory "C:\a\1\a" -Properties Configuration=${BuildConfiguration};Platform any cpu
2016-02-27T09:07:35.8808468Z pack: invalid arguments.
2016-02-27T09:07:35.8964722Z usage: nuget pack <nuspec | project> [options]
2016-02-27T09:07:35.8964722Z Creates a NuGet package based on the specified nuspec or project file.
2016-02-27T09:07:35.8964722Z Specify the location of the nuspec or project file to create a package.
2016-02-27T09:07:35.8964722Z options:
2016-02-27T09:07:35.8964722Z -OutputDirectory Specifies the directory for the created NuGet package file. If not specified, uses the current directory.
2016-02-27T09:07:35.8964722Z -BasePath The base path of the files defined in the nuspec file.
2016-02-27T09:07:35.8964722Z -Verbose Shows verbose output for package building.
2016-02-27T09:07:35.8964722Z -Version Overrides the version number from the nuspec file.
2016-02-27T09:07:35.9120964Z -Exclude + Specifies one or more wildcard patterns to exclude when creating a package.
2016-02-27T09:07:35.9120964Z -Symbols Determines if a package containing sources and symbols should be created. When specified with a nuspec, creates a regular NuGet package file and the corresponding symbols package.
2016-02-27T09:07:35.9120964Z -Tool Determines if the output files of the project should be in the tool folder.
2016-02-27T09:07:35.9120964Z -Build Determines if the project should be built before building the package.
2016-02-27T09:07:35.9120964Z -NoDefaultExcludes Prevent default exclusion of NuGet package files and files and folders starting with a dot e.g. .svn.
2016-02-27T09:07:35.9120964Z -NoPackageAnalysis Specify if the command should not run package analysis after building the package.
2016-02-27T09:07:35.9120964Z -ExcludeEmptyDirectories Prevent inclusion of empty directories when building the package.
2016-02-27T09:07:35.9120964Z -IncludeReferencedProjects Include referenced projects either as dependencies or as part of the package.
2016-02-27T09:07:35.9120964Z -Properties + Provides the ability to specify a semicolon ";" delimited list of properties when creating a package.
2016-02-27T09:07:35.9120964Z -MinClientVersion Set the minClientVersion attribute for the created package.
2016-02-27T09:07:35.9120964Z -MSBuildVersion Specifies the version of MSBuild to be used with this command. Supported values are 4, 12, 14. By default the MSBuild in your path is picked, otherwise it defaults to the highest installed version of MSBuild.
2016-02-27T09:07:35.9120964Z -Help (?) help
2016-02-27T09:07:35.9120964Z -Verbosity Display this amount of details in the output: normal, quiet, detailed.
2016-02-27T09:07:35.9120964Z -NonInteractive Do not prompt for user input or confirmations.
2016-02-27T09:07:35.9120964Z For more information, visit http://docs.nuget.org/docs/reference/command-line-reference
Unfortunately I copied the Configuration=${BuildConfiguration} parameter incorrectly (use {} instead of ()), I also had to make other changes , I didn't require the platform parameter. I was also packaging to the incorrect folder.

TeamCity, version numbers from file in repo and assembly patcher

Context
In our repo, we have a file called version.txt that contains the major and minor version number: 0.7.
I added a TeamCity build step with a powershell script that sets this parameter into a config parameter, based on this answer:
$version = Get-Content version.txt
Write-Host "##teamcity[setParameter name='UserMajorDotMinor' value='$version']"
The UserMajorDotMinor parameter defaults to 0.6 on TeamCity.
I have a config parameter called %UserVersionNumber% that is used to set the actual version number, which is defined as
%UserMajorDotMinor%.0.%system.build.number%
The Problem
While prints 0.7 in the TeamCity build log, but it doesn't seem to properly set the UserVersionNumber, because the number that the assembly patcher writes into the dll is still 0.6.0.xxxxx.
What do I have to change so TeamCity will actually write the correct version number into the dlls?
The Assembly Info Patcher build feature will run before any build step, therefore, changes made to parameters within a step won´t affect the Assembly Info Patcher
If you really need to use the Major.Minor Info from the version.txt file then i would setup a seperate build configuration that reads the file and provides the content as build parameter %UserMajorDotMinor%. Basicly what you already did.
Then you can add the newly created config as dependency to the actual build and set the %Version% Parameter to %dep.[buildconfigname].UserMajorDotMinor%.0.%system.build.number%
As a Alternative, use a Script to patch your AssemblyInfo.cs files as seperate build step instead of the Assembly Info Pather Feature.