This is an ongoing series on Window’s Azure. The series starts here, and all code is located on GitHub: https://github.com/mmooney/MMDB.AzureSample. GitHub commit checkpoints are referenced throughout the posts.
I’m assuming that you have Visual Studio 2012. Now go install the latest Windows Azure SDK. Go go go.
So the first thing we are going to do is build a simple Windows Azure web application. To do this, we’ll create a new VS2012 solution:
And we’ll create a plan old MVC web application:
Now we have a empty project, and add in a Home controller a view, we have ourselves an simple but working MVC web application.
Now Let’s Azurify This Fella
Now if we want to deploy this to Azure, we need to create an Azure project for it. Right-click on your project and select “Add Windows Azure Cloud Service Project”
That will add a bunch of Azure references to your MVC app, and will create a new wrapper project:
Now if you can still run the original web application the same as before, but you if you run the new Azure project, you’ll get this annoying, albeit informative error message:
Ok so let’s shut it all down and restart VS2012 in Administrator mode.
(Tip: if you have a VS2012 icon on your Windows toolbar, SHIFT-click it to start in Admin mode)
When we come back in Admin mode and run the Azure project, it’s going to kick up an Azure emulator:
And we get our Azure app, which looks much the same as a our existing app, but running on another port:
The idea here is to simulate what will actually happen when the application runs in Azure, which a little different than running in a regular IIS web application. There are different configuration approaches, and the Web/Worker Roles get fired up. This is very cool, especially when you are getting started or migrating an existing site, because it gives you a nice test environment without having to upload to Azure all the time.
However, the simulator does have it’s downsides. First, requiring Administrator mode is annoying. I forget to do this EVERY TIME, and so right when I’m about to debug the first time, I have to shut everything down and restart Visual Studio and reopen my solution in Admin mode. Not the end of the world, but an annoying bit of friction. Second, it is SLOW to start up the site in simulator; not unusably slow, but noticeably and annoyingly slow, so I guess it’s almost unusably slow.
To combat this, I try to make sure that my web application runs fine all the time as a regular .NET web application, and then I just test from there. Then before I release a new feature, I test it out in simulator mode to sanity check, but being able to run as a vanilla web application makes everything a lot faster.
Also, and this is important, it forces you to keep your web application functioning independent of Azure. Besides the obvious benefit of faster debuggability, it also ensures that your application has enough seams that if we had to move away from Azure, you can. I’ve gone on and on about how great Azure is, but it might not be the right thing for everyone, or might stop being the right thing in the future, and you want to have the option to go somewhere else, so you really don’t want Azure references burned in all over the place. Even if you stay with Azure, you might want to replace some of their features (like replacing Azure Table Storage with RavenDB, or replacing Azure Caching with Redis). We’ve used a few tricks for this in the past that I’ll get into in some later blog posts.
Next we’ll actually deploy this thing to Azure, but first we need to setup an account, which we’ll do next. Get your checkbook ready (just kidding).