Run ASP.NET MVC on Windows Azure
If you’ve purposefully been ignoring the announcements out of PDC, I don’t blame you one bit. Everybody knew it would be the unveiling of Microsoft’s “cloud computing” initiative, and just about the only thing we didn’t know was the official name of it: Windows Azure. And of course I pronounce it wrong every time (I say “ah-jour”, as in “soup-de-jour”). It’s hard to call it “initiative” when they’re the 3rd one to bring a product to the table. 
One thing I was looking forward to was hearing about the ASP.NET MVC story on Azure. So color me surprised when I found out there wasn’t one. Since ASP.NET MVC is bin-deployable it shouldn’t be impossible, and doing some quick searches didn’t retrieve any results showing anybody else having tried this. Of course later I discovered that Phil and Eilon had whipped up a sample app that ran ASP.NET MVC on Azure, but was pleased to find out that the downloadable sample app didn’t work. In fact, it seemed to just be MVC stuff slapped into a WebRole project. (I’m guessing something got “lost in translation” since it wasn’t Phil or Eilon that posted the code.)
Anyway, here’s how you can get ASP.NET MVC up and running on Azure. I’ve created a Visual Studio template for this to make it easy to set up – download it here. To avoid distributing code that isn’t my own (i.e. Windows Azure SDK Samples) there are a few steps you’ll have to take. I’m presuming that you’ve already installed the Windows Azure SDK and the Azure Visual Studio tools.
One thing that running a web application “in the cloud” means is that you can instantly scale higher by adding more “instances”. This means the leaky-as-a-sieve abstraction of “session state” isn’t immediately available (finally!) since any given HTTP request could be going to a different server. The default session state provider for ASP.NET is an in-memory provider. This assumes that every request comes to the same physical machine. Session state providers have varied in their reliability and handling of scalability, but the other built-in providers include an out-of-proc provider (still same machine, but more resilient to IIS going up and down) and a SQL Server provider. None of these are enabled on the Azure platform, for good reason.
The limitation of zero session state wouldn’t matter except that ASP.NET MVC includes the concept of “Temp Data”, which is data persisted in one request and made available to the next request only. By default, MVC uses the session to store this data.
Aside: like it does everywhere else, ASP.NET MVC allows you to swap out default implementations for TempData persistence. A better solution than what I have below is to specifically implement a TempDataProvider that uses the Azure data storage capabilities. Look for that soon.
Fortunately for us the Windows Azure SDK includes some “samples”, including full implementations of membership, profile, and session providers built on the Azure data storage platform. So let’s hack those in to fulfill the default requirements of ASP.NET MVC. The only thing that I’ll say about this is that much of this stuff had better be baked into the SDK/platform by the time it goes GA. This is just a CTP, and Microsoft has been doing better at earlier community releases, so I’ll cut them some slack. But this is way to much work to be a reasonable shipped solution.
Unzip the “samples.zip” file in the Azure SDK and build the “AspProviders” application.
They’ve conveniently included “buildme.cmd” batch files, but I built the application using Visual Studio since I like to see more of “what’s going on” (even though I really don’t see more, per se).
Create the required tables in the Azure Development Storage.
Open the Azure SDK command prompt under your start menu, and navigate to the directory containing the AspProviders output. Run the command “devtablegen” passing in the assembly name “AspProviders.dll”. This command creates the appropriate database structures to persist objects that meet certain criteria. Run devtablegen with no parameters for a short description, or check out the documentation for more info as well.
You’ll get a confirmation window that displays progress and shows that the table was created successfully.
Start the Development Storage service.
By now, the storage service should be running, but you’ll need to explicitly enable its endpoints. Open the UI from the system tray icon (
), and click “Start”. If you’ve never started it before, it will ask you for the name of the database – select “AspProviders”.
Create a new Cloud Service and add an “ASP.NET MVC Web Role” project.
Download the Visual Studio template I created here. Import the template by copying the downloaded .zip file to “My Documents\Visual Studio 2008\Templates\Project Templates” (or whatever you have specified in Tools – Options – Projects and Solutions – General). Create a new “Blank Cloud Service” project.
Add a new “ASP.NET MVC Web Role” project using the installed template.
Your VS solution should now approximate this:
Under the “Cloud Service” project, right-click on the “Roles” folder and select “Add > Web Role Project in solution…” and select the web role project we just added.
Cleanup
Because I can’t distribute the compiled version of the sample app, and because the location of it on your drive depends entirely on your personal preferences, you’ll have to re-add the references manually. From the ASP.NET MVC Web Role project we added, delete the references to AspProviders and StorageClient
and re-add the references pointing to the assemblies we built above.
Press F5, and you’re up and running the default ASP.NET MVC sample app on the Windows Azure platform! From there the sky’s the limit. Or maybe “the cloud’s the limit”?
