Is "Autoparameterizationwebconfigconnectionstrings"-Option the Only Way to Prevent Connection String Tokenization?
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...
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.
3 Answers
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>
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
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.
Chloe Bennett explores the intersection of pop culture, streaming entertainment, digital trends, and contemporary lifestyle. Her weekly commentary reaches thousands of culture enthusiasts.
