Getting Project Version Information During MSbuild build - msbuild

I'm attempting to automate the building of our installers through MSBuild. The problem that I have come up against is getting the Version information of the C# project which is calling the custom MSBuild script, which would then pass the version number into Wix during the build process.
What I would like to do is to set the version into some properties like this:
<ProductVersion>$(MajorVersion).$(MinorVersion).$(PatchVersion).$(BuildVersion)</ProductVersion>
<InstallerName>"$(ProductName)-$(ProductVersion).msi"</InstallerName>
The version is updated as part of our continuous integration build and incorporating the version number into each installer that is built on our continuous integration server helps us in producing an application that is Continuously Deployable.
Any help would be greatly appreciated.

The way I have solved this problem is by creating a 'version.xml' file in my code repository. This file contains the following data
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<VersionMajor>0</VersionMajor>
<VersionMinor>1</VersionMinor>
<VersionBuild>1</VersionBuild>
<VersionRevision>0</VersionRevision>
</PropertyGroup>
</Project>
In my case this file is checked in but it should not be too hard to generate this file with information from the build server or whatever is desired.
During the build a custom MsBuild taks (similar to the TemplateFile task) creates an assembly info file and a Wix include file from their respective template files. The 'version.xml' file is accessed by including it in the MsBuild script. For example like this:
<?xml version="1.0" encoding="utf-8"?>
<Project
ToolsVersion="4.0"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Include the version info file so that we can pull the version info from it -->
<Import
Project="$(DirWorkspace)\version.xml"
Condition="Exists('$(DirWorkspace)\version.xml')" />
<!-- Generate a file with the version information -->
<Target Name="GenerateAssemblyInfoVersionNumber">
<ItemGroup>
<VersionTokens Include="Major">
<ReplacementValue>$(VersionMajor)</ReplacementValue>
</VersionTokens>
<VersionTokens Include="Minor">
<ReplacementValue>$(VersionMinor)</ReplacementValue>
</VersionTokens>
<VersionTokens Include="Build">
<ReplacementValue>$(VersionBuild)</ReplacementValue>
</VersionTokens>
<VersionTokens Include="Revision">
<ReplacementValue>$(VersionRevision)</ReplacementValue>
</VersionTokens>
</ItemGroup>
<TemplateFile
Template="$(FileTemplateAssemblyVersion)"
OutputFileName="$(FileGeneratedAssemblyVersion)"
Tokens="#(VersionTokens)" />
</Target>
</Project>
The AssemblyInfo.VersionNumber.cs file which is included in the C# projects is generated from a template file that looks like:
//-----------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
//
// Changes to this file may cause incorrect behavior and will be lost
// if the code is regenerated.
// </auto-generated>
//-----------------------------------------------------------------------
using System.Reflection;
[assembly: AssemblyVersion("${Major}.${Minor}.${Build}.${Revision}")]
[assembly: AssemblyFileVersion("${Major}.${Minor}.${Build}.${Revision}")]
// The AssemblyInformationalVersion stores the version that will be displayed in
// Windows explorer.
[assembly: AssemblyInformationalVersion("${Major}.${Minor}.${Build}.${Revision}")]
During the replacement process the ${TEXT_HERE} sections are replaced with their respective values.
The Wix include template file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Include xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!--
This is a generated file.
Do NOT make changes to this file.
They will be undone next time the file is generated.
-->
<!-- The current version -->
<?define CurrentVersion = "${Major}.${Minor}.${Build}"?>
<!-- The install version string -->
<?define ProductVersionFolder = "${Major}.${Minor}"?>
</Include>
After including this file it is possible to refer to the CurrentVersion and the ProductVersionFolder variables in the Wix installer where ever it is needed.
By using this method the version information is stored in a single location and can be accessed by all parts of the build.

Related

How to ship the stylecop.json and custom.ruleset files with a NuGet package in VS2017

