Concourse Windows Worker Tooling

To build .NET Applications on Concourse, the Concourse environment should have Windows Workers registered with it.

The biggest difficulty is understanding the necessary build tools and dependencies required to build a project. Usually, these have not been well documented and it just worked on my machine because they just kept using their own machine or some known machine built a long time ago without documentation In an ideal scenario, we should be able to just to use msbuild and the target project would just use the NuGet package management to pull in all required dependencies during building time. However, it is common to see in legacy projects that require external commercial off the shelf dependencies that need to be installed and ‘setup’ properly on a build server beforehand, e.g. PostSharp.

To make matters more difficult, at the time of writing, some development teams have legacy projects that use Visual Studio 2015 (VS2015) and some newer projects on Visual Studio 2017 (VS2017). This has led to compatibility effects between versions and the matter is compounded further by the presence/non-presence of dependencies and tools between tooling versions.

BOSH Install Tools

Since Concourse Windows workers don’t use real containers we can BOSH install all the dependencies onto the worker VM and have them shared between pipeline job runs. Currently the best way to do this is to utilize the Windows .NET Framework Dev Tools Bosh Release.

Some setup notes

  1. When installing tools, use the shortest install path possible, i.e., instead of installing MSBuild2017 into C:\Project Files (x86)\Visual Studio\2017\MSBuild\, just put it into C:\MSBuild2017. It has been observed, in medium-large legacy projects, that some build tasks concatenate multiple references as a single string and is passed to some command line tool. What happens next is that the build will fail because it exceeds 32000 characters.
  2. If there are projects using VS2015, install MS BuildTools 2015.
  3. If there are projects using VS2017, install MS BuildTools 2017 and install VS BuildTools 2017 (Yes, they’re different pieces)
  4. DOCUMENT - DOCUMENT - DOCUMENT. Keep notes of what has been installed, where, what version, what it is used for and any odd configurations.
  5. Make a plan for the applications to migrate off these dependencies and move into NuGet packages, if available.

Reference Pipelines

It is typical to see .NET pipelines that utilize MSBuild, hardcode the path to MSBuild. however, different versions (2015, 2017, community, enterprise) and sprinkle MSBuild all over different places. The link below presents a simple pipeline using psake . psake aides in the determining the location of MSBuild and uses that appropriately. It also simplifies the creation of build scripts.

Other issues observed

A. The Project name is too long and the build fails because it exceeds the 260 MAX_PATH limit for command prompt. Some ideas to get around this are to: i) Shorten the project name ii) (Untested) Use Junctions (soft symlinks) to some phyiscal drive. e.g. c:\blah\blah\project\blah –> d:\project\. Note: New-PSDrive was tested but did not work. This basically sets a path to a fake drive. However, MSBuild did not seem to respect this, most likely because the fake drive was setup for a particular user and MSBuild utilized a different user or did not see the driver.