Creating a .NET 4.6.2 Build server on Server 2012

Given that I’ve not written anything original for over a year and a half (More on that in another post) and given I had an hour to spare, I thought I’d quickly go over what I’ve been up to this weekend (Feb 2nd 2017).

As part of a new project I’m involved in, I needed to create a new CI/Build server, and since I’ve had a Dell C6100 sat in the server rack not been used to it’s full potential, I decided now was a good time to put it into use.

The first thing I did was to install “Hyper-V 2012” onto one of the Nodes in the machine, each node has 8 xeon CPU’s clocked at just under 3ghz and 24gb of memory, making it a perfect bit of kit for running virtual machines on.

Once I had Hyper-V up and running, I then set about creating and installing a new server 2012 instance. Nothing fantastic, just a simple IIS8 machine configured with a 30gb virtual disk, 1 vCpu and 4gb of ram. I made sure that it was configured with only a web role, and had RDP enabled so that I could log in remotely from my workstation and configure it.

So far everything’s perfect, I had it registered in my internal DNS, I registered the MAC address in my internal DHCP service, and booted the image up and logged in. Awesome stuff….

Preparing the Run-time

Knowing that the project I’ll be building will be a .NET 4.6.2 project, I figured that I should go ahead and download and install the .NET 4.6.2 run time (I’ll leave the links until the bottom of the post), so off I went to the mighty Microsoft, found the appropriate download, clicked on it, and attempted to install it, and here’s where the fun begins!

The extraction process started normally, I waited a while got the usual green bar, then the .NET purple logo, and then BOOM! this appears:

Great!!! so I need to go on a knowledge base hunt… fine, so off I go, back to google, and I start to search. It’s not long before I find the official Microsoft download page for the update, fantastic I thought, so I read the destruction’s, and quickly realize that the file I want is the larger one that according to the text, includes ALL the smaller ones.

I set that away downloading (about 700mb) and I go make myself a coffee

10 mins later, I have the update, so I log into the virtual machine and attempt to install the update, only to be greeted by this:

I go back to the download page, make sure I have the correct page

Which I do. But I note that ALL the file names are named ‘Windows 8.1’.

If you know your windows builds however, this is not really a surprise. Why? because each Server OS has a corresponding consumer build, the most common of which are as follows:

• Windows Vista => Server 2008 (NT 6.0)
• Windows 7 => Server 2008 R2 (NT 6.1)
• Windows 8 => Server 2012 (NT 6.2)
• Windows 8.1 => Server 2012 R2 (NT 6.3)
• Windows 10 => Server 2016 (NT 10.0)

As you can see, windows 8.1 is server 2012 R2, and given that most of the updates where applicable to the same code bases, everything is usually fine.

Still thinking I’d missed something somewhere, I downloaded all the rest of the files, and continued searching.

Very quickly I came across a multitude of forum posts, blog posts, stack overflow questions and much more, all reporting, or proposing solutions to the problem.

Long story short, most of the solutions ended up, install the smaller files (The ones supposedly in the larger one already), in various different orders, and while this may have actually installed the specific patches needed by .NET 4.6.2, it still didn’t install the specific KB patch number that the DN Installer was obviously looking for. Every link I came across that mentioned Server 2012 (Not R2) all pointed back to the windows 8.1 downloads already seen.

After what seemed like an age, I came across a random post, which had the same order of files in as I’d already seen many times already but, there was an extra KB number in the list, KB2919442

After some research, it turns out that this KB update is actually responsible for updating a system from W8 to W8.1 (or in my case SVR2012 to SVR2012 R2), not only this, but a windows server 2012 build with this applied, automatically becomes applicable for support again, and thus windows updates in general too

Once I installed this, I was then able to install KB2919355, and finally the .NET 4.6.2 run time.

The final say in installing these updates is this, definitely install KB2919442 first, then attempt to install KB2919355. If 2919355 fails to install, go back to the download page, download all the smaller components, then install them in EXACTLY this order: KB2932046, KB2959977, KB2937592, KB2938439 and KB2934018, then retry KB2919355. If nothing works after that, I don’t know what else to suggest, that all worked for me

