Why are some Web.config transforms tokenised into SetParameters.xml and others are not?

Question

I\'ve been using config transforms in VS2010 quite a bit lately but am confused as to why some transforms are applied directly to the Web.config in the package but others are st

Answer 1

This actually has nothing to do with config transforms. I just posted a very detailed blog at http://sedodream.com/2010/11/11/ASPNETWebApplicationPublishPackageTokenizingParameters.aspx. But some info here for you.

In the Web Publishing Pipeline (WPP) we handle connection strings as special artifacts. We will automatically create parameters for you for all connection strings. This is because in many cases when you deploy your app you want to change the connection strings. We do not automatically create parameters for any appSettting value. Now back to your question why do we tokenize the connection strings? We are really doing this to make sure that you do not miss setting the value and then accidentally have your application updating the wrong DB. We do help you by creating those parameters for you. Also you can disable this behavior if you want. You can set the MSBuild property AutoParameterizationWebConfigConnectionStrings to false.

Answer 2

Regarding deployment, there's one significant difference between them. When you import web packages to IIS:

• Connection strings will automatically be included in the wizard dialog for further parameterization.
• App settings will not be there by default. If you really want to do that, please follow the steps in "Custom Parameterization - Application settings in the web.config file" section of Configuring Parameters for Web Package Deployment

The differentiation creates a responsibility boundary between dev and ops. On one hand, you put parameters of target environment (database, cache, AWS key/secret, etc.) in connection strings that ops needs to take care of. On the other hand, you put irrelevant options in app settings section so ops's burden over specific products and business logic can be relieved.

In my company, one ops guy is often responsible for multiple products. You really can't require them to know as much product knowledge as you do. The less thing they need to pay attention, the happier the life will be.