Manage connection strings in a controlled source application that is constantly deployed on Azure sites

Question

Here's the scenario: I have several developers in an asp.net mvc 4 project. Each developer has a local database. Source Management System - TFS at http://tfs.visualstudio.com . We use Azure sites to host the site. We also set up Azure websites for continuous deployment.

Version control system can be git, mercurial, TFS, etc. Honestly, I don’t think it matters.

My question is how to accomplish these three things:

• Each developer has his own connection string locally (without source control)
• Azure has its own connection string (without source control)
• Source Control does not show connection information
• The ability for each F5 developer to run / debug / test the application locally.

We performed # 1 by adding separate connection strings to our machine.config so that there was no conflict between the settings of the developer's workstation.

I initially deleted the connectionstrings section from web.config. On the Azure website (using the management portal in the "Configuration" section), I configured the connection strings, and after watching the video of Scott Hanselman, it was found that they would be dynamically merged into my web.config during deployment, but this does not seem to happen. Whenever I go to any page that falls into db, I get an error message, I cannot find the connection string (or some other db error related to the connection)

If I put the Azure connection string directly in web.config, Things work on Azure, but then these connections are in source control, visible to everyone.

After reading a few more posts from Scott and David Ebbo, it seems like I can put an empty connection string in web.config (with the correct name) and then Azure will return the correct values. Then I would need the developers to put their connection strings in their web.debug.config file, and then install the Slow Cheetah plugin so that they can F5 and test locally. They also did not need to check the web.debug.config file in the source control. (Not so easy with TFS). This is like a serious gap that cannot fail somewhere along the line.

I have to believe that this is not a rare problem. How do other teams do this?

Answer 1

Looking back, it seems that what I requested is not actually supported without a bunch of hackers on the command line before / after assembly. What we have finished forces developers to create their own local databases, use trusted authentication, and set the SQL alias that was used by all developers in web.config. Thus, it works locally for everyone, it does not provide any usernames / passwords in the original control, and Azure can still overwrite it when it is automatically pulled out of the control source.

Answer 2

Slow Hepatitis is a really good solution. This is a web.config conversion extension. These conversions allow you to save one web.config file, and then for each deployment scenario you specify what changes you need. For example, your version of Release is likely to remove the debug attribute.

It can also be used to change connection strings. Transforms are applied during the deployment of your project in Azure.

What I did in the past so that it also works with local development machines is to use web.config with an external connection.config file . Each developer created a connection.machinename.config file, which was copied to the connection.config file for assembly in the post-build phase. These files do not need to be checked, and they can never cause conflicts, because each machine name is unique.

Release / stage / .. configurations use the web.config transformation to replace the connection string element with a specific connection string for this deployment (and thus remove the dependency on the external configuration file).

Slow Cheetah offers some nice helpers to check the result of these transformations during development.