I'm currently using the Jenkins "Version Number Plug-In" to set an Environment Variable for build version. This works fine within jenkins but i need a way to pass this to MSBuild so the Version Number of the exe's and dll's are updated. I tried the config bellow but it does not update the builds version
Environment Variable Name should be written without the percent-marks ('%'), like this:
VERSION
apart from that, I think you are good to go.
May also consider changing
${BUILDS_ALL_TIME}
to
${BUILDS_ALL_TIME, XX}
(this will enforce a two-digit build-number with leading zeros)
This is a MSBuild target that replaces the revision number in the file GlobalAssemblyInfo.cs with the SVN_REVISION variable from Jenkins.
We have a multi project solution where each project references the same GlobalAssemblyInfo for common information (like version). Modify this so it fits your setup.
By having the Exists condition the target executes on developer machines where the MSBuildCommunityTasks is not installed.
In those cases the version number in GlobalAssemblyInfo.cs is left untouched.
<Target Name="InjectSVNRevision" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')">
<!-- When this build is done by the Jenkins CI server; the svn revision number is set in the environment variable SVN_REVISION
This little snippet replaces the revision number in GlobalAssemblyInfo.cs with this svn revision number
-->
<Message Text="Injecting SVN revision number in GlobalAssemblyInfo.cs" />
<FileUpdate Files="GlobalAssemblyInfo.cs"
Multiline="true"
Singleline="false"
Regex="(AssemblyVersion|AssemblyFileVersionAttribute|AssemblyFileVersion)\("([0-9]+\.[0-9]+\.[0-9]+)(\.[0-9]+)?"\)"
ReplacementText="$1("$2.$(SVN_REVISION)")"
Condition="$(SVN_REVISION) != '' "/>
</Target>
The easiest way I´ve found to do this is using the Change Assembly Version. Using that plugin you only need to provide the version number (or the environment variable used) and it will replace it in all the AssemblyInfo.cs files in your workspace.
A very quick work around to this is to create a powershell task before your msbuild task. This is assuming you defined VERSION variable as above (without the %%). And you checked delete workspace before build starts.
This is the code for the powershell task.
gci -rec -Filter *AssemblyInfo* | ForEach { (Get-Content $_.FullName) | ForEach-Object {$_ -replace "1.0.0.0",$env:VERSION } | Set-Content $_.FullName}
Here is my summary what was necessary to make it work:
Install this Plugins:
https://plugins.jenkins.io/versionnumber/
https://plugins.jenkins.io/change-assembly-version-plugin/
make sure your AssemblyInfo.cs contains:
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
Set your version variable name without '$'.
Define a nice version number like: '1.1.${BUILD_NUMBER}.${SVN_REVISION}'
Add the 'Change Assembly Version'-Build Step.
Enter your variable inside '${...}' example: '${VERSION}'
If you still get build error. Check you project file and AssemblyInfo.cs for merge conflicts.
Related
I'm using the new CSPROJ schema introduced in Visual Studio 2017.
Additionally, I use this to create a NuPkg for my assembly.
<PropertyGroup>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<PackageId>MyComponent</PackageId>
<Version>2.1.0</Version>
.
.
.
</PropertyGroup>
I'm using VSTS to build my solution and I'd like to use the build to control the package quality, by adding a pre-release designation to the tag. Something like this:
<Version>2.1.0$(VERSIONSUFFIX)</Version>
To yield package names such as:
MyComponent.2.1.0-alpha-12345.nupkg
MyComponent.2.1.0-beta-67890.nupkg
MyComponent.2.1.0.nupkg
This works ok, but I found a nasty side effect - if I edit the version number interactively in Visual Studio it strips the $(VERSIONSUFFIX) placeholder. The only way I can update the version number is to edit the CSPROJ directly.
Is there a better way of allowing the build to control the NuPkg generation?
Thanks
-John
The editor will always change Version and remove all customisations.
The suggested way of the new SDK is to set VersionPrefix in the build and VersionSuffix - if set - will be appended to it.
So you'd have
<VersionPrefix>1.2.3</VersionPrefix>
and could build using -p:VersionSuffix=beta-123 to produce a 1.2.3-beta-123.nupkg file.
But editing in VS properties becomes impossible in any way.
You can use build variables to specify the package version and prefix version in NuGet pack task as you need.
If you want to use assembly version for the package version and change the prefix version as you want, you can use below steps:
1. Get assembly version
You can add the task Assembly Info Reader, then you can get the assembly version by the variable $(ASSEMBLYINFO.ASSEMBLYVERSION).
2. Define package version and prefix version as you need
You can define a variable in your build definition to specify the prefix version only. Such as the variable ver with the prefix part beta-1.1.
Add a PowerShell task to combine $(ASSEMBLYINFO.ASSEMBLYVERSION) and the prefix version together for packing nuget package. The PowerShell script can be:
Write-Host "##vso[task.setvariable variable=ver]$(ASSEMBLYINFO.ASSEMBLYVERSION)-$(ver)"
So the variable $(ver) contains the version with prefix version.
3. Specify the defined version with prefix for the package to be pack
In NuGet pack task, select Use an environment variable for Automatic package versioning option and specify ver as the Environment variable.
Then the packed package will as the format MyComponent.2.1.0-beta-1.1.nupkg etc.
I would like to create a setup project based on WiX which does the following (as well as creating the installation package):
callable from msbuild running on a CI build server (Hudson)
take a version number from some asset in either the setup project or the main assembly
take the current build number from the CI system
create a full product version number [version].[build] such as 1.3.432
store this value in an asset (e.g. the main assembly) is such a way that it can be read out at run time and displayed on the splash window
I have tried a number of approaches and googled a lot but have not found a workable solution. Can anyone help?
The WiX toolset does this by creating a version.cs, a version.h and a version.wxi during the MSBuild then including those files in all the projects. That way our executable can print out their version when you run something like candle.exe -? and all of the bundles and .msi packages have their versions set correctly.
You can see how we do this in tools\WixBuild.Version.targets (here). It would straight forward to override the properties in WixBuild.Version.targets with properties passed via the command-line to MSBuild via Hudson if you wanted.
I have added the xunit.runners package to a solution. The current version is 1.9.1, so I have hard-coded the path to the executable in an MSBuild project file:
<StartAction>Program</StartAction>
<StartProgram>$(MSBuildProjectDirectory)\..\..\Packages\xunit.runners.1.9.1\tools\xunit.gui.clr4.exe</StartProgram>
<StartArguments>"$(MSBuildProjectDirectory)\$(OutPutPath)$(AssemblyName).dll"</StartArguments>
(Off-topic: with this configuration, F5 starts the xUnit GUI runner and I can debug specific unit tests.)
I know that everytime I update the Nuget package, I will forget to change the path. Changing the path is a minor nuisance, since I have to unload the project, edit the file, then reload the project.
How can I start the executable, regardless of the actual version of the package? Can I find the executable in the folder named xunit.runners.* using a wildcard in MSBuild, then use that as a property in the <StartProgram> element?
Edit:
Something like:
<ItemGroup>
<Runners Include="$(MSBuildProjectDirectory)\..\..\Packages\xunit.runners.*\tools\xunit.gui.clr4.exe" />
</ItemGroup>
Will give me all runners in #(Runners), sorted by version. How can I get one of them, preferably the last one?
For filtering you can build a custom task. It can even be inline http://msdn.microsoft.com/en-us/library/dd722601.aspx, were you can write the c# code you need to loop over the items and pick the right one. Then you can expose the chosen path in an output property that you then use to set the value of the StartProgram property.
This question shows a custom inline task that gets an item array and does stuff with it. You can probably start from there.
You'll need to use this task in a target that runs before the target that initiates the debugging.
With fsimonazzi's comment I ended up with this:
<PropertyGroup>
<Package>$([System.IO.Directory]::GetDirectories("$(MSBuildProjectDirectory)\\..\\..\\Packages\\", "xunit.runners.*").GetValue(0))</Package>
<StartAction>Program</StartAction>
<StartProgram>$(Package)\tools\xunit.gui.clr4.exe</StartProgram>
<StartArguments>"$(MSBuildProjectDirectory)\$(OutPutPath)$(AssemblyName).dll"</StartArguments>
</PropertyGroup>
Apparently, NuGet will guarantee there's only one version of the package.
First of all, I do have some sort of understanding that the following might not be the generally accepted way to do things.
We have a Maven 2 project that has a version number which should be updated each week or so, during a new release. During this process, I've tried to eliminate all the things one has to remember and I've made a bash script that handles the process interactively.
However, my problem is updating the pom version from the command line. I can do this with sed but I don't think it is very convenient. I was wondering if there is any maven plugin that would be able to modify the pom.xml directly from the command line. The version is set in the properties section of the pom. Would it be possible to write a plugin that would change the properties?
Thanks in advance.
Update
It seems that my issue was with project versions defined as properties (that were applied when filtering) which seems now a bit dumb.
One thing that I'm still looking for an answer is how to get the version of certain project reliably to the command line. Previously I had a "pretty unique" property that I got using grep, but now the <version> element is not unique as in child project there is at least two of these. I would need some sort of XML parser if Maven has no solutions, but my goal is to make the script as independent as possible.
I'm not sure if I should've created a new question from this, but I didn't. Getting the version is very closely related to the setting the version.
I was wondering if there is any maven plugin that would be able to modify the pom.xml directly from the command line.
The Versions Maven Plugin can do this. Check the following goal:
versions:set can be used to set the project version from the command line, updating the details of any child modules as necessary.
From Maven POM reference:
env.X: Prefixing a variable with
"env." will return the shell's
environment variable. For example,
${env.PATH} contains the PATH
environment variable. Note: While
environment variables themselves are
case-insensitive on Windows, lookup of
properties is case-sensitive. In other
words, while the Windows shell returns
the same value for %PATH% and %Path%,
Maven distinguishes between
${env.PATH} and ${env.Path}. As of
Maven 2.1.0, the names of environment
variables are normalized to all
upper-case for the sake of
reliability.
That means that you can have an environment variable like $MYMAVENPROJECTVERSION and read it as this:
<version>${env.MYMAVENPROJECTVERSION}</version>
You can update this environment variable every week, before running build.
Hope this will help you.
I am using TeamCity 4.5.1 to build and deploy an ASP.Net application to development.
This is working perfectly so far, however, my manager has asked that I tag the folder with the specific SVN Revision from which the source was compiled.
I am using an MSBuild script to do the build and deployment, however, I am unable to successfully retrieve the build number.
Here is the MSBuild command I'm using (sanitized):
<Exec Command=">\\server08\D$\Websites\MYPROJECT\version.txt echo %env.BUILD_VCS_NUMBER%,%env.BUILD_VCS_NUMBER.1%,%system.build.vcs.number%,%system.build.vcs.number.1%,%system.build.number.format%,%system.build.number.format.1%,%system.build.vcs.number.MYPROJECT_Web_Root%,%env.TEAMCITY_VCS_NUMBER_MYPROJECT_Web_Root%" />
Version.txt turns up like this:
,,,,,,,,
Aka, empty. What am I doing wrong? Any better way to do this?
%env.XYZ% is TeamCity's method of referring to the environment variables, if you want to use them in ITS settings anywhere.
In a batch file or via msbuild, you only want the XYZ part.
echo %BUILD_VCS_NUMBER% > \\path\to\version.txt