Two new tasks in my Manifest Version VSTS Extension

calendarMay 2, 2017 · 3 min read · Uncategorised  ·
Share on: linkedincopy

I have just released a new version of my VSTS Manifest Version Extension (1.5.22). This adds two new tasks to the set of versioning tasks in the extension. The complete set now is

  • VersionAssemblies - sets the version in the assemblyinfo.cs or .vb (used pre build)
  • VersionDotNetCoreAssemblies - sets the version in the *.csproj (used pre build)  - cross platform
  • VersionAPPX - sets the version in the Package.appxmanifest (used pre build)
  • VersionVSIX - sets the version in the source.extension.vsixmanifest (used pre build)
  • VersionDacpac - sets the version in a SQL DACPAC (used post build)
  • VersionNuspec - sets the version in a Nuget Nuspec file (used pre packing)
  • VersionSharePoint - sets the version in a SharePoint 2013/2016/O365 Add-In
  • VersionWix - sets the version in a Wix Project

As with all the other tasks, these new tasks aim to find files recursively to update with a version number extracted from the build number

Version .NET Core CSPROJ file

This is a cross platform task, written in Node.JS. It updates a version number in a .NET Core .CSPROJ file. There is a parameter so it can look for different XML node names

 1<Project Sdk="Microsoft.NET.Sdk.Web"> 
 2
 3<PropertyGroup> 
 4
 5<TargetFramework>netcoreapp1.1</TargetFramework> 
 6
 7<Version>1.0.0.0</Version> 
 8
 9</PropertyGroup> 
10
11<ItemGroup> 
12
13<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" /> 
14
15<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" /> 
16
17<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.1" /> 
18
19<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.1" /> 
20
21<PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="1.1.0" /> 
22
23</ItemGroup> 
24
25</Project>

Version a Wix project

As Wix is a Windows technology, my new Wix task is only supported on Windows (PowerShell) build agents.

Due to the flexibility (complexity?) of Wix it does have to make some assumptions. I have documented them in the VSTS extension’s project wiki.

The summary is you need to put all the version number variable definitions in an installerversion.wxi file that is included into your Wix project. The task looks for and updates this file(s)

 1<?xml version="1.0" encoding="utf-8"?>  
 2<!-- Note that this file will be overridden by the build server. -->  
 3<Include>  
 4  <?define MajorVersion = "1" ?>  
 5  <?define MinorVersion = "0" ?>  
 6  <?define BuildNumber = "0" ?>  
 7  <?define Revision = "0" ?>  
 8  <?define FullVersion = "1.0.0.0" ?>  
 9  <!--WiX Installer Versions are Major.Minor.Revision -->  
10</Include>

These variables can be used anywhere in the Wix project where needed e.g. to set the MSI version you could do the following

1<?xml version="1.0" encoding="UTF-8"?>  
2<?include InstallerVersion.wxi ?>   
3<Wix xmlns="[http://schemas.microsoft.com/wix/2006/wi"](http://schemas.microsoft.com/wix/2006/wi")\>  
4  <Product Id="\*" Name="WixProject" Language="1033" Version="$(var.FullVersion)"  Manufacturer="Test"  
5           UpgradeCode="510ca227-7d91-43f4-881c-13319a07b299">

If you want a different number format just build it from the individual parts.

Hope you find them useful, as usual asked question on VSTS Manifest Version Extension Q&A or raise issues on Github