title: How to create EF migrations with ConnectionStrings on Azure's ConfigurationManager.ConnectionStrings?
body: <p>We recently moved from a local server for <code>dev</code> and a private server on the cloud for <code>prod</code> to Azure, where we have different slots (<code>dev</code>/<code>staging</code>/<code>prod</code>) and to SQL Azure as well.</p>
  <p>Everything is running fine until I needed to create a new migration. We are using a Code First EF6 so, in order to create a migration I type on the console package administrator window the <code>add-migration Whatever099BriefDescription</code> command.</p>
  <p>I instantly got a <code>NullReferenceException</code> referring to the connection string. We've got a <code>ConnectionStringFactory</code> class where we used to have an <code>#if DEBUG#</code> returning the correct connection string grabbed from the <code>Web.Config</code>.</p>
  <pre><code>public static class ConnectionStringFactory
  {
      public static string GetConnectionString()
      {
          //USED JUST FOR CREATING MIGRATIONS
          //#if DEBUG
          //            return @&quot;Data Source = SQLSERVER\LANSERVER; Initial Catalog = Project; user id = Project; password = asdf; MultipleActiveResultSets = true&quot;;
          //#endif
  
          var connectionString = System.Configuration.ConfigurationManager.ConnectionStrings[&quot;Project&quot;].ConnectionString;
          return connectionString;
      }
  }
  </code></pre>
  <p>Since we're actually using the Azure's configuration connection strings (on Azure Portal panel) our <code>web.config</code> has no connection strings defined. So of course that <code>NullReferenceException</code> makes complete sense, because it's trying to get that string from a place where it can't get grabbed.</p>
  <p>I could finally create the migration using again the <code>#if DEBUG#</code> annotation, providing the hardcoded connectionstring and of course deleting it afterwards.</p>
  <p>This seems like an &quot;odd&quot; behaviour or at least not the optimal. Could you please share any advice on how could I create EF migrations without the needance of hardcoding temporarily the connectionstring so it could be &quot;somehow&quot; achieved to get it from Azure?</p>