How to build ASP.NET applications in TeamCity with MSBuild Tools 2013 and .NET Framework 4.5 SDK
It’s time to set the newly installed TeamCity-server from my previous post to do some actual work.
The goal in this post is simply to get a simple ASP.NET webproject to build in TeamCity, without installing Visual Studio on the build server. We will create a new (simple) web project, with no database and no authentication. And we will install the required tools and frameworks on our buildserver. And hopefully get it to compile our project.
One of the first things I usually do when I start on a new project is to set it up in TeamCity. It’s easier to get a small project to initially build, and I get early feedback when I do something that breaks the code. Could be something like a reference to a file that only exists on my computer, but is not checked in to source control or in exists in other environments.
To get an easy start, we create a template-project and add it to our source control system of choice. My solutionname is OrbitalJournalism and the project name is OrbitalJournalism.Web. You can use my OrbitalJournalism on GitHub if you just want to get started configuring TeamCity serverside.
- Create a new ASP.NET Web Application (in VS2013)
- Select MVC as a template
- Change authentication to “No Authentication”
Configure the TeamCity server
Let us get started on the server side. Log on to your TeamCity server (remote desktop) and start the install-next-next-finish dance.
Install Microsoft Build Tools 2013
We need to install Microsoft Build Tools 2013 [more]. Open up a browser and go to Visual Studio Downloads, scroll down past Additional software and click Microsoft Build Tools and click Download now. Run BuildTools_Full.exe (17.5 MB), Agree and Install… And Close.
If we would try to run a build now it would fail, with the following message
error MSB4019: The imported project “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets” was not found. Confirm that the path in the
declaration is correct, and that the file exists on disk.
You can read more about the WebApplication.target error in this question on Stack.
To fix this error you can copy the folder (from a machine with VS 2013 installed)
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0
to the TeamCity server. If you don’t have access to a machine with Visual Studio 2013 installed, you can download the v12.0 folder in a zipped file from my DropBox. Place the v12.0 folder in the same location on the buildserver as on the dev-machine. When finished the path of the Microsoft.WebApplication.targets file should be like this
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets
Install .NET Framework 4.5 SDK (and other SDKs)
There is still one error that would have shown up if we tried to run the build now
warning MSB3644: The reference assemblies for framework “.NETFramework,Version=v4.5” were not found.
Go to Windows Software Development Kit (SDK) for Windows 8 and click Download now. As stated on the page: You can use the SDK to build applications that target these operating systems: Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008.
In the installer select “Install new or updated features…” and click Next, Accept. When prompted to Select the features you want to install, deselect everything except the .NET Framework 4.5 Software Development Kit.
Edit! Here is a short list of SDKs:
- Microsoft .NET Framework 4.6.2 Developer Pack
- Windows 8.1 SDK (.NET 4.5.1)
- Windows 8 SDK (.NET 4.5)
- Windows 7 SDK (.NET 4.0)
- Windows Azure SDK 2.5
You could do a restart of the TeamCity server at this point to make sure everything loads up nicely.
Now, with a simple web project in sourcecontrol and the required tools and frameworks installed on the server, let us try to get the solution from source control and compile it on the buildserver.
Open up a browser and navigate to your TeamCity server. If this is your first time navigating around in TeamCity, it might be a bit intimidating. But give it some time and this too shall pass.
We created a new project in Visual Studio, but now we need to create a project in TeamCity. I will name my (root) project the same as the solution we created, OrbitalJournalism. TeamCity will suggest projectId to be the same, and that’s OK. Click “Create”, and the administration page for the project is displayed.
Create VCS root
Select the VCS Roots tab, and click Create VCS root. Here our ways may part, because this step depends on what kind of sourcecontrol you are using. You can read more on configuring VCS roots on JetBrains pages.
If you use my OrbitalJournalism repository from GitHub take a look at this screenshot to see how it should look like. I name my VCS root OrbitalJournalism master because it will point to the master branch of this projects source control repository. And the VCS root ID, OrbitalJournalism_Master. Make sure the Test Connection is successful, and save.
Create Build Configuration
If you find yourself lost, and don’t find your newly created project, select Administration next to your username in the top right, and on that page click your project.
Select the General tab and click Create build configuration. The free version of TeamCity lets you create 20 build configurations. Pretty nice! I name my build configurations after what it does eg. Build master. Let the other parameters stay their default values. Click the VCS settings button. Since we already created a VCS root, we select the one we created from the dropdown Choose VCS root to attach, and click the Add Build Step button.
To make sure we don’t lose our progress so far, just hit Save without choosing any build runner type.
Add build parameters
Again, if you are wondering where you should be, don’t worry, let’s make sure we are on the same page… On the Project page, click the caret next to the Build Configuration, and click Edit Settings.
On the right side, you have the different settings for the current build configuration. Go to number 7 Build parameters. Here we can add parameters that the build configuration can use. Parameters can be declared one level up, on the project, and would then be available for all the build configurations within that project. For now, we declare it directly on the build configuration.
Click Add new parameter. Set Name to be SolutionPath. The Value should be the solution file path relative to your folder structure in source control. If your solutionfile (sln) is in the root of your sourcecontrol repository it is just to put the solutionfilename in the value field. Click Save.
Add the first build step
The Build Steps are the part that do the work eg. run tests, compile code, deploy. Select 3 Build Steps, and click the Add build step button.
Select NuGet Installer and under NuGet settings, NuGet.Exe should be set to default (not yet selected). The Path to solution file will need to be the .sln file path. But hey, we declared that in our build parameters. So here is some TeamCity magic. Start typing %sol and an autocomplete box shows up. Select SolutionPath. We know that the value of this parameter is the path to our solutionfile. Nice.
Before we forget, we should set the default nuget.exe file for our first build step so it doesn’t fail. Go to Administration (top right), then NuGet settings in the left menu. Now select the tab NuGet.exe. Click the Fetch NuGet button, select the newest (at the moment 2.7.3), and make sure the Set as Default checkbox is checked. Click Add.
Add the second build step
Get back to the build configuration settings page and select number 3 again (now option number 3 has changed name to Build Step: NuGet Installer). Click Add build step, and now we select Visual Studio (sln) from the Runner type dropdown. You do not have to set a step name, but you could put in something like, Build solution.
What do you know, there it is again, the Solution file path. What was the path and solution name again? Ahh, never mind, use the parameter %SolutionPath%.
The Visual Studio dropdown is by default Visual Studio 2013 which is fine since we are working on a solution created in VS 2013. Targets is Rebuild and Configuration is Release, which all is fine for now. We will play more with these parameters later in another post. For now, lets just focus on getting the solution to build, click Save.
Build baby, build!
Now I really hope that you got the green light! If you didn’t, hit the carret next to “Failed” and take a look at the build log. The build log contains a lot of information of what happens in your build configurations and are a very useful. But it takes some practice to find out what really is going on.
Was that it?
Well, that was it for now. If this was your first time setting up a build server and you got the code to build, consider this a great day! From now on only your imagination, and some technical issues along the way, can stop you from creating a fully automated build, test and deploy system.
In the next post I will show you how to deploy the webproject using WebDeploy. So for now, let us take a step back and look at our first successful build in TeamCity.