Windows Azure local development environment speed

I've started porting an existing ASP.NET web app to Windows Azure 开发者_如何学运维and have noticed that the development process is really slow. Each time I make a change to my code and want to view it, I have to effectively redeploy it to the local dev cloud (using Start debugging (F5) or Start without debugging (Ctrl-F5). The process itself takes over a minute, during which time Visual Studio is completely unresponsive.

Am I doing something wrong or is that simply how things are developing for Azure?

My specs:

• Visual Studio 2008 9.0.30729.1 SP
• 5 projects running on .NET 3.5 SP1
• Azure SDK 1.1 (February 2010)
• Single instance of a single web role
• Dual-core AMD 64 machine with 8GB RAM, 64-bit Windows 7, fully patched
• The main project itself is quite large (3k files, ~200k lines) but compiles normally in 10-15 seconds

If your web role has limited functionality, you might be able to just set the Web project as the Active Project in your VS solution and run from there.

For example, my web role doesn't call into table storage, blob storage, etc... it just makes some Azure logging calls and interacts with SQL Azure. So sometimes I just set the web project to be the startup project in the VS debugger, not Azure, and run from there. I've properly written my logging calls to check if Azure is available before they write, so they don't execute in this situation.

Of course, if you're doing lots with table storage, queues, blobs, etc. then this is not for you.

Normally in a development machine we just compile and run the solution. In case of Azure development there is a additional step where the specific project is deployed in the Dev fabric which involves copying the complete web site content to the dynamically created deployment folder. Since you have a large number of files this would require all those files to be copied into a new folder every time you press F5 or Ctrl-F5. This may cause the delay you are noticing.

This scenario also highlights the inflexibility in deploying the solution over the App fabric. Any time you change any content (static or dynamic) in the website the complete site has to be packaged and re uploaded on your production server.

In my case when I changed the port from 80 to something else (under end points) the speed returned to normal.

Microsoft's Steve Marx has a blog post about running a website from a mounted VM in Azure. This may be a good development pattern since you simply update the contents of a VM stored in blob storage instead of having to redeploy to the fabric each time.