One of the coolest things about Windows Azure Websites is the integration with source control, and the automated deployment hooks Azure offers. However, there are a number of small gotcha’s related to deployment, chief among these is the protection of confidential configuration items such as database connection strings. One of these gotchas is for connection string for entity framework, for which there is no native provider in Azure web app settings.

When you use Entity Framework to either build a database based upon the model you create in the VS Entity Designer, or use Entity framework to reverse-engineer a conceptual model from an existing database, it creates a bunch of meta-data mappings used to manage the interaction of your application with the database.

Unlike the “Code-First” approach, in which much of the meta-data exists as annotations on your model classes which Entity Framework then uses to create and map the relations of your classes to the database, the Model-First paradigm leaves you with straight POCO (“Plain Old CLR Objects” or, alternately, “Plain Old Class Objects”) classes.

In order for Entity Framework (and thus, your application) to work properly in a Model-First approach, it needs to know where all this meta-data lives, and this is evident in the connection string created by Entity Framework in your Web.config file. It should look like below:

In the above, the first XML node in , named “DefaultConnection” is the connection string for the standard Forms Membership feature included out of the box with the default MVC project template.

The second node, for the connection string named “ExampleDbEntities” is what you get when you create an Entity Framework Model First implementation of the actual domain database your application will consume. All that metadata=res: stuff essentially tells Entity Framework where to find the meta data it needs to properly relate your generated model classes to database tables, and to keep track of the relationships between them.

In Azure Web App application settings, there are 4 values required for connecting string:

1. Name
2. Value
3. Provider Type
4. Slot Setting (Optional)

We need to provide these settings as below:

1. Name – Name of the connection string (for example, this would be ‘ExampleDbEntities’ in our case)
2. Value – All the information related to connection string. This should be in the format as below:

   metadata=res://*/Models.ExampleEntities.csdl
   |res://*/Models.ExampleEntities.ssdl|res://*/Models.ExampleEntities.msl;
   provider=System.Data.SqlClient;
   provider connection string="data source=XIVMAIN\XIVSQL;
   initial catalog=ExampleDb;integrated security=True;
   MultipleActiveResultSets=True;App=EntityFramework"

   Make sure to remove any special characters like ‘&quot’ from string. Do note that we can choose to replace ‘&quot’ with double quotes or single quote.

3. Provider type – Choose ‘Custom’ from list of drop down. It will not work for any other provider type.
4. Check box for slot setting, if you want to specify that the mentioned connection string is only for the current slot.

Now, save the settings in the portal. However, you can not remove the connecting string from web.config entirely. If you would remove the connection string from web.config, you would get error like this:

The connection string ‘ExampleDbEntities’ in the application’s configuration file does not contain the required providerName attribute.”

So, you still need to keep the connection string in the web.config. However, just replace the actual connection string with dummy keyword. So it will look like this inside web.config:

Azure will inject correct value at runtime. So we need not worry about that.