Is "AutoParameterizationWebConfigConnectionStrings"-option the only way to prevent connection string tokenization?

Question

I am still trying to get my head around MSBuild things. Currently I am fiddling around with deploying via powershell script using the generated scripts from the PackageWeb-Nuget-Package (video demo). I have been trying that out for a few days now and it seemed to work. But "suddenly" the connection string in the generated web.config is tokenized and instead of the connection string in question I see

connectionString="$(ReplacableToken_DefaultConnection-Web.config Connection String_0)

I wrote "suddenly" because I could not link this (for me new) behaviour to anything I had done in the previous hours.

So to sum it up: The deployment from package is working fine, also the correct config transformation is being applied, but I end up with this tokenized connection string.

I realize that I can fix this if I insert

<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>

into a PropertyGroup (I just put it into the generated targets-file that the Nuget-Package creates)

However I really dislike this, having to insert this additional value into each project that might need it; especially because I did not know I need this adjustment in the first place. Yesterday it worked and I did not have this extra line inserted into any projects- or targets-file.

So I was hoping that maybe someone knows an extra switch, trick or setting that might have an additional influence on how that is working, too.

Gratify

This is old, but would you plz share your findings on how you did it without specifying this loooooog property in .*proj file? – Stockjobber

@Stockjobber To be honest, I did not "solve" that at any point - the property AutoParameterizationWebConfigConnectionStrings=false is still part of my deployment process; though I have not run into any problems with that, besides esthetically, I would also still be very interested if this can be circumvented in any way. – Gratify

@Stockjobber To add to that, the primary thing that I disliked about this was having to modify each project ('s proj-file) for that; however you do not have to do that, you can pass properties as parameters to msbuild - that way you override already existing properties in your proj-files or add new ones that you need (just like AutoParameterizationWebConfigConnectionStrings) hope this helps you ;) (example: https://mcmap.net/q/76666/-how-do-i-pass-a-property-to-msbuild-via-command-line-that-could-be-parsed-into-an-item-group) – Gratify

@Gratify I am trying to use AutoParameterizationWebConfigConnectionStrings and DisableAllVSGeneratedMSDeployParameter for publishing Web Deploy Packages from Visual Studio 2013. Where exactly do you put these? In the csproj file? I've tried that and it gives an error. – Cask

@Cask I am actually calling msbuild directly and override properties with that cmd like this; you should however also be able to use those parameters in your project file directly. You need to watch out if those parameters are altered in a later stage, for example passed in command line will override (augment) properties known from the project file. – Gratify

@Gratify It didn't work when I put it directly in the project file, it would create an error on build. I put it in the publish settings file .pubxml that is created in Project Folder/Properties/PublishProfiles when you create a profile in the Publish->Web Deploy Package dialog. There wasn't an error after putting it there. – Cask

Answer 1

Microsoft is using auto parameterization by default. This includes het connectionstrings. You can disable this by adding this to the project file.

<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>

For disabling all transforms you can add this as described here.

<TransformWebConfigEnabled>false</TransformWebConfigEnabled>

For disable all the parameters for a deployment package: <DisableAllVSGeneratedMSDeployParameter>true</DisableAllVSGeneratedMSDeployParameter>

Benitabenites

Answer 2

Now that my company has been using TFS's "Release Manager" tool, which works off of a single build, we don't use web.config transforms anymore and instead use MS WebDeploy's parameters.xml method for swapping out values for different environments. However, I ran into the issue of the 'auto-gen'd' conn string mentioned above. Below is one work around for it.

If you're using parameters.xml files in your project, if you give your parameter the same name as the auto-gen'd one for your connection string, it works.

So below I have a 'DBConnectionNameHere' (what would be my example connectionStrings 'name' in the web.config) and then I just append "-Web.config Connection String" to the name. Now instead of the auto-gen'd conn string overriding my own in the parameters.xml file it will work and just add an extra and harmless 'parameterEntry' child tag.

For example:

<parameter name="DbConnectionNameHere-Web.config Connection String" defaultValue="#{TokenHereOrActualValue}#">

  <parameterEntry kind="XmlFile" scope="\\web.config$" 
match="/configuration/connectionStrings/add[@name='DbConnectionNameHere']/@connectionString" />

</parameter>

Hope that helps someone!

Chris

Czarina

Answer 3

I've noted that things like $(ReplacableToken_ seem to happen randomly when publishing and was able to fix the situation by doing a cleanup before rebuilding and republishing. However, since you cannot really know unless you always manually check the web.config after publishing, I've also added

<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>

to the web service project in question.

Killer