Installing the build server

At this point I had a server instance, running IIS8 and capable of running C#6 generated DN4.6.2 applications. Now I needed to install some CI and build tools

In this day and age of Jenkins, Hudson, Team City and many other pointy clickity type CI services, I still prefer good old cruise control .NET (CCNet for short)

CCNet while verbose and needing to be configurable by writing XML, still remains one of the most dependable, stable and solid bit’s of CI software I’ve ever used. It’s unfriendly, and sure as hell let’s you know when you get things wrong, but once you get it working, it simply just grafts along and doesn’t falter.

I headed for the CCNet download page, and pulled down the installer, and set it away installing on the virtual server, 10 mins later I had the service up and running, and the web control panel running in an instance of IIS8

If we where just building projects using C#5 and below features here, then we would have been ok. Adding the “c:\windows\microsoft.net\framework\” path, to your system path variable, would have meant you had a standard “msbuild”, “csc”, “vbc” and other compiler tools available, and ready to rock and roll when asking CCNet to perform an MSBuild on your project

I’m not however…. (But you knew that already 🙂 ), I’m using C#6 and some of the nice new shiny stuff like string interpolation and expression body’s. All things that make the standard .NET run-time tools choke

The answer to making this work however, is to download the little known “Compiler Tools Download” from Microsoft. What this does is to install all the C# compilers and an updated version of MSBuild that understands them into a completely different folder inside program files

At this point you’ll also need to install the .NET 4.6.2 Targeting pack. Bizarrely enough, when you download and install the dot net run-times, you don’t actually install the system assemblies (Or at least not a set that can be used for compiling), so the targeting pack is also needed to make sure these exist to. Could we make this easier Microsoft????

If you start investigating this, you’ll find that many people advise installing Visual Studio 2015 on the build server, and in some cases removing it but leaving the tools behind. If your serious about doing CI correctly, then please, please DON’T do this. Simply just head to the link below, and download, and install the build tools as a separate install.

Once you get to this point, it’s just a matter of configuring your CCNet build script to use the new version of MSBuild to build the project. Take the “c:\Windows\Microsoft.net\framework” folder out of your system path, and instead add in “C:\Program Files (x86)\MSBuild\14.0\Bin” that way you can also test your MSBuild scripts yourself, directly from a standard CMD prompt on the server.

Final hurdle – NUGet restore

The last problem your likely to need to solve will be getting NUGet to restore any packages you use. If like many, you don’t check your packages into source control, this step will need to be performed before you can actually build your project.

As always there is a ton of different, and often conflicting information out there. For me, I ignored all of it, well mostly anyway…..

Instead, I downloaded the latest NUGet.exe binary from NUGet.org. I copied this into the MSBuild directory where all the other tools such as csc are. I then modified my projects .csproj file and added the following:

  <Target Name="BeforeBuild">
    <Exec Command="nuget restore ..\project.sln" />
  </Target>

The latest versions of Nuget have a command line option called restore, which when pointed at your project solution file will pull down and make sure any dependencies are matched up, automatically. Adding it as a before build step in your MSBuild file (Just near the bottom, after the comment that says “put your own custom rules here”) ensures that nuget restore gets run before any of the build processes are even attempted. I still have to work out, how I’m going to automate a few other things, such as “npm install” fro the front-end build system, but I’ll be doing a separate blog post on that, and configuring the CCNet configuration, to make the build system work.

Once you get to this point, then you should have a build server, that when configured, will check out the latest source, complete with C#6 features and running under DN4.6.2, then build it and report back on the build state. I’ll be further expanding things so that my client-app SPA get’s built, and then deploys out to the staging server, for now however, here’s the prmised links you’ll need:

• KB2919442 download (Install this one first)
• KB2919355 download
• Dot Net 4.6.2 Runtime
• Crusie Control .NET
• Visual Studio 2015 Build tools
• Dot Net 4.6.2 Targeting pack
• NUGet command line tool

All the links presented above, where correct at the time of writing.(February the 2nd 2017)