Best practice with .gitignore for connection strings inside App.config or Web.config

Question

I've tried several approaches with *.gitignore for managing connection strings when working on a larger team.

From the official repository of .gitignore files at gitignore, I've downloaded VisualStudio.gitignore and used it as a starting point for all the projects.

The same process can be done by visiting http://gitignore.io/, typing VisualStudio, then downloading the file.

The approach I currently use is by leveraging the SectionInformation.ConfigSource Property

<connectionStrings configSource="myConnectionStrings.config" /> 

and then adding myConnectionStrings.config to .gitignore, which is nice because it doesn't add the entire *.config.

Also you can use the same myConnectionStrings.config inside another project (your MyProject.Data layer)

<configuration>   <connectionStrings configSource="myConnectionStrings.config"/> </configuration> 

Just remember to set Copy always!

Also I've tried using filters as described at Git - Ignoring a specific modification to a config file, but I find that to be an overkill.

I wonder if there is any other approach that is considered a best practice?

Answer 1

I can't speak for your setup, but this is how I have tackled this problem.

Firstly, all the guys in my team use local databases with Integrated Security set as true. This means that when we check out the files from source control, it is good to go with a local setup. So my Web config file looks like this

<add name="appConnString"    connectionString="Data Source=(local);Initial Catalog=MyDatabaseName;Integrated Security=True;"    providerName="System.Data.SqlClient" /> 

Regarding going deploying to different environments, the first option you have is to use transforms. If you don't know what that is, read here

Since we use Octopus Deploy as our deployment tool, our transform file has the connection string for "web.release.config" like this

<add name="appConnString"    connectionString="{{appConnString}}"    xdt:Transform="Update"     xdt:Locator="Match(name)" /> 

When Octopus runs it's course, it grabs the web.config and overwrites the relevant sections using the release file. Then depending on which environment/machine/branch I am deploying to, it replaces the {{appConnString}} with the configuration that has been set up for that deployment.

I'm sure Visual Studio has pretty much the same process.

If you don't like the Transforms process. You can also use a parameters.xml file. msdepoy uses this file to replace values in your web.config at build. You can read up more about it here.

Another consideration is if you are hosting with Azure, you can set up certain configuration replacements on your various deployment slots all the way to production.

These are just a few techniques I have used and seen being used very effectively. Some take a bit getting used to and also a lot of frustration setting up, but having a proper deployment system will pay in the long run.