There are several reasons for setting up Continuous Integration for any project. The very same reasons (and some more) are true for an Azure project. In this post I’ll take you through the journey that I and a colleague travelled in our quest for a fully automated build-test-deployment solution for our Azure project.
In order to reach our goal we need to:
Let’s get started!
As it is, our build server can build basic projects without any problems. But, as we soon found out, it could not build Azure projects. So my goal here is to describe all the issues that we ran into and how we solved them. Hopefully this will help some of you trying to do the same thing.
As I mentioned before our goal was to avoid installing Visual Studio on the build machine. We decided this for several reasons. I guess that the main reason had something to do with developer pride… Simply put, it should not be necessary to install a full development environment on a build server just to build an Azure project.
Anyway, we started out with installing Windows Azure SDK on the build server triggered our first build.
The type or namespace name ‘WindowsAzure’ does not exist in the namespace ‘Microsoft’
Well this isn’t good is it? We installed all Azure assemblies but it still refused to find them. Well, the solution for this problem is apparently to copy Microsoft.CloudService.targets from your development machine to the build machine. The file is located at C:Program FilesMSBuildMicrosoftCloud Servicev1.0.
WAT050 : The version of the Windows Azure SDK currently installed is not compatible with this version of Windows Azure Tools for Microsoft Visual Studio. Please download and install the latest version of both the Windows Azure SDK and the Windows Azure Tools for Microsoft Visual Studio
Wait, what? We have already installed that, right? We’ll for some reason this wasn’t quite enough. I order to solve this problem you first need open up the Registry Editor and navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SDKsServiceHostingv1.3. There you have an entry called ToolsVersionSupportLevel. Note the number, in our case is was 7.
Now navigate to Microsoft.CloudService.targets that you copied in the previous step and open it. Now find the element <ServiceHostingVSSupport> and change the value to whatever number you found in the registry. Some of you might call this a hack, I like to call it pragmatism.
MSB4057: The target "PipelineTransformPhase" does not exist in the project.
It seems that this informative message tells us that it misses the file Microsoft.WebApplication.targets. In order to get rid of this error you need to copy C:Program FilesMSBuildMicrosoftVisualStudiov10.0Web to your build server. This wasn’t easy to figure out… you’re welcome.
Need to specify the physical directory for the virtual path ‘Web/’ of role MyProject.Web.
Ah, this error actually made some sense. Or well, I don’t exactly know why we got this error, but the solution was at least not that hard to figure out. Since one of our Azure roles is a WebRole, we need to specify its physical directory in ServiceDefinition.csdf. So find the element <Site> and add the attribute physicalDirectory=”..MyProject.Web” (assuming that your WebRole’s name is MyProject.Web… which it’s probably not).
error MSB4019: The imported project "C:Program FilesMSBuildMicrosoftVisualStudiov10.0Windows Azure Tools1.5Microsoft.WindowsAzure.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Noted by Andreas Hallberg, just copy copy the "Windows Azure Tools" dir to buildserver C:Program FilesMSBuildMicrosoftVisualStudiov10.0
That’s it! Now our build server built our Azure project, ran all the test with coverage and doing this without complaining. First step done!
The next step was to build our package file. You know, the same file that gets generated when you select publish in Visual Studio. This is basically an encrypted zip file containing all your assemblies needed to run your Azure roles. In order to have our build server build the very same package, we wrote a simple MSBuild script that invoked cspack. It looked something like this.
<?xml version="1.0" encoding="utf-8" ?>