When you develop for Windows Azure for the first time, there are a couple of things that you have to be careful about, in order to deploy your application successfully.
For this checklist (to be more complete) I will use a Silverlight Application with WCF RIA Services and Entity Framework 4.0. It is great and Windows Azure already supports .NET 4.0 along with all the goodies that come along with it. I will show the application in another post, now it is more important what we have to do in order to successfully deploy our application. I will not put them in ordered list, because if you fail in any, your application will cycle through “initializing – busy – stopping – initializing – busy – stopping”.
You can download the source solution from here.
· Diagnostics connection string
Whenever you choose to create a new Web Role, a WebRole.cs file is added to your web application. It is very important part of your Windows Azure Web Role. It gives you the possibility to intercept the Start and Stop events of your Web Role and do some initializing or cleaning up. It also starts the Diagnostics Monitor, which is something you can’t live in Azure without! The Diagnostics Monitor uses Azure Storage to save diagnostics logs, that’s why it needs a connection string. This connection string, however is set to use development storage by default:
It is very easy to change that connection string – just right click on your Web Role from the Cloud Service project choose Properties, then select Settings from the left navigation tabs. Now click on the […] button which is located right next to the Value string and new window will appear:
You have to enter storage credentials. A good practice is to always use HTTPS endpoints. The Account name and Account key, you can get from the Azure Developer portal. Once you create an Azure Storage service, you can give the account name, and the keys are generated from the portal:
You will have to go to Windows Azure (1) and then select your Storage Service (2). Your account name (4) and account keys (5, 6) are located within main Cloud Storage settings area (3). You can use either of the keys – Primary (5) or Secondary (6) as configuration.
You are done. Of course the Windows Azure Storage service can be accessed from any place with internet connection, so now you can start and run your application to check out if it will run smoothly on local development fabric.
· References in Web Role
Dealing with References can be really annoying in Web Roles & Worker Roles! You have to be very careful – you have to select Copy Local = True, for each and every assembly that you refer and that is not part of Core .NET Framework 4.0. This of course includes any third party assemblies (such as NetAdvantage for .NET). More interesting for you to find out, that you have to set Copy Local to True even for the following assemblies:
Microsoft.WindowsAzure.Diagnostics
Microsoft.WindowsAzure.StorageClient
The WindowsAzure part of the names of these assemblies would make you think that they must exists on the Azure VM, but they don’t! However the Microsoft.WindowsAzure.ServiceRuntime is part of Azure VM deployment, and you can safely leave it as Copy Local = False.
Working with WCF RIA Services, you will also have to set this attribute (Copy Local) for all RIA assemblies:
System.ServiceModel.DomainServices.EntityFramework
System.ServiceModel.DomainServices.Hosting
System.ServiceModel.DomainServices.Hosting.OData
System.ServiceModel.DomainServices.Server
· Target CPU Architecture
Windows Azure uses 64 bit CPUs and the operating system (Windows Server 2008 based) is x64. So your assemblies – any and all assemblies that run as part of your Web Role should be compiled as either “Any CPU” or “x64”. In very rare situations, when you use Worker Role, you can use x86 assemblies, but you can only execute them in separate process, that is not part of the Role! The target CPU architecture is managed from "Configuration Manager". You can launch the configuration manager by right clicking on the Solution in Solution Explorer and selecting "Configuration Manager". You will see the following dialog:
Most probably you've never seen this dialog, but it is something that you have to pay attention when developing for Azure!
· Web.config issues
As you may already know – Windows Azure Guest OS is Windows 2008 based. That means your web roles are run on IIS 7. So any configuration that is not compatible will cause your web role to not start and begin cycling.
Well, this is first, not fully complete, but the very first checklist you have to check even before you are going to deploy your WebRole!
