Powershell call msbuild with nested quotation marks_问答_开发者

Using Powershell and Psake to create package and deployment for a visual studio solution. Trying to deploy a database project using msbuild - which is working correctly using msdos visual studio command line

   msbuild /target:Deploy /p:UseSandboxSettings=false /p:TargetConnectionString="aConnectionWithSpacesAndSemiColons" "aDatabaseProjectPathWithSpaces"

the same method call results in an error when called from powershell

& msbuild /target:Deploy /p:UseSandboxSettings=false /p:TargetConnectionString="aConnectionWithSpacesAndSemiColons" "aDatabaseProjectPathWithSpaces"

relating to spaces - can't figure out how to replicate this call in powershell - sample database connectionstring Data Source=.\SQL2008;Initial Catalog=Docume开发者_运维问答ntExecution;Integrated Security=True;

Short Version

How do you pass an argument containing quotes into a native command from PowerShell?

Use single quotes instead of double quotes in the argument string:
"/p:Target='Data Source=(local)\SQL;Integrated Security=True'"
→ /p:Target='Data Source=(local)\SQL;Integrated Security=True'
Use backslash-escaping for double quotes in the argument string^∗:
'/p:Target=\"Data Source=(local)\SQL;Integrated Security=True\"'
→ /p:Target="Data Source=(local)\SQL;Integrated Security=True"

If the embedded quotes are only being used to treat the argument as a single string, rather than being a required part of the parameter, then the following can be used:

Quote the entire argument string, instead of embedding quotes in the argument:
'/p:Target=Data Source=(local)\SQL;Integrated Security=True'
→ /p:Target=Data Source=(local)\SQL;Integrated Security=True
Escape all PowerShell special characters with backticks^∗ (this can only be done as an in-line argument):
/p:Target=`"Data Source=`(local`)\SQL`;Integrated Security=True`"
or /p:Target=Data` Source=`(local`)\SQL`;Integrated` Security=True
→ /p:Target=Data Source=(local)\SQL;Integrated Security=True

Full command line example (using the second alternative):

PS> [string[]]$arguments = @(
  '/target:Deploy',
  '/p:UseSandboxSettings=False',
  '/p:TargetDatabase=UpdatedTargetDatabase',
  '/p:TargetConnectionString=\"Data Source=(local)\SQL;Integrate Security=True\"',
  'C:\program files\MyProjectName.dbproj'
)
PS> ./echoargs $arguments

Arg 0 is </target:Deploy>
Arg 1 is </p:UseSandboxSettings=False>
Arg 2 is </p:TargetDatabase=UpdatedTargetDatabase>
Arg 3 is </p:TargetConnectionString="Data Source=(local)\SQL;Integrate Security=True">
Arg 4 is <C:\program files\MyProjectName.dbproj>

Long Version

Calling native commands is something that crops up quite a bit as folks move between the legacy cmd system and PowerShell (almost as much as the "separating parameters with commas" gotcha ;).

I've tried and sum up everything I know on the subject of command invocation in PowerShell (v2 and v3) here, along with all the examples and references I can muster.

1) Calling Native Commands Directly

1.1) At its simplest, for an executable located in the environment path, the command can be called directly, just as you would call a PowerShell cmdlet.

PS> Get-ItemProperty echoargs.exe -Name IsReadOnly
...
IsReadOnly   : True    

PS> attrib echoargs.exe
A    R       C:\Users\Emperor XLII\EchoArgs.exe

1.2) Outside of the environment path, for commands in a specific directory (including the current one), the full or relative path to the command can be used. The idea is to have the operator declare explicitly "I want to invoke this file", rather than let an arbitrary file that happened to have the same name get run in its place (see this question for more info on PowerShell security). Failing to use a path when it is required will result in a "term is not recognized" error.

PS> echoargs arg
The term 'echoargs' is not recognized as the name of a cmdlet, function, script file,
 or operable program...

PS> ./echoargs arg
Arg 0 is <arg>

PS> C:\Windows\system32\attrib.exe echoargs.exe
A    R       C:\Users\Emperor XLII\EchoArgs.exe

1.3) If a path contains special characters, the call operator or escape character can be used. For example, an executable starting with a number, or located in a directory containing a space.

PS> $env:Path
...;C:\tools\;...

PS> Copy-Item EchoArgs.exe C:\tools\5pecialCharacter.exe
PS> 5pecialCharacter.exe special character
Bad numeric constant: 5.