At the moment we are switching from VS2015 to VS2017. One of our upgrade steps is to switch from stylecop to the new Stylecop.Analyzer package. The new Stylecop is using 2 files. The stylecop.json and the Stylecop.ruleset.
The target: I want to provide the stylecop files as a custom nuget package. But I dont know how to create the needed .csproj entries.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
...
<CodeAnalysisRuleSet>packages\My.StyleCop.1.0.0-pre15\RuleSet\My.StyleCop.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
...
<ItemGroup>
<AdditionalFiles Include="packages\My.StyleCop.1.0.0-pre15\Config\stylecop.json">
<Link>stylecop.json</Link>
</AdditionalFiles>
</ItemGroup>
</Project>
In the past, there was the possibility to use a install.ps1 script to do this stuff. But with NuGet 3. (or 4.) the install scripts are obsolete and will be ignored.
I already tried to use My.StyleCop.targets:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<AdditionalFiles Include="packages\My.StyleCop.1.0.0-pre17\Config\stylecop.json">
<Link>stylecop.json</Link>
</AdditionalFiles>
</ItemGroup>
</Project>
But here I have some issues, too. Since NuGet 3. (or 4.) there is no solution wide package folder and I dont know any variable or placeholder I can use here to get a absolute or relative path to my package.
You can add .props or .targets files to the build folder in your packages and they will be imported to the projects.
On the .props file, you can use the MSBuildThisFileDirectory MSBuild variable that represents the folder where that file is located.
Thanks to Paulo.
How I did it:
This is the structure of my NuGet package.
The solution is quiet easy. You need to create to files. A .props and a .targets file named like the NuGet package and place them in the build folder of your package.
In these MSBuild files you can use the $(MSBuildThisFileDirectory) variable to get the path of your NuGet package.
MSBuildThisFileDirectory = C:\Users\UserName\.nuget\packages\sig.stylecop\1.0.0-pre23\build\
My SIG.StyleCop.props file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)\..\RuleSet\SIG.combiLink.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
</Project>
My SIG.StyleCop.targets file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<AdditionalFiles Include="$(MSBuildThisFileDirectory)\..\Config\stylecop.json">
<Link>stylecop.json</Link>
</AdditionalFiles>
</ItemGroup>
</Project>
Cause of the structure of my package i need to navigate (..) into the Config and into the RuleSet folder.
The variable $(MSBuildThisFileDirectory) already includes the backslash at the end. It is important to omit the backslash when you reference the ruleset and the stylecop.json file:
<CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)..\RuleSet\SIG.combiLink.ruleset</CodeAnalysisRuleSet>
<AdditionalFiles Include="$(MSBuildThisFileDirectory)..\Config\stylecop.json">
With the double backslash I experienced two strange problems in Visual Studio 2017:
Unit tests rebuild the code each time I start them, even without any code change
The IDE shows many StyleCop errors in the Error List window and shows red marks in the scroll bar even for rules that are explicitly disabled in the rule set.

Inexplicably cleared msbuild properties in TeamCity build

I'm trying to create a "tools NuGet package" that provides a tool and setting that is unpacked during build and used by a later TeamCity build step.
The NuGet package contains the following content in its build\MyPackageId.props file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MyTool1>$(MSBuildThisFileDirectory)..\tools\MyTool.exe</MyTool1>
</PropertyGroup>
<Target Name="ReportMyToolToTeamCity" BeforeTargets="PrepareToRun">
<PropertyGroup>
<MyTool2>$(MSBuildThisFileDirectory)..\tools\MyTool.exe</MyTool2>
</PropertyGroup>
<Message Text="MyTool1 = $(MyTool1)" />
<Message Text="MyTool2 = $(MyTool2)" />
</Target>
</Project>
(The messages will eventually set a TeamCity property, but this is sufficient to demonstrate the issue.)
Because it's a props file, after installing the NuGet package into a C# project it has added an import as the very first thing, above the import of Microsoft.Common.props. I want a props file rather than a targets file so that the property values are also available to other project settings and targets files.
When I compile this inside Visual Studio 2015, I see both MyTool1 and MyTool2 paths set to the same (correct) path as expected.
When I compile this from TeamCity (2017.2.2, using the Visual Studio (sln) runner), according to the output the MyTool1 property is empty and only MyTool2 shows the correct value.
Why?

