Upgrading to the Windows Azure 1.7 SDK
The Windows Azure 1.7 SDK has been out for a little less than 3 months, and with the RTM release of Visual Studio 2012 it might be a good opportunity to upgrade your existing applications to the new version of the Window Azure SDK. You can install the required components for this new version through the Web Platform Installer or by downloading them from the Windows Azure website. After installing these components you can simply open your project to make the switch to the new version. In some cases, you’ll get a dialog asking you to convert to the new version of the Windows Azure tools. There are other cases where you’ll need to go to the properties of your Cloud project an manually choosing Upgrade under Application.
For most projects this will do the job (especially with new applications). But in other cases things might go wrong when testing the application locally or after deploying to Windows Azure. The first thing to note is that your config files won’t always be upgraded how they should (maybe you’re doing transformations from template files and the upgrade process didn’t pick up those files). The issue you’ll typically encounter will be related to the trace listener.
<system.diagnostics> <trace> <listeners> <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=220.127.116.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics"> <filter type="" /> </add> </listeners> </trace> </system.diagnostics>
You might need to scroll to the right, but you’ll see that in the pre-1.7 SDK the version of the DiagnosticMonitorTraceListener was 18.104.22.168. If you notice your logs suddenly don’t work anymore you’ll need to find any instance of the DiagnosticMonitorTraceListener and change its version to 22.214.171.124. Also code like in the following sample should be modified and updated to the new version.
if (RoleEnvironment.IsAvailable) Trace.Listeners.Add(Activator.CreateInstance(Type.GetType("Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35")) as TraceListener)
A good place to start looking for these old versions would be your configuration files. These include the web.config for Web Roles, the WaIISHost.exe.config for Web Roles (when you’re logging from your WebRole.cs), the app.config of your Worker Roles, … Also don’t forget if you’re doing web/app.config transformations and you’re storing the ‘real’ configuration file in an other file you should also update that template file.
Windows Azure Frameworks and Toolkits
If you’re working on a Windows Azure application you have probably used some NuGet packages to support your application, like TOPAZ (Microsoft Transient Fault Handling Application Block). And these frameworks/toolkits might still be targeting an older version of the SDK, causing errors like these:
Could not load file or assembly ‘Microsoft.WindowsAzure.StorageClient, Version=188.8.131.52, Culture=neutral, PublicKeyToken=31bf3856ad364e35′ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0×80131040)
Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.AzureStorage.StorageTransientErrorDetectionStrategy.CheckIsTransient(Exception ex) +0 Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.AzureStorage.StorageTransientErrorDetectionStrategy.IsTransient(Exception ex) +21 Microsoft.Practices.TransientFaultHandling.RetryPolicy.ExecuteAction(Func1 func) +557
Well for the TOPAZ users I have good news, the August 2012 Update was released 2 days ago: Microsoft Transient Fault Handling Application Block ("Topaz") – August 2012 Update. But there are still some great packages on NuGet targeting the old version, like Lokad.Cloud.Storage. For these packages you will want to use assembly binding redirects to fix any possible issues with version numbers. This is possible by making the change to your configuration file (web.config/WaIISHost.exe.config/app.config):
<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Microsoft.WindowsAzure.StorageClient" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="184.108.40.206" newVersion="220.127.116.11" /> </dependentAssembly> </assemblyBinding> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Microsoft.ServiceBus" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="18.104.22.168" newVersion="22.214.171.124" /> </dependentAssembly> </assemblyBinding> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Microsoft.ApplicationServer.Caching.Core" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="126.96.36.199" newVersion="1.0.4655.0" /> </dependentAssembly> </assemblyBinding> </runtime>
The June update of Windows Azure brought some cool and shiny features like Virtual Machines, Web Sites, … (see the complete overview on Michael S. Collier’s blog). But the existing components like Windows Azure Storage did also get a well deserved updated. The Windows Azure Storage blog announced some interesting features, including "Expanded Blob Copy", a way to copy blobs between storage accounts. Know that this new feature only applies to destination storage accounts created after June 7, 2012. And if you want to use this functionality from .NET you’ll need to upgrade to version 1.7.1 of the SDK.
We’ve covered most issues you could encounter when upgrading to version 1.7 of the SDK and we saw why you might want to migrate your existing storage accounts to new storage accounts. If you want to stay up-to-date with the versions, keep an eye out for updates on NuGet (you’ll see version 188.8.131.52 of the ConfigurationManager and version 184.108.40.206 of WindowsAzure.ServiceBus).