PS> & 5pecialCharacter.exe special character
Arg 0 is <special>
Arg 1 is <character>

PS> `5pecialCharacter.exe escaped` character
Arg 0 is <escaped character>


PS> C:\Users\Emperor XLII\EchoArgs.exe path with spaces
The term 'C:\Users\Emperor' is not recognized as the name of a cmdlet, function,
 script file, or operable program...

PS> & 'C:\Users\Emperor XLII\EchoArgs.exe' path with spaces
Arg 0 is <path>
Arg 1 is <with>
Arg 2 is <spaces>

PS> C:\Users\Emperor` XLII\EchoArgs.exe escaped` path with` spaces
Arg 0 is <escaped path>
Arg 1 is <with spaces>

2) Calling Native Commands Indirectly

2.1) When you are not typing out a command interactively, but instead have the path stored in a variable, the call operator can also be used to invoke the command named in a variable.

PS> $command = 'C:\Users\Emperor XLII\EchoArgs.exe'
PS> $command arg
Unexpected token 'arg' in expression or statement.

PS> & $command arg
Arg 0 is <arg>

2.2) The arguments passed to a command can also be stored in variables. Arguments in variables can be passed individually, or in an array. For variables containing spaces, PowerShell will automatically escape the spaces so that the native command sees it as a single argument. (Note that the call operator treats the first value as the command and the remaining values as arguments; the arguments should not be combined with the command variable.)

PS> $singleArg = 'single arg'
PS> $mushedCommand = "$command $singleArg"
PS> $mushedCommand
C:\Users\Emperor XLII\EchoArgs.exe single arg

PS> & $mushedCommand
The term 'C:\Users\Emperor XLII\EchoArgs.exe single arg' is not recognized as the
 name of a cmdlet, function, script file, or operable program...

PS> & $command $singleArg
Arg 0 is <single arg>

PS> $multipleArgs = 'multiple','args'
PS> & $command $multipleArgs
Arg 0 is <multiple>
Arg 1 is <args>

2.3) The array format is especially useful for building up a dynamic list of arguments for a native command. For each argument to be recognized as a distinct parameter, it is important that the arguments get stored in an array variable, and not just munged together in one string. (Note that the common abbreviation $args is an automatic variable in PowerShell, which can cause values saved in it to get overwritten; instead, it is better to use a descriptive name like $msbuildArgs to avoid the naming conflict.)

PS> $mungedArguments = 'initial argument'
PS> $mungedArguments += 'second argument'
PS> $mungedArguments += $(if( $someVariable ) { 'dynamic A' } else { 'dynamic B' })
PS> ./echoargs $mungedArguments
Arg 0 is <initial argumentsecond argumentdynamic B>

PS> $arrayArguments = @('initial argument')
PS> $arrayArguments += 'second argument'
PS> $arrayArguments += $(if( $someVariable ) { 'dynamic A' } else { 'dynamic B' })
PS> ./echoargs $arrayArguments
Arg 0 is <initial argument>
Arg 1 is <second argument>
Arg 2 is <dynamic B>

2.4) Also, for scripts, functions, cmdlets, and the like, PowerShell v2 can send named arguments contained in a hashtable using a technique called "splatting", without having to worry about parameter order. This does not work with native commands, which do not participate in the PowerShell object model and can only handle string values.

PS> $cmdletArgs = @{ Path = 'EchoArgs.exe'; Name = 'IsReadOnly' }
PS> $cmdlet = 'Get-ItemProperty'
PS> & $cmdlet $cmdletArgs     # hashtable object passed to cmdlet
Cannot find path 'C:\Users\Emperor XLII\System.Collections.Hashtable'...

PS> & $cmdlet @cmdletArgs     # hashtable values passed to cmdlet
...
IsReadOnly   : True

PS> ./echoargs @cmdletArgs
Arg 0 is <Name>
Arg 1 is <IsReadOnly>
Arg 2 is <Path>
Arg 3 is <EchoArgs.exe>

3) Calling Native Commands With Complicated Arguments

3.1) For simple arguments, the automatic escaping used for native commands is generally sufficient. However, for parenthesis, dollar signs, spaces, and such, characters used by PowerShell need to be escaped to be sent as-is to native commands, without having them interpreted by the parser. This can be done with the backtick escape character, `, or by putting the argument inside a single-quote string.

PS> ./echoargs money=$10.00
Arg 0 is <money=.00>

