How do you handle dev/test/prod connection strings when doing an App. Diagram?

This was a question from one of a Microsoft Regional Director. The answer, ala Bill Gibson:

Database connection strings will most likely be replaced during deployment as they include information that is related to the actual location of a database. Production databases are not usually accessed during development and vice versa. Some parts of the connection string might be used in production with the values defined on the AD, or overridden when configuring a system on the SD, but potentially all of the connection string could be replaced on deployment. Think about a web service URL on a consumer endpoint. It might be set in development and kept that way, or it might be overridden in the SD or it might be replaced during deployment. We are currently best set up for the latter - connections on the SD are all about instructing a deployment engine on how to propagate URL values between services and their consumers. The same is true for databases except of course we have no real story for the database location, so my position would be that we expect the connection string to be replaced on deployment. With respect to secure settings on database connections, I thought the conclusion was.

In development it was thought less likely they will be used but if they are used, that the values will either be replaced on deployment (i.e. the passwords used for a test database will not be those used for a production database) and if not, then, rather than risk compromising those value, they will need to be reentered on deployment. But as stated above, I think we might expect database connection strings to be replaced in their entirety on deployment.

Comments

• Anonymous
  May 24, 2005
  We use connection strings in a configuration section handler much like .NET 2.0's connection strings. Ours allow for encrypted connection strings to be stored in web.config. We apply a "file" attribute to our connectionStrings element that allows us to override the connection strings. We merge the two config files and allow the "file" attribute's configs to take presidence. Additionally, if a file is specified, but not found, it "eats" the error. I should also note that the overridable behaviour is only available in standard builds. Obviously, for security reasons, this isn't desirable in production because someone could drop a file with their connection strings in it and play man in the middle. Then they could delete the file without ever touching web.config. As such, when we compile for deployment, the file override functionality is not included. This is a bit of paranoia because it requires physical access, but none-the-less, I like the additional layer of security.
• Anonymous
  May 25, 2005
  Visual Studio Team System
  
  Yesterday marked the one-year anniversary of the public announcement of...