I would like to specify the (SemVer) version number during a (not selfhosted) DevOps release, so that DLLs will have this version number embedded in them, and I can create a release to GitHub + NuGet with the same version.
However, I'm struggling with how to accomplish this with as much automation as possible.
I know I can use the /p:Version=x.y.z during build to set a specific version, but if I build one more time I shouldn't use the same version number again, which could be fixed by appending +buildnumber to the version. This build number is not something I neccessarilly would want in the actual release, though.
So, how should I best handle version numbers during build and deploy, without having to edit some variables every time?
how should I best handle version numbers during build and deploy, without having to edit some variables every time?
If you want to increment the version in build/release automatically, the buildnumber should be a good choice.
In generally, we defined the major.minor.patch in Variables or some config file, and use it with BuildNumber in the Build number format option:
Then, we could use the option use the build number as nuget version when we pack the nuget package:
For the release, we could use the parameter $(Build.buildnumber) to get the build number and set it as release version:
Now, we could handle version numbers with same version during build and release, without having to edit some variables every time.
Hope this helps.
Related
In Azure DevOps I have a Pipeline variable "package version" and I set it using 0.1.3$(Rev:.r)-alpha .
I use that variable to replace the "Version" in the .net core project file.
In the Build tasks the dotnet build give me this error:
so I assume the Pipeline variable cannot use a nested variable.
There is a nother way or a different syntax to do it?
[Edit]
The nested variables should work.
I think the error was the dotnet pack using Automatic package versioning set to "Use the build number" that contain the wrong $(rev:.r) (lowercase!).
Using a custom string for Version in the VS project file gives noise on VS (error if the file is open, warning otherwise) and now the Pipeline Build give me an error on dotnet nuget restore because of the invalid Version.
I decided to use a simple clean version, <Version>0.1.2</Version>, that I can choose and document.
Then I want to find a way to read it in the build pipeline and create a custom variable attaching the Build Revision:
0.1.2$(Rev:.r) => 0.1.2.123
That is the result I want.
I found this: https://marketplace.visualstudio.com/items?itemName=tmarkovski.projectversionasvariable
I'm using it with the default settings.
I'm using the variables it creates to compose a new variable, "package version":
and I use that in the nuget pack task:
but it does not work.
The resulting variable still contain "$(Rev:.r)" not parsed.
I'll try to use again the "Automatic package versioning" and create the build number in the Options...
[Edit 2]
Set the build version number in the Pipeline Build Options worked.
It's not the optimal solution because the Build Number is not parsed and looks awful.
[Solution]
$(Rev:.r) is not available outside Build / Options.
I used $(Build.BuildNumber) and I'm able to create a composed variable:
$(Version.MajorMinor).$(Build.BuildNumber)-alpha
Build.BuildNumber is valorized in Build/Options: $(Build.DefinitionVersion)$(Rev:.r)
Version.MajorMinor is created by the Project Version As Build Variable add-on.
I don't know how to obtain the same result without using a third party component.
I'm glad my extension helped and thanks for the nice review. If you want more control and have a little time to spend to play with PowerShell, you can easily achieve what you want in two steps, without using third party extensions.
Read and parse the .csproj file as XML
Set build variables
Here are couple of links on reading XML files and working with build variables, it's actually pretty easy.
https://www.business.com/articles/powershell-read-xml-files/
VSTS: Pass build/release variables into Powershell script task
[xml]$XmlDocument = Get-Content -Path $env:project_file
echo $XmlDocument.Project.PropertyGroup.Version
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=vsts&tabs=yaml%2Cbatch
Write-Host '##vso[task.setvariable variable=package_version;issecret=true]0.1.2.'
Note: my answer wouldn't fit in a comment, I had to post an answer.
I have created a TeamCity build configuration which suits my needs, see build log below:
It's all working great except for 1 thing - Custom Build Number. My build number format is as follows:
Major.Minor.BuildCounter.TodaysDate, i.e. 2.0.59.20160224.
I achieved this with a PowerShell script.
Notice in the build log, Step 1 is to Set Build Number. Problem is that this happens after the Update assembly versions step. So this version number does not get applied to my assemblies.
But the correct version number is used everywhere else in the build process.
So my question is, HOW do I set the Custom Build Number before AssemblyInfo Patcher runs?
Resolved using Snapshot dependency feature of TeamCity.
Created a build configuration called Version. This has a powershell script build step which creates my desired build number.
Next, I make my actual build configuration dependent on the Version build configuration.
Then I get this build number in my actual build configuration, like so:
%dep.[Build Configuration ID].system.build.number%
Teamcity provides build feature "AssemblyInfo Patcher" which allows setting a build number to an assembly without having patch.
You may find it under :
Build Configuration Settings -> Build Features -> click on add new feature and select AssemblyInfo patcher.
You may assign same build number format "Major.Minor.BuildCounter.TodaysDate" AssemblyInfo Patcher. something like : %Major%.%Minor%.%build.counter%.%system.build.start.date%
By adding Major and Minor as teamcity configuration parameters.
You may use teamcity's predefined %build.counter% parameter.
And finally TodaysDate:
The Groovy Plugin for TeamCity provides build start date/time properties
system.build.start.date
system.build.start.time
!!This is not about custom pipeline!!
I want to know how I can manually specify version for the pipelines that we define using the already provided pipeline components in visual studio?. I am new to BizTalk, and even don't know if we can manually specify version for the pipelines or not. We can specify version for a schema, by specifying the version in version property of a schemas's property. But there is no version property in a Pipeline's property.
Also, I want to know if we can specify version number for a pipeline component, if yes, then how?
Screenshots attached for better understanding.
You version Custom Pipeline Components by setting the Assembly Version Number in the Project the component is in.
When you GAC it and add it to your toolbox in Visual Studio, it will read that Assembly Version Number. So any Pipeline you add it to will be referencing that Version. There is no need to set it manually.
We have many libraries which are build in a CI, which deploy prereleases every time they build. Other projects depend on these and automatically updates them during build.
But the references are set with the Specific Version = true, which means that increasing the version number on these dlls causes the build to fail.
How can I control the setting of the property?
You cannot change NuGet's behaviour without changing its source code. NuGet will always sets SpecificVersion to true when adding a non-GAC assembly from within Visual Studio.
You would need to run some sort of post build script to fix the references or manually change them.
Not sure exactly how you are updating the projects in your CI server. If you use NuGet.exe update project.csproj then that will update to the latest NuGet package and will not set SpecificVersion to true. However the command line application does not support PowerShell scripts or content files, only references will be updated. This also assumes that there is an update available otherwise the reference will not be modified.
I am making a change to some code which I need for one component of my application but which I do not wish to release to the rest of my application due to concern that it might have an unintended side effect.
We currently name our packages major.minor.hotfix.buildnumber with our system on say 1.4.9.600 I'd like to release a package along the lines of 1.4.9-branch.601 which can only be chosen manually and wouldn't be picked up with the Update-packages command.
http://docs.nuget.org/docs/reference/versioning
You want the section labeled:
Prerelease Versions
//Quote//
Additionally, prerelease versions of your API can be denoted by appending an arbitrary string to the Patch number separated by a dash. For example:
1.0.1-alpha
1.0.1-beta
1.0.1-Fizzleshnizzle
Note that the actual string applied doesn't matter. If there's a string there, it's a prerelease version.
When you’re ready to release, just remove the dash and the string and that version is considered “higher” than all the prerelease versions. For example, the stable version 1.0.1 is larger than 1.0.1-rc
//End Quote
and then the "how to get it" command-line argument
Install-Package CoolStuff -IncludePrerelease