33

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 stored against a token in SetParameters.xml then applied on publish.

For example, take a Web.config with the following connection string and app setting:

<connectionStrings>
  <add name="AutoDeployDb" connectionString="Data Source=(local);Initial Catalog=AutoDeploy;User ID=AutoDeployUser;Password=Passw0rd"/>
</connectionStrings>
<appSettings>
  <add key="ChartImageHandler" value="storage=file;timeout=20;dir=c:\TempImageFiles\;" />
</appSettings>

Then here's the corresponding config transform for the current build configuration:

<connectionStrings>
  <add xdt:Transform="Replace" xdt:Locator="Match(name)" name="AutoDeployDb" connectionString="Data Source=MyDevServer;Initial Catalog=AutoDeploy;User ID=AutoDeployUser;Password=s*#@Kdsl" />
</connectionStrings>
<appSettings>
  <add xdt:Transform="Replace" xdt:Locator="Match(key)" key="ChartImageHandler" value="storage=file;timeout=20;dir=d:\inetpub\AutoDeploy\TempImageFiles\"/>
</appSettings>

These are both "Replace" transforms and other than one being a connection string matching on "name" and the other being an app settings matching on "key", to my eye they're identical.

Now look inside the SetParameters.xml file in the resultant package and only the connection string has a setParameter node. In the Web.config of the PackagTmp folder, the app setting transform has already been applied while the connection string has a "$(ReplacableToken_AutoDeployDb-Web.config Connection String_0)" value which is applied only when the package is deployed.

Why is this? Is it something specific to connection strings (or conversely, to app settings)? I appreciate the rationale of this approach, I'm just not clear on why it's applied to some settings and not others.

Can anyone shed some light on this?

Sayed Ibrahim Hashimi
  • 43,864
  • 17
  • 144
  • 178
Troy Hunt
  • 20,345
  • 13
  • 96
  • 151

2 Answers2

37

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.

Sayed Ibrahim Hashimi
  • 43,864
  • 17
  • 144
  • 178
  • 3
    It would be incredibly useful if there was an easy way (via an MSBuild property) to treat appSettings (either specific ones or the whole set) in this way as well. e.g. AutoParameterizationAppSettings = true. – James Webster May 25 '11 at 23:23
  • 5
    This article is quite good in defining a way to solve my problem: http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html – James Webster May 25 '11 at 23:37
  • 1
    But why would anyone want this? – Code Silverback Mar 26 '12 at 14:00
1

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.

David Hu
  • 49
  • 1