One of the major benefits of the Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio is the ability to operate an Azure Development Fabric and Azure Development Storage emulation on your local machine.  Pressing F5 in a Visual Studio Azure project deploys and runs your application in an environment emulating the real Windows Azure.  This is somewhat similar to the ASP.NET Development Server that starts up and somewhat emulates IIS (or other ASP.NET hosting environment) when you debug an ASP.NET application.

This is great, but can also create an efficiency bottleneck during development.

If you are debugging a regular ASP.NET application and you need to make changes, in many cases you can stay in debug mode;  you can edit an ASPX page or other assets (including CSS) and simply refresh the already running web browser instance to see you changes.  In the case of the ASPX page having changed, it is dynamically recompiled when you next access it.  This works because the ASP.NET Development Server is pointing at your development files.  This efficient cycle is lost when you start debugging with the Windows Development Fabric…

When you debug (or run) an Azure project in Visual Studio, your application is built into a package that is ‘deployed’ to the local Azure emulation.  The emulation therefore uses its own copy of the files.  Making changes to the file in Visual Studio while debugging, only updates the copies under Visual Studio’s control – they are neither repackaged nor redeployed.  The Azure Development Fabric has no idea that they’ve changed.  So, you have to stop debugging, re-launch, wait for the new package to build and deploy, and then get back to the same place in the application.

Here’s what likely amount to a satisfactory workaround before you are ready for the emulation stage:  create a mock for the Data Access Layer that deals with Windows Azure Storage and debug your project outside of the Azure Development emulation.  You lose role instance configuration, but you can go back to using the ASP.NET Development Server.  You may also lose the Azure diagnostic logging – but you can mock that too.

Note:  If you are using SQL Azure, for the most part you can use a regular local SQL Server in place.

I’m not suggesting you mock the interfaces to the Azure APIs directly.  Your application may well have a Data Access Layer which (when following best practices), will likely have an interface.  I suggest you create an object to mock this using the same interface or perhaps use one of the available mocking frameworks.

To facilitate the selection of the polymorphic DAL objects (real or mock) in one code-base you’ll likely want to make your application smart enough to know if it’s running in the Azure environment (Microsoft or local emulation) or not.  My previous post on the topic explains this idea.

You’ll need an interface that suits the operations of your DAL such as this example (where WallMessage is defined elsewhere)…

a mock object (such as the example shown below) and a real object (not shown) that both implement the interface…

and then calling code that first selects the mock or real object to use based on environment detection……

after which you go on to use properties and methods on the selected interface oblivious to the implementation being used.

This is just a basic example and as mentioned, there are some very good Mocking frameworks as well as Dependency Injection frameworks available that ease this kind of setup in large or complex solutions.

The code shown is from the sample Silverlight application I provide (including source code) in my Azure Deployment Guide, already used by 100s of people to successfully deploy their first Azure application.

I hope you found this tip useful 🙂 If so, and you’re reading this on January 15th 2010 then please vote for my Mix 2010 conference submissions today! :)  Thank you.

Looking to learn more about the Windows Azure Platform, Silverlight, Windows Touch or Windows Identify Foundation? If you’d like to see these sessions in person at Microsoft’s Mix 2010 conference or the recordings that will likely be made available for free later on, please vote for the sessions before January 15th 2010, by going to the site, adding the 3 sessions to you ballot and submitting it.