How to get jspm/webpack/browserify/requirejs bundling working with msdeploy?

I currently use jspm but the same issue applies with any other build-time bundling tool. I can't figure out how to get these to play well with msdeploy.
Here's the issue:
I run jspm to produce one or more bundle files (one for each "chain" that I want).
My application uses System.import (or require or just a script tag) to start these loading.
If I were to deploy everything to a directory and xcopy from there to the deployment server everything is copacetic. However, our devops team prefers to deploy using msdeploy. For this I'm supposed to point it at a csproj. If I do this then how does msdeploy know to deploy the generated bundles?
You have to create an MSBuild project to accomplish this - one which hooks into the MSDeploy pipeline. I've provided a sample (one I'm currently using for a project) below; I'm likely going to release this as a Nuget package (along with some other MSBuild scripts that were written to take advantage of npm, jspm, and gulp).
The props file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
FrontendDeploymentFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
</PropertyGroup>
</Project>
The targets file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="FrontendDeploymentFiles">
<ItemGroup>
<_CustomFiles Include="dist\**\*" />
<_CustomFiles Include="jspm_packages\**\*" />
<FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
<DestinationRelativePath>%(RelativeDir)%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
</Project>
This isn't exactly a drop-in for you as you're bundling your files, but the takeaway here is that you can define a glob pattern for your copy methods. Replace jspm_packages with whatever your bundles are (as the scripts I've provided are only for publishing to a development environment) and you should be good.
Hope this is helpful to anyone else who runs into this issue.

Unable to find MSDeploy task within MSBuild

I am trying to use the MSDeploy task within MSBuild (instead of calling it form the command line). I assumed this task was built in to MSBuild but I seem to be having trouble finding the task. The error Im getting is below. I have just re-installed the Web Deploy Tool to see if it might help.
C:\CLIENTS\DAM\Components\Umbraco\SiteTemplate_v6_1_6\Build>msbuild MSBuildScript.csproj -t:Deploy_v2
Microsoft (R) Build Engine version 4.0.30319.17929
[Microsoft .NET Framework, version 4.0.30319.18052]
<!-- some other stuff -->
error MSB4036: The "MSDeploy" task was not found. Check
the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and imple
ments the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks
files located in the "c:\Windows\Microsoft.NET\Framework\v4.0.30319" directory.
v10.0 can vary (v11.0 for example)
Do a search for your "Microsoft.WebApplication.targets" file and alter the import statement to match.
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="AllTargetsWrapped">
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
<!-- Bunch of Other Stuff -->
<Target Name="AllTargetsWrapped">
<CallTarget Targets="ShowVariables" />
</Target>
<Target Name="ShowVariables" >
<Message Text="MSBuildExtensionsPath = $(MSBuildExtensionsPath)" />
</Target>

Working directory issue when importing msbuild file in another msbuild file

I am trying to specify some additional targets/tasks to an msbuild file by extending an existing msbuild file (a web applicartion .csproj file). The idea is to put configuration specific tasks in this "extended ms build file" and use this file in our build server (TeamCity). The way I tried to solve it at first was to add a folder "msbuildscripts" to my web project and put the extended ms build file there:
<?xml version="1.0" encoding="utf-8" ?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<Import Project="../My.Web.csproj" />
...more stuff...
</Project>
and then build this file using something like:
c:\myweb\msbuild.exe msbuildscripts/extended.msbuild.file.xml
Now, this wont work because when importing the original ms build file, that csproj file will be "executed" in the "wrong" folder (msbuildscripts), and the csproj-build-file wont find any of its referenced folders/items.
Is there any way to tell msbuild.exe to use a specific working directory? I know it is possible to solve this problem using an execute task, but that doesnt seem like a good solution.
Use MSBuild task like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="MyBuild">
<ItemGroup>
<ProjectToBuild Include="../My.Web.csproj" />
</ItemGroup>
<Target Name="MyBuild">
<MSBuild Targets="Build" Projects="#(ProjectToBuild)"></MSBuild>
</Target>
</Project>