MSBuild in Visual Studio Part 4: A Quiz on Project Escaping

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 ]

Comments (2)
  1. Keith Hill says:

    My guess without trying this would be that only the last one needs to escape the "$" char in order to not replace $(configuration) with the value of the Configuration property. You mention semi-colon but I thought that had special meaning just in item lists and not in properties?

  2. Mike Fourie says:


    Thanks for taking a guess. I must admit I failed miserably on this quiz.

    Semi-colons are special in property groups too. You can see this with the "DisabledWarnings" property above, which gets passed into a task and the task expects to be able to treat it as a list of items. Another way to look at it is if you have a property in a task defined as ITaskItem[], you want to be able to accept both properties and items as an input, and still see them as individual array elements.

    I won’t spill the beans on answers yet though… On Monday next week the first set of answers will go up (the answers were so long we broke them up across two posts). Check back then!


Comments are closed.

Skip to main content