Moving an Entity Framework Code First Database and Appication to Azure

Home / Moving an Entity Framework Code First Database and Appication to Azure

I’m still playing with Azure and getting a full fledged application working and hosted using the Azure services. As I showed yesterday, setting up a Web App is pretty easy.

The next step for me involves moving an Entity Framework Database using Migrations to Azure.

I found this to be a pretty straight forward process. In creating my Web App, I had already created a free 20MB Azure DB and called it “long2know_db.”

Browsing to to the Azure portal and viewing our Database instances, we’re interested primarily in retrieving an ADO.NET connection string.

Once we have the connection string, we can modify the web.config in our Web application to utilize this database/instance.

After adding this bit of set-up, all that’s really required is to run “Update-Database” from the Package Manager console. In this sense, it’s not terribly different from working with any other network instance of SQL Server.

I was pleased that all of my migrations, mostly, ran without issue. I did have a few migrations that referenced other databases that exist on the same server for importing data, but I commented those out for this test.

Azure SQL provides some nice browser-based design/querying tools. They do require Silverlight, so I was forced (gah!) to utilize IE to access them. Overall, it’s a similar experience to using SSMS. I can view all of the migrated tables, history, and perform simple queries without little effort.

Alluding to my post from yesterday, now it was time to deploy my Entity Framework-based Web App. This was a painless process, but I did run into a few random issues that were configuration related.

First, I got this error:

Server Error in ‘/’ Application.

A route named ‘HelpPage_Default’ is already in the route collection. Route names must be unique.

That seemed pretty odd as I know that I had I only had this route defined once. I chalked this up to having deployed a previous application, and forcing a clean of the publish directory (in the publish settings fixed this issue):

The next problem I ran into was another server error:

Server Error in ‘/’ Application.

Could not load file or assembly ‘System.Web.Http.WebHost, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

This one left me scratching my head at why it would occur. To fix, I reinstalled the nuget packages and added a web.config binding redirect for WebHost:

Update-Package Microsoft.AspNet.WebApi -reinstall


  <assemblyIdentity name="System.Web.Http.WebHost" publicKeyToken="31bf3856ad364e35" culture="neutral" />
  <bindingRedirect oldVersion="" newVersion="" />

Finally, with those pieces in place, I could now run and play around with my EF based application. It’s a CRUD management app, so I created some dummy entries in the Admin seciton. Keep in mind that I did fake out the login and such for testing purposes.

Once I added a bit of data, I could easily go back to the Azure DB management portal and query that data.

It was nice to see, generally, how straight-forward it is to retrofit an existing ASP.NET application to work as an Azure Web App and to take advantage of Azure SQL. I plan to continue playing around with the Azure (free MSDN) services and potentially use it for hosting demo projects for both internal and external projects. Having this venue available eliminates a lot of hassle that usually comes about when trying to demo WIP to colleagues and others.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.