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.
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.
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.
MS BuildTools 2017and install
VS BuildTools 2017(Yes, they’re different pieces)
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 https://github.com/pivotalservices/dotnet-concourse-app-cicd .
psake aides in the determining the location of MSBuild and uses that appropriately. It also simplifies the creation of build scripts.
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.
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.