Setting up a Microsoft build server

What is needed to build .NET code without installing Visual Studio?

The question seems simple enough, but it is not at all so simple. There’s a lot to install on a blank server, to make this happen, especially if you need to build many different .NET Framework versions and project types. It’s also useful information, if you need to setup virtual build servers on the fly. In my next blog post, I will even show you how to setup a Dockerfile and pipeline, that makes it possible to setup a build server with docker. In this post, I assume that you have access to some kind of “blank” Microsoft server, for instance a Microsoft Windows Server 2016.

But first, we need to establish the requirements of a Microsoft build server.



The requirements for the server is quit simple:

  • Build .NET and .NET Core code without Visual Studio installed
  • Test the code (in this blog, I will use NUnit, as this is the unit test framework I primarily use)
  • Create a build artifact to publish/deploy somewhere (deployment is not described in this post – build examples will be described in a later post)


Components to install

So, what should we install and how? I will show you what to install and how to do it using some Powershell commands.


Windows features

First thing is to install some basic Windows features:

These features is used by MSBuild to define how an ASP.NET project is build.



MSBuild itself comes wrapped in a package from Microsoft called “Build Tools”. There’s a correlation between releases of Visual Studio and MSBuild versions. The reason is that a Visual Studio project file contains references to targets or target files. These target files defines the build process and thereby describes how MSBuild should build a given project file. All these target files are installed when installing Build Tools.

The Microsoft Build Tools are NOT backwards compatible. Microsoft have changed quit a lot in the format and the content of both the target and project files over the years (new project types have also emerged), so if you need to build older Visual Studio project files, then you have to install the corresponding Microsoft Build Tools versions! In the script below, I have chosen to install the three latest versions.

Notice the lines 3, 7 and 11, where the Build Tools is installed.

The first two lines install packages can be installed with the parameters:

  • “/Silent” (run the install in the background and don’t ask for user input)
  • “/Full” (everything is installed).


The latest Build Tools package (MSBuild 17 – last line in the script above), has all new parameters:

  • As the package contains a lot of components you wouldn’t normally need (mostly C++ stuff), you can choose only to install the MSBuildTools and the WebBuildTools component by using the “–add” parameter. If you need additional components, here’s a full overview:
    • MSBuildTools contains all the basic stuff you need, including MSBuild and target files, to build .NET projects.
    • WebBuildTools is important, if you need to build web projects (ASP.NET), as it contains the target files referred in those project files.
  • “–passive” is the same as “/Silent”
  • “–norestart” is what it is – don’t restart after installation (we will install a lot of stuff as well in the final install script).


.NET Framework Developer/Targeting packs

The .NET Frameworks does not ship with the Microsoft Build Tools packages, so we need to install them seperately. Again, the .NET Framework packages are not backwards compatible. All the .NET Framework versions that you would like to build, needs to be installed on the build server.

We will only be installing Developer/Targeting packs, as these also contain the .NET Framework itself – no need to install the framework files twice. Apart from the .NET Framework itself, the developer packs also contains the .NET SDKs. If they are not installed, you will get some weird build errors when trying to run MSBuild for some projects.

Parameters for all three packages:

  • “/q” as in “Silent”, meaning that it won’t ask for user input during installation.
  • “/norestart”, again the server will not restart after installation.


If you have solutions/projects that target older .NET Frameworks, these should of course be installed as well.


Optional: Windows SDK

If you need to build WPF applications, then it is important to install the Windows SDK package.


.NET Core

This is the new hot stuff in the .NET community – .NET code that builds and runs on nearly all environments, including on Linux based systems. A lot of the new project types that ships with Visual Studio 2017, is build with the .NET Core SDK, also including the new cross-platform and -API .NET Standard projects.

As we will only build and test the code, the .NET Core SDK is what we need. The only thing we need to do is downloading and unpack it to a folder on the file system.



No build server without NuGet. Just download and unpack to a folder on the file system. This makes it possible to restore (download), pack and add NuGet packages.


Optional: NUnit

Download your preferred unit test framework – mine is NUnit.


Web Targets

If you need to build ASP.NET (or other Visual Studio web projects), you need the Web.targets package(s). Again again, the package is not backwards compatible, so you need to install the ones you need to build – the versions correlate with the MSBuild versions. 14 should be sufficient for both MSBuild 14 and 17.

Notice two things in the above script:

  1. I “navigate” to the correct MSBuild folder prior to installation and then move the files installed to the correct folder.
  2. We use NuGet to install the packages.


System variables

The last thing we need to do on the server, is to set some environment variables, including the PATH variable.

The PATH variable now contains the paths for .NET Core, MSBuild and NuGet. Read more about the PATH environment variable here.


We also need to rewrite the MSBuildSDKsPath, to tell how to build .NET Core projects with MSBuild. In this way, we use the .NET Core SDK to build our Visual Studio 2017 projects. We do this by pointing the MSBuildSDKsPath environment variable to where we unpacked the .NET Core SDK. The reason why we do this, is covered in a MSBuild issue at Github.


The final install script!

That’s it! This is all that needs to be installed, to create a Microsoft build server.

The full Powershell script for installing your own build server is available below.


Next step…

In my next blog posts, I will show you:

  • How you can use the above build server installation to setup a docker build server image.
  • Create a Powershell build script, to build and test your code, and create a deployable artifact.
Share this blog post:

Leave a Reply