Applying Entity Framework’s Code-First Migrations against a Database in Azure by running Update-Database

This post describes how to run Entity Framework’s code-first migrations against a database located in the Windows Azure. This is done by running Update-Database commandlet with suitable switches, see below.

The problem and symptoms

Okay, so you’re developing your MVC+EF cool web app with a database in Azure, and you’re using code-first migrations. Cool! What’s nice with code-first-migrations is the fact they are run automatically even in the cloud the next time your app is running (as long as you publish your app with that little box ticked – something like in the screen capture below). But wait – what if there are conflicts – what kind of errors are you going to get?


Azure Web Publish
Azure Web Publish

Not very useful ones, I’m afraid, and it’s a pain navigating the Azure portal to fetch the log files. At some point – for me, it wasn’t the first time I ran the web app, but the phase when I was logging in – you’ll be getting the error the migrator internally throws. That might be enough to point you to the right direction, and maybe you’ll be able to figure out what’s wrong! But if that’s not the case, here’s the way to run Update-Database against your Azure Database!

Solution: Update-Database to the rescue!

Alright – you’ll actually just need to specify the ConnectionString for the command. If you have a wood league -level memory, just like me, you’ll have forgotten about the ConnectionString syntax already, so I’ll just write it down here for future reference. The whole script will be something like this:

Update-Database -ConnectionString "Data Source=****;Initial Catalog=****;Integrated Security=False;User ID=****;Password=****;Connect Timeout=60;Encrypt=False;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False" -ConnectionProviderName "System.Data.SqlClient" -force -verbose

But wait – what if you don’t have your Azure Connection String at hand? No worries, that’s easy to get. With any luck, you’ll already have it saved in your Publish -dialog (see screenshot above). If you don’t, fear not – you can still get the string from SQL Server Explorer, where you’ll have to select your database and click properties. You’ll find the connection string in your Visual Studio’s properties -window.

SQL Server Properties
SQL Server Properties

Oh but well – the problems probably don’t end there. What if you get an error like “Cannot open server – – requested by the login. Client with IP address – – is not allowed to access the server” while you try the deployment? No worries – I’ve described the solution to that error here. Check it out!

With all that, you should be all set – or at least you’ll be getting more useful error messages… 🙂

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. This is his personal professional (e.g. professional, but definitely personal) blog.

Let me know your thoughts!