We have multiple teams of developers in different offices, and they need different values for a number of configuration setting in our projects\' web.config
and
Did you consider a content filter driver?
That would mean, on each git checkout
, the smudge script would generate the actual config file based on:
@@A_PARAM_VALUE@@
)That avoid any merge issue and gitignore settings: each "config value files" are different and remain separate.
This is also compatible with other config generation solution like ConfigGen mentioned in pms1969's answer.
I'd like to suggest you look at ConfigGen. We use it in all our projects, and it works wonders for all the developers and also for all our environments. It basically runs off a spreadsheet that states machine name and output configuration file, and then tokenises a template App.Config or Web.Config, substituting values from the spreadsheet into it. Add a simple pre-build step to your projects to run configgen, and before the build kicks off, you have a tailored configuration file for your machine. It also supports default settings.
Take a look at the site and make your own mind up, but I can definitely vouch for it.
EDIT: It's worth noting that you can then ignore all your Web.config and App.config files (in terms of .git). But you do need to add your templates and spreadsheets to the repo. Also, I am assured there is an update on the way that may well include an xml replacement for the spreadsheets, that has it's own editor, making it eminently more suitable for DVCS's.
Edit2: Also take a look at Daniel's post here: https://stackoverflow.com/a/8082937/186184. He gives a very clear example of the template and spreadsheet, and how to get it working in your solution.
A bit has changed since 2012 and these days and now I would suggest your build/deploy tool (VS Team Services, TeamCity, Octopus Deploy) managing environment specific configurations.
If you work in azure you can define app settings and connection strings as part of your app definition.
We ran into a similar dilemma at our company. We ended up creating separate configuration branches which supplement the main branch. Like for example - develop-config, master-config, etc. We then have a small script which will rebase those branches with the correct source branch based on the deployment environment. So for example on the development machine we would rebase develop-config with develop. If you are working on local machine, you would get the default configuration (agreed upon by all developers) which is checked into the main branch (like the local DB name, password, etc). Of course the downside is that you always have to keep those *-config branches up-to-date or get them upto speed at the time of deployment.
Since implementing this workflow, I've come across couple of deployment tools out there like whiskey_disk which take a somewhat similar approach. In fact I like their solution a lot more since its much more secure and flexible. Although probably not a good fit for you guys since its geared more towards a LAMP/RoR development stack.
Aside from that, there are also some commercial solutions out there that you might want to take a look at like Beanstalk
I would take a look at this answer for Managing complex Web.Config files between deployment environments by Dan for a potential solution. I use mercurial and use this same process to have a generic web.config file checked in and use the web transforms to change the location of configSource
to point to my deployment specific stuff.
The advantage of using this route is it is completely built in to the framework, requires no extra code, and works with web deployment.
Checked in web.config:
<?xml version="1.0"?>
<configuration>
<!-- snip -->
<connectionStrings configSource="config/connectionStrings.config" />
</configuration>
Checked in web.debug.config:
<?xml version="1.0"?>
<configuration>
<connectionStrings
configSource="config/dev.connectionStrings.config"
xdt:Transform="Replace(configSource)" />
</configuration>
I have a config/connectionStrings.config
checked in with defaults, but the development servers config/dev.connectionStrings.config
is not checked in and its not replaced on a new deployment.