Upgrading to Azure 1.7 SDK: Visual Studio build and publishing problems

We recently went through upgrading www.leansentry.com to the Windows Azure SDK version 1.7, and definitely hit a fair share of problems with building and publishing afterwards.  It was a somewhat painful process taking me deep into the night, and I figured I’ll share some of the things I learned along the way to make it easier for others.

Here are the issues and what we had to do to fix them:

(Disclaimer: this is “what we did” information based on our experience with installing 1.7, rather than the official how-to)

1. Where can I download Windows Azure SDK 1.7?

Don’t go looking for Azure 1.7 in Web Platform Installer (if you have the 3.0 version).  Suprisingly,  its not there.  You have to install Web Platform Installer 4.0 to get it.

Options:

A) Install automatically using Web PI 4.0 (option we used).  

– Get Web Platform Installer 4.0: https://www.windowsazure.com/en-us/develop/net/
– Install the Windows Azure SDK 1.7 via WPI:  https://www.windowsazure.com/en-us/develop/net/

(credit goes to Lars for his post about this here)

B) Download all the components individually (yeah right):  http://www.microsoft.com/en-us/download/details.aspx?id=29988

Other installation notes:

–  You need to uninstall old versions of Windows Appfabric Cache before installing, otherwise the installation of Windows Azure tools v1.7 will fail.

2. Upgrading your Visual Studio Azure projects to Azure SDK 1.7

The official way seems to be using Visual Studio project properties of your Windows Azure project after installing the Azure SDK 1.7.  Here is an example.

This will also trigger a conversion of the project, and make changes to the .csdef files.

Now, I have to be honest and say we didnt find this button.  We ended up making manual changes to the project files.  If you need to make them, here they are:

1) Unload the project file (Right click on project, click “Unload project”)

2) Edit the project file (Right click on unloaded project, click “Edit X.csproj”)

3) Change the product version to 1.7

<ProductVersion>1.7</ProductVersion>

4) Change the Azure tools version to 1.7

<CloudExtensionsDir Condition=” ‘$(CloudExtensionsDir)’ == ” “>$(MSBuildExtensionsPath)MicrosoftVisualStudiov$(VisualStudioVersion)Windows Azure Tools1.7</CloudExtensionsDir>

5) Save the project file, and reload the project

6) This should activate the conversion wizard which will then make changes to your .csdef file, adding the following schema version attribute:

<ServiceDefinition name=”SentinelWebAzure” xmlns=”http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition” schemaVersion=”2012-05.1.7″>

NOTE: If you are getting a build error complaining about the schema version, that is because you dont have the right cloud extension dir setting applied.  See step #4.

3. Azure referenced assemblies fail to load after upgrading to Azure SDK 1.7

By default, after you install the Windows Azure SDK 1.7, your solution will now build with the 1.7 version libraries.  However, if you have project components that reference prevoous versions of the SDK, they will fail to resolve the assembly reference and fail at runtime.

This is the most likely cause of Azure roles continually recycling after upgrading to the v1.7 SDK.  This will likely happen even if you have references to specific versions of the Azure DLLs in your source tree, because in our experience VS will always publish the 1.7 versions (its possible we didnt have the right combination of SpecificVersion settings in our 133 projects).  Either way, you upgraded to 1.7, didnt you? Presumably because you want to use 1.7 DLLs.

If you are lucky enough to TS into the recycling instance and pull up the event log (or if you are using LeanSentry), you may see:

System.IO.FileLoadException was unhandled by user code Message=Could not load file or assembly ‘Microsoft.WindowsAzure.Diagnostics, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

System.IO.FileLoadException was unhandled by user code Message=Could not load file or assembly ‘Microsoft.WindowsAzure.StorageClient, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

and so on …

This is because you may have configuration or  assembly references in your deployment that point to previous versions of the Azure assemblies via strong name signatures.  You should go through your entire project and update your references to 1.7 versions.  However, a fast fix may be to set up assembly binding redirection to point all references to Azure assemblies to the 1.7 versions.

Put this in your web.config for web role projects or app.config for worker role projects:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <!-- Upgrade to Azure SDK 1.7 -->
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.WindowsAzure.StorageClient"
            publicKeyToken="31bf3856ad364e35"
            culture="neutral" />
            <bindingRedirect oldVersion="1.1.0.0" newVersion="1.7.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.WindowsAzure.Diagnostics"
            publicKeyToken="31bf3856ad364e35"
            culture="neutral" />
            <bindingRedirect oldVersion="1.1.0.0" newVersion="1.7.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.WindowsAzure.ServiceRuntime"
            publicKeyToken="31bf3856ad364e35"
            culture="neutral" />
            <bindingRedirect oldVersion="1.0.0.0" newVersion="1.7.0.0" />
        </dependentAssembly>
    </assemblyBinding>
  </runtime>

This will cause the assembly loader to look for 1.7 assemblies when resolving references to previous versions of the Azure assemblies.

4. And the most important thing is: republish your Azure project!

Your deployment will need to be upgraded to v1.7 of the SDK.  This happens when Visual Studio publishes your project.

That’s it.  If you hit any other issues, comment below and we will do our best to help.

Best,

Mike