3

I spent the last few hours looking for the best solution to a growing issue:

  • We have more and more websites (in VS 2010) and therefore, more and more web.config files to manage. There are quite a lot of differences between the dev and prod environments (connection strings, tracing/emailing config, etc.).
  • Also, depending on the team someone is working (ex: web design team), he cannot have access to some passwords and encryption keys (located in the web.config file).

Currently we have:

  • A web.config file containing the prod values (connections strings, passwords).
  • A web.config.dev file containing the dev values.
  • A web.config.restricted file that contains the minimum required values to allow the web designers to do their job.

Therefore:

  • Every time a dev wants to add a new line the web.config file, he also needs to insert that line into the web.config.dev file (and eventually the web.config.restricted file).
  • After check in:
    • all the members of the dev team have to copy all the content from the web.config.dev file and override their web.config file.
    • all the members of the web design team have to copy all the content from the web.config.restricted file and override their web.config file.
  • These manual operations provoke lots of errors (people forgets to reflect the changes in all the files).
  • TFS must be configured to not give an access to the web.config file to the web design team (they have to create the file manually).

I'm looking at the less hacky way to:

  • Manage multiple environments (dev/prod) without having to duplicate all the web.config file content.
  • Manage TFS rights in order to hide some sensitive values to certain teams.

Note that:

  • I'm using websites projects (not web applications) so I cannot use web.config transforms.
  • It seems like Web Deployment Projects won't be available anymore in VS 2012 so I'd rather avoid to start using it now.
  • Publishing Profiles might be a good solution but we're still using VS 2010.

I'm convinced not being the first to have this issue. I'd be curious to know how people dealt with that :)

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Pedro
  • 3,511
  • 2
  • 26
  • 31

1 Answers1

3

For each version of the .NET Framework installed on a machine, you get a machine level web.config and machine.config files. You can put all your environment specific values, such as connection strings, in these files for each framework version you plan on using.

For example, in your dev machine, put your connection strings or appSettings values in C:\Windows\Microsoft.NET\Framework64\v4.0.3031\CONFIG\machine.config (or your exact version), and do the same for the different values in production. Config files inherit, so you won't need to do anything different in your code.

This however, will require each developer to setup appropriate machine level config files. This would probably point to your dev environment, or even local paths on the developer's machine.

wsanville
  • 37,158
  • 8
  • 76
  • 101
  • 1
    I didn't know the existence of these files. It could be used to define some steady values like the connection strings. Thanks for the tip! – Pedro Jan 11 '13 at 20:31