Impossible to properly escape paths from Visual Studio variables - by Vlad Didenko

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 810491 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 12/2/2013 11:12:55 AM
Access Restriction Public


The problem is related to escaping paths in Pre-Build, Pre-Link, and Post-Build events. Both batch processor and powershell behave as expected when invoked from a build event command line. That is, before passing parameters to powershell, batch shell processes escape sequences. That is expected and it is usually scripter's responsibility to do proper multiple escaping.

The problem I see lies with VS2012 as it is impossible to properly escape escape sequences when content comes via variables - given the way VS2012 invokes the commands. Apparently it calls a batch shell equivalent.

What is normally done to avoid this impossibility, is either to use an exec-equivalent call which does not perform any expansion or feed input into a command interpreter as a stdin or a filename to execute, again, without expansion. VS2012 does one extra step of passing build steps through a shell - and that hurts. I am not sure what is Microsoft's rationale behind it.

So, to mitigate the problem one thing Microsoft could do is allow a user to specify an interpreter name and then an array of args - which won't be escaped. Otherwise, allow a user to specify an interpreter and feed it the script at the stdin.

By the way, when I clicked on the "Search related threads" link at the top of this post, there is clearly much pain other users having with this issue. Which greatly limits the use of build events - and somewhat reduces the build tool usability overall.

The rest of the detailed description of the problem is here:
Sign in to post a comment.
Posted by Vlad Didenko on 12/3/2013 at 8:09 PM
Dear Microsoft. Please, note the four points below.

1. There is a real issue and it is not between the keyboard and a chair on my end. Please, please, please study the referenced materials before answering.

2. Putting quotes around parameters does not solve the issue - and you would have know it if you tried the "replicate" procedure. In any case, quoting parameters produces the following:

1>------ Build started: Project: tools, Configuration: Debug x64 ------
1> Arg A: C:\Users\Vlad Didenko\src\ buildeventtest" C:\Users\Vlad
1> Arg B: Didenko\src\ buildeventtest"

Note that parameter separation is messed up, as well as ending backslashes missing.

3. I am aware of the suggested workaround - and do temporarily use it in current production setup since September.

4. I need to solve a general case of this problem - which is to reliably know that I can pass any variable from VC++ to a build event hook and not worry about its content. Lack of this warranty makes development complexity (or even possibility) for build hooks unpredictable and from now on I can not take up those issues for coding. At the very least I need to know what character sequences do break parameter passing from VC++ to an event hook.

May be it can help you for prioritization to know that many people struggle with this issue as evidenced by the related search referenced in my November 25 comment at the forum post. This issue wastes tons of cumulative developer time and does make Visual Studio an unpleasant product to struggle with. It also happens to be exactly the point where Unix-oriented products are so much simpler to interface with. Finally, it does not seem to be a hard one to fix - so in my ming it qualifies for a low hanging fruit priority.

Thank you, appreciate your involvement.
Posted by Microsoft on 12/3/2013 at 2:02 PM
These macros are expanded directly into the command line. To avoid issues with spaces in paths please put quotation marks around the macros.

powershell.exe -ExecutionPolicy RemoteSigned -file "$(SolutionDir)paramtest.ps1" "$(SolutionDir)" "$(ProjectDir)"
Posted by Vlad Didenko on 12/3/2013 at 7:10 AM
The workaround #1 addresses not a generic case of passing data from variables to build hooks, but a specific use case, which is known and documented at the original use case here:

In order to have content from variables usefully feed flexible build hooks either hook interface needs to be coded properly (do not escape parameters) or enumerate affecting escape sequences and problematic use cases and show that problematic use cases each have workaround.
Posted by Microsoft on 12/2/2013 at 10:59 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 12/2/2013 at 11:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(