PS> ./echoargs money=`$10.00
Arg 0 is <money=$10.00>


PS> ./echoargs value=(spaces and parenthesis)
The term 'spaces' is not recognized as the name of a cmdlet, function, script file,
 or operable program...

PS> ./echoargs 'value=(spaces and parenthesis)'
Arg 0 is <value=(spaces and parenthesis)>

3.2) Unfortunately, this is not so simple when double quotes are involved. As part of argument processing for native commands, the PowerShell processor attempts to normalize all double quotes in an argument so that the contents of the argument, sans quotes, is passed as a single value to the native command. The native command parameter processing occurs as a separate step after parsing, so normal escaping will not work for double quotes; only escaped single quotes, or backslash-escaped double quotes can be used.

PS> ./echoargs value="double quotes"
Arg 0 is <value=double quotes>

PS> ./echoargs 'value="string double quotes"'
Arg 0 is <value=string>
Arg 1 is <double>
Arg 2 is <quotes>

PS> ./echoargs value=`"escaped double quotes`"
Arg 0 is <value=escaped double quotes>

PS> ./echoargs 'value=\"backslash escaped double quotes\"'
Arg 0 is <value="backslash escaped double quotes">


PS> ./echoargs value='single quotes'
Arg 0 is <value=single quotes>

PS> ./echoargs "value='string single quotes'"
Arg 0 is <value='string single quotes'>

PS> ./echoargs value=`'escaped` single` quotes`'
Arg 0 is <value='escaped single quotes'>

3.3) PowerShell v3 added a new stop-parsing symbol --% (see about_Parsing). When used before complicated arguments, --% will pass arguments as-is without any parsing or variable expansion, except for cmd-like %ENVIRONMENT_VARIABLE% values.

PS> ./echoargs User:"$env:UserName" "Hash"#555
Arg 0 is <User:Emperor XLII>
Arg 1 is <Hash>

PS> ./echoargs User: "$env:UserName" --% "Hash"#555
Arg 0 is <User:Emperor XLII>
Arg 1 is <Hash#555>

PS> ./echoargs --% User: "%USERNAME%" "Hash"#555
Arg 0 is <User:Emperor XLII>
Arg 1 is <Hash#555>

This can also be used to de-munge a single string representing multiple arguments, by passing the stop-parsing symbol in a string^∗ (although the best practice is to not munge arguments in the first place).

PS> $user = 'User:"%USERNAME%"'
PS> $hash = 'Hash#' + $hashNumber
PS> $mungedArguments = $user,$hash -join ' '
PS> ./echoargs $mungedArguments
Arg 0 is <User:%USERNAME% Hash#555>

PS> ./echoargs --% $mungedArguments
Arg 0 is <$mungedArguments>

PS> ./echoargs '--%' $mungedArguments
Arg 0 is <User:Emperor XLII>
Arg 1 is <Hash#555>

4) Debugging Native Commands

There are two key tools for debugging the arguments PowerShell passes to native commands.

4.1) The first is EchoArgs.exe, a console application from the PowerShell Community Extensions that simply writes back the arguments passed to it between angle brackets (as shown in the examples above).

4.2) The second is Trace-Command, a cmdlet that can show many details of how PowerShell processes a pipeline. In particular, the NativeCommandParameterBinder trace source will show what PowerShell receives and passes on to a native command.

PS> Trace-Command *NativeCommand* { ./echoargs value="double quotes" } -PSHost
DEBUG: NativeCommandParameterBinder : Raw argument string:  "value=double quotes"
DEBUG: NativeCommandParameterBinder : Argument 0: value=double quotes

PS> Trace-Command *NativeCommand* { ./echoargs 'value="double quotes"' } -PSHost
DEBUG: NativeCommandParameterBinder : Raw argument string:  "value="double quotes""
DEBUG: NativeCommandParameterBinder : Argument 0: value=double
DEBUG: NativeCommandParameterBinder : Argument 1: quotes

