I spent a frustrating week dealing with Azure deployment.
One of the most irritating things for me about Azure is that sometimes you can screw up an Azure package but this wont be revealed until you try and deploy it as it will remain in the starting state. As the time a role can take to start up varies this is doubly annoying as you dont know whether it has failed yet!
But wait – surely Azure would give you a bit of information regarding why it cannot start up your role?
Well no although this potentially changes with Azure Tools 1.3. Version 1.3 of the tools allow you to remote desktop into the role and may or may not offer additional information..
So what kind of things can cause a role to remain in this state and consider sacrificing small animals to the azure gods?
From my experience:
1) Not including required assemblies- make sure all necessary assemblies are set to copy local. Azure is not your machine and may not know about your assemblies
2) Corrupt configuration
3) Storage wrongly configured e.g. leaving your role pointing at devstorage4) Wrongly configured or missing certificates
4) The moon moving into Venus’s orbit..
When you package Azure roles by default they are encrypted (devfabric packages are not) which can make it tricky to spot missing assemblies etc. You can disable this by creating a new system environmental variable called _CSPACK_FORCE_NOENCRYPT_ and setting it to true (see http://blogs.msdn.com/b/jnak/archive/2009/04/16/digging-in-to-the-windows-azure-service-package.aspx). You can then change the .cspkg extension to zip and browse the contents of it. Note the team say this technique is unsupported so may stop working in a future version of the tools.