MSBuild in Visual Studio Part 6: Quiz Answers, Round 2
If you’re joining us mid-stream, these are answers to a quiz on property escaping when saving properties back to the project file. Let’s pick up right where we left off in our last post.
DisabledWarnings: Not escaped
This is a great example of why we default to not escaping when we have the choice.
Since the warnings are always listed as numbers you might think it doesn’t matter a heck of a lot whether we escape the strings. The catch is that the minute we escape the semi-colons you can no longer pass the list as individual entries to a task, and it makes batching impossible. (A variant of this issue was raised by a customer in our forums regarding the AvailablePlatforms property).
Pre-/Post-Build Event: Yuck
This is really, really messy. When Rajeev presented this it made everyone in the room hold their head in pain. We have no way of knowing what the user wanted when they type in something like: echo $(Configuration). Did they want MSBuild to do variable replacement? Should this get passed as-is to the console? We wound up not escaping to get compatibility with the behaviour in Everett, and figured that would be perfect.
Then we got a bug from a customer.
One of our customers tried to do "echo %DEBUGGER_SETTINGS%" in the pre-build task. Since we didn’t escape, MSBuild converted the %DE to a character, as % is a special character in MSBuild used for HTML encoding. We wound up having to special-case the pre- and post-build event. Now we escape the % sign, and nothing else. See? I told you it was yucky!
Summary
Phew, so there you have it. To summarize the last two posts in a couple of simple rules:
- Don’t escape unless you really have to
- Escape where the user expects the entered text to get used exactly as entered
- Pre-/Post-Build events are icky
[ Author: Neil Enns ]