PS> Trace-Command *NativeCommand* { ./echoargs value=`"double quotes`" } -PSHost
DEBUG: NativeCommandParameterBinder : Raw argument string:  value="double quotes"
DEBUG: NativeCommandParameterBinder : Argument 0: value=double quotes

PS> Trace-Command *NativeCommand* { ./echoargs 'value=\"double quotes\"' } -PSHost
DEBUG: NativeCommandParameterBinder : Raw argument string:  "value=\"double quotes\""
DEBUG: NativeCommandParameterBinder : Argument 0: value="double quotes"

Other Resources

Articles

2012-01-02 - PowerShell V3 CTP2 Provides Better Argument Passing to EXEs
2011-03-10 - The problem with calling legacy/native apps from PowerShell
2010-11-04 - Escaping Spaces
2010-02-01 - The trials and tribulations of using MSDeploy with PowerShell
2008-10-17 - Executing commands which require quotes and variables is practically impossible [Connect]
2006-05-15 - Cannot enter an argument containing double quotes [Connect]

Questions

2013-09-11 - powershell executing external command not accepting parameter
2013-02-20 - Parameters with double quotes are not properly passed to Scriptblock by ArgumentList
2013-01-02 - ERROR: Description = Invalid query
2012-09-18 - How can I execute an external program with parameters in PowerShell?
2012-09-10 - Invoke executable (w/parameters) from powershell script
2012-08-16 - How do I pass a property value containing a semicolon on the MSBuild command line when running it from PowerShell?
2012-08-08 - Call ruby script from powershell
2012-08-01 - Brackets or quotation marks breaking a powershell command
2012-07-13 - Problems using powershell to perform a source safe get by label
2012-06-13 - Missing argument -m using svn at windows powershell
2012-06-01 - Powershell command line argument with spaces and curly brackets?
2012-04-18 - Spaced paths, msbuild, and psake
2012-04-12 - Make Power shell ignore semicolon
2012-03-08 - Simple Powershell Msbuild with parameter fails
2012-02-10 - Quote Madness in Powershell
2012-01-18 - Powershell: run msiexec with dynamically created parameters
2012-01-18 - PowerShell's call operator (&) syntax and double-quotes
2012-01-16 - PowerShell - passing calculated paths with spaces
2012-01-09 - powershell: script to start a program with parameters?
2011-12-20 - Powershell - calling icacls with parantheses included in parameters
2011-12-15 - Msbuild log doesn't work when executed through powershell
2011-12-06 - Pass parameters to InstallUtil from Powershell
2011-11-23 - Executing an exe with arguments using Powershell
2011-11-08 - Powershell remove quotes when start process
2011-09-16 - Commands executed in PowerShell with variables surrounded in quotes fail. Why?
2011-07-25 - Powershell parsing quotes strangely (includes a short analysis of quote parsing in one of the answers)
2011-07-15 - powershell stripping double quotes from command line arguments
2011-06-14 - In Powershell, how do you execute an arbitrary native command from a string?
2011-06-03 - Powershell call msbuild with nested quotation marks
2011-05-13 - powershell - passing parameters to exe
2011-03-02 - Why does this PowerShell script fail to execute this external command properly?
2011-01-09 - Executing an EXE file using powershell script
2010-12-13 - Command-line arguments to an exe
2010-10-08 - What is up with this PowerShell command line quoting/escaping?
2010-10-05 - Running an exe using powershell from a directory with spaces in it
2010-08-28 - Executing a Command stored in a Variable from Powershell
2010-08-17 - How do you call msdeploy from powershell when the parameters have spaces?
2010-04-12 - How to suppress quotes in Powershell commands to executables
2010-01-26 - powershell sending multiple parameter to a external command
2009-11-04 - How to run exe in powershell with parameters with spaces and quotes
2009-03-16 - PowerShell - Start-Process and Cmdline Switches
2009-01-14 - How to escape command line arguments on Powershell?

This could all be made a lot easier if you used the Start-Process cmdlet with the -ArgumentList parameter. I'm surprised that this hasn't been mentioned already.

Example:

Start-Process -FilePath msbuild.exe -ArgumentList '/target:Deploy /p:UseSandboxSettings=false /p:TargetConnectionString="aConnectionWithSpacesAndSemiColons" "aDatabaseProjectPathWithSpaces"';

Here's a method I like to use a bit better, which allows for variable substitution:

$ConnectionString = 'aConnectionWithSpacesAndSemiColons';
$DatabaseProjectPath = 'aDatabaseProjectPathWithSpaces';
$MsbuildArguments = '/target:Deploy /p:UseSandboxSettings=false /p:TargetConnectionString="{0}" "{1}"' -f $ConnectionString, $DatabaseProjectPath;
Start-Process -FilePath msbuild.exe -ArgumentList $MsbuildArguments;

Put the whole parameter in single quotes:

& msbuild /target:Deploy /p:UseSandboxSettings=false '/p:TargetConnectionString="aConnectionWithSpacesAndSemiColons"' "aDatabaseProjectPathWithSpaces"

The extra level of quoting will mean that PSH doesn't process the content with PSH's rules. (Any single quotes inside the string need to be doubled up—this is the only type of escaping in a PSH single quoted string).

@Richard - Testing this generates a different error saying that no valid project file is provided. I've run this through echoargs pscx helper to show some more detailed examples.

With single quoatation marks wrapping the TargetConnectionString - Powershell evaluates each space in the connectionstring as a new line:

& echoargs /target:Deploy /p:UseSandboxSettings=false    /p:TargetDatabase=UpdatedTargetDatabase /p:TargetConnectionString='"Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False"' "C:\program files\MyProjectName.dbproj"

Arg 0 is </target:Deploy>
Arg 1 is </p:UseSandboxSettings=false>
Arg 2 is </p:TargetDatabase=UpdatedTargetDatabase>
Arg 3 is </p:TargetConnectionString=Data>
Arg 4 is <Source=(local)\SQLEXPRESS;Integrated>
Arg 5 is <Security=True;Pooling=False>
Arg 6 is <C:\program files\MyProjectName.dbproj>

Separating each parameter with backticks recreates the initial problem = no quotation marks around the connectionstring:

& echoargs /target:Deploy `
/p:UseSandboxSettings=false `

c /p:TargetConnectionString="Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False" "C:\program files\MyProjectName.dbproj"

Arg 0 is </target:Deploy>
Arg 1 is </p:UseSandboxSettings=false>
Arg 2 is </p:TargetDatabase=UpdatedTargetDatabase>
Arg 3 is </p:TargetConnectionString=Data Source=(local)\SQLEXPRESS;Integrated Se
curity=True;Pooling=False>
Arg 4 is <C:\program files\MyProjectName.dbproj>

Adding backticks to quotation marks behaves the same as example 1:

& echoargs /target:Deploy `
/p:UseSandboxSettings=false `
/p:TargetDatabase=UpdatedTargetDatabase `
"/p:TargetConnectionString=`"Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False"`"  `
"C:\program files\MyProjectName.dbproj"

Using the @ operator to try to split the parameters still ignores the quotes:

$args = @('/target:Deploy','/p:UseSandboxSettings=false','     /p:TargetDatabase=UpdatedTargetDatabase','/p:TargetConnectionString="Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False"','C:\program files\MyProjectName.dbproj'); $args 

/target:Deploy
/p:UseSandboxSettings=false
/p:TargetDatabase=UpdatedTargetDatabase
/p:TargetConnectionString="Data Source=(local)\SQLEXPRESS;Integrated           Security=True;Pooling=False"
C:\program files\MyProjectName.dbproj

& echoargs $args

Backticks to escape the connectionstring using line separators - same results as example 1:

& echoargs /target:Deploy `
/p:UseSandboxSettings=false `
/p:TargetDatabase=UpdatedTargetDatabase `
"/p:TargetConnectionString=`"Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False"`" `
"C:\program files\MyProjectName.dbproj"

Your problem is that PowerShell does not escape quotes when it passes them to command line applications. I ran into this myself and thought that PowerShell was eating the quotes. Just do this.

msbuild /target:Deploy /p:UseSandboxSettings=false /p:TargetDatabase=UpdatedTargetDatabase '/p:TargetConnectionString=\"Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False\"' "C:\program files\MyProjectName.dbproj"

Thanks to JohnF's answer, I was able to figure this one out, finally.

echoargs /target:clean`;build`;deploy /p:UseSandboxSettings=false /p:TargetConnectionString=`"Data
Source=.`;Integrated Security=True`;Pooling=False`" .\MyProj.dbproj
Arg 0 is </target:clean;build;deploy>
Arg 1 is </p:UseSandboxSettings=false>
Arg 2 is </p:TargetConnectionString=Data Source=.;Integrated Security=True;Pooling=False>
Arg 3 is <.\MyProj.dbproj>

In short, but backticks in front of the double quotes AND the semicolons. Anything less (or more!) will screw it up.

It's mentioned in the Articles from this answer, but with PowerShell 3 you can use --% to stop the normal parsing PowerShell does.

msbuild --% /target:Deploy /p:UseSandboxSettings=false /p:TargetConnectionString="aConnectionWithSpacesAndSemiColons" "aDatabaseProjectPathWithSpaces"