When we last posted everything was looking pretty straightforward. At this point we know how the project system reads and writes properties from the project file. What we haven’t talked about is the mess involved in escaping property values. During the presentation when Rajeev started to talk about this, about half the team started to laugh (those that weren’t around for the original pain) and half started to cry (those that were around and had to fix all the bugs). At the end of this series of three posts on escaping I’ll be interested to know how many of you laughed, how many cried, and how many did both.
Since the project file is stored in XML, it’s pretty obvious that at some point we’ll have to escape something. Some characters like < have to be escaped because we store all the data in XML. Others, such as a semicolon, have special meaning in MSBuild lingo and could be misinterpreted if they aren’t taken care of. If that weren’t bad enough, MSBuild also supports variable replacement in its properties so things like $(USERNAME) may need special treatment as well. The $64,000 question is: “Which properties need escaping”?
Rajeev put us to the test in the meeting, and now it’s your turn. Here are six examples of properties that Visual Studio stores in the project file and can be edited by users through UI. Which ones get escaped when they are written back to the file?
OutputPath (e.g. c:\myproject\bin\debug)
AssemblyName (e.g. Microsoft.VisualStudio.CommonIDE)
WarningLevel (e.g. 2)
ReferencePath (e.g. c:\myreferencepath; c:\yourreferencepath)
DisabledWarnings (e.g. 645;1701;1702)
Pre-/Post-Build Event (e.g. echo Hello, my config is $(configuration))
If you’re daring you can try various values for these properties through the Visual Studio UI, and then look in the project to see what got persisted. If you’re not daring, take a guess and read our next entry in the series to see if you were right.
[ Author: Neil Enns ]