30

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.

enter image description here

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!

enter image description here

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?

Community
  • 1
  • 1
Matija Grcic
  • 12,963
  • 6
  • 62
  • 90
  • 5
    I worked at a company that did it exactly the way you describe. I think the configsource attribute was designed for this, so I think you're spot on with your implementation. – CarllDev Feb 20 '14 at 17:09
  • @CarllDev thanks for taking your time to post a feedback. – Matija Grcic Feb 22 '14 at 19:44
  • Just like @CarlDev said, you hit it spot on. :) That's the best way to do it. – Granville Schmidt Feb 23 '14 at 03:28
  • 2
    This link, [Keep Private Settings Out of Source Control](http://typecastexception.com/post/2014/04/06/ASPNET-MVC-Keep-Private-Settings-Out-of-Source-Control.aspx), really helped me also, mentions the method above, as well as some other options too. – BMB Sep 05 '15 at 22:09
  • @CarllDev downloading a file from the net and adding strings to that is not an "implementation" (I love coming back to this post, LOL). – Ярослав Рахматуллин May 25 '16 at 06:43
  • @Ярослав Рахматуллин I think that depends on ones definition of implementation. The dictionary states that it is 'the process of putting a decision or plan into effect'. The plan here was to set up connection strings in a separate file. It doesn't matter how it was done, as far as definitions go, the result is the implementation. – CarllDev Jun 02 '16 at 13:32
  • what is the purpose of "copy always" ? – ebram khalil Apr 29 '17 at 15:52
  • Dude what a great Ideia, I alredy saw that on a big project, but i never think this way even for me, and guys ) don't need help to create damage due envirment switching. By the way, you can also have the appSettings outside your configFile: Regards :) – NFRiaCowboy Aug 02 '17 at 10:35

2 Answers2

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.

Talon
  • 3,466
  • 3
  • 32
  • 47
-12

Perhaps a bit presumptuously, I hold that there is no need for a policy for adding shell globs to a file. I've never heard of "connectionStrings" before reading this question, but from what I could gather, they hold URIs / credentials for various backends.

How often does a backend change? Better yet, how often does the path of the configuration file change? Probably not often enough to warrant a policy. The only thing you need is a convention for naming the configuration files that contain these connectionStrings to easily identify them with automation tools.

So use your tools or write a script and append the foobarService.config from <connectionStrings configSource="foobarService.config" /> to the .gitignore file for all your backends.

1. Find the files.

$ find -name cs.xml

./more/configs/here/cs.xml
./cs.xml
./some/sub/folder/cs.xml

2. get config-file names

$ find -name cs.xml | xargs grep -ho '[^"]\+\.config'

getImagesService.config
users.config
ldap.config
foobar2k.config
ratpoison.config
moo.config
foo.config
trololol.config
moreconfigz.config
myConnectionStrings.config
data.config
base.config
filebackend.config
offsitewhatever.config

3. ignore them

$ find -name cs.xml | xargs grep -ho '[^"]\+\.config' >> .gitignore

4. update your CV

  • March 2014 - lead designer of a connectionString policy

I'm baffled that anyone would ask about advice on managing a .gitignore file. This could indicate that I don't see the big picture. Would you kindly update your question with some background information? I'm curious about why this is a meaningful question, as I'm having a hard time grasping that there is a need for establishing best practices to append a string to a file.

  • 2
    Better just decree that a file with credentials has always to be called, well `FileThatContainsSomeSecret.credentials` or such, and add `*.credentials` to your `.gitignore`. Problem solved forever. And I claim the exalted title of **Creator of The Ultimate Credentials Management Meta-Policy**. – vonbrand Mar 05 '14 at 18:13
  • 6
    I'm glad you have learned something by reading the question. I didn't ask how to manage .gitignore file but how to manage connectionsstrings and specifically in the case with VisualStudio. If you don't understand the question please don't be a troll with your sarcastic/irony answer. – Matija Grcic Mar 07 '14 at 11:24
  • @Ярослав Рахматуллин How often does the backend change? *Very often in some cases*. I have a named instance of database *.\mssql2014* , while my colleague has it as default *.* (dot). There are 30 fine men on the team. Now sometimes fine men make mistakes and commit their configs. And on friday evening someone spends 30 minutes trying to realise why some feature throws an SQLException – evictednoise Feb 29 '16 at 12:25
  • Add the configs to .gitignore. Still no policy needed. – Ярослав Рахматуллин Mar 03 '16 at 08:56
  • @Ярослав Рахматуллин Ok, added. Tommorow our team expands to 100 men. They pull the code, but .config isn't there. Aside from connection string there is a bunch more stuff. USB sticks to the rescue? – evictednoise Mar 15 '16 at 17:13
  • @ЯрославРахматуллин the other problem is that the developers might actually want to change the appSettings, SMTP, Oauth, WCF settings and a bunch of other stuff. That's why its a ".config" file. On the other hand, I create a new local DB for each branch I work on, so I have multiple connection strings for each project. You have to admit that you have not understood the entire situation. – Talon Sep 27 '17 at 09:26