A little background first: where I work we maintain about 40 .NET applications of varying size. These apps share many secrets (account credentials, connection strings, etc.) in configuration files. We encrypt all of our configuration files during build. However, our approach still has disadvantages:

  • Whenever a credential changes (such as a password change), we have to update it in 40+ locations.
  • Developers have access to all credentials.

What I'd like to do is have some sort of system similar to how Azure allows you to specify app settings and connection string replacements during build/deployment:

Azure replacement configuration

We aren't using Azure (this is an internal, intranet environment) but we do have TFS running all of our builds. I'm looking for recommendations about how I can centralize and secure credential management (ideally locked down to just our security folks) and tie our build system into this new system so that configuration is handled all via the build.

One additional question I have is how this approach would affect local development and debugging - currently, when we are developing locally, we typically are using "development" assets (a development database). If I end up removing this configuration information from the local environment, how will our developers still be able to run apps locally (i.e., will I need to start providing a local configuration that creates local assets, such as a SQL server database).

1 Answer 1


The way Team Foundation Server handles this is through the Release Management tooling. So each deployment to each environment has different variables. This can be updated in a single place and you can have central replacements used in many application.

For build you replace your dev condign data with tokens that RM then replaces per environment as part of the deployment. Developers ben not have access to the values.

  • Thanks for pointing me at this - I will be investigating it further to see if it meets our needs. Commented Jul 15, 2015 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.