Powershell-Aufruf von msbuild mit verschachtelten Anführungszeichen

Mithilfe von Powershell und Psake Paket zu erstellen und die Bereitstellung für eine visual studio-Lösung.
Versuch zum bereitstellen eines Datenbank-Projekts mithilfe von msbuild - die arbeiten richtig mit MS-DOS-visual studio-Befehlszeile

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

gleichen Methode-Aufruf führt zu einem Fehler beim Aufruf von powershell

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

Bezug auf Leerzeichen und kann nicht herausfinden, wie zu replizieren dieser Aufruf in der powershell - Beispiel-Datenbank connectionstring
Data Source=.\SQL2008;Initial Catalog=DocumentExecution;Integrated Security=True;

InformationsquelleAutor der Frage JohnF | 2011-06-03

  1. 56

    Kurze Version

    Wie Sie übergeben ein argument mit Anführungszeichen in eine native PowerShell-Befehl aus?

    • Verwenden Sie einfache Anführungszeichen statt der doppelten Anführungszeichen in der argument-string:

         "/p:Target='Data Source=(local)\SQL;Integrated Security=True'"

      → /p:Target='Data Source=(local)\SQL;Integrated Security=True'

    • Verwenden backslash-escaping für doppelte Anführungszeichen im argument Zeichenfolge∗:

         '/p:Target=\"Data Source=(local)\SQL;Integrated Security=True\"'

      → /p:Target="Data Source=(local)\SQL;Integrated Security=True"

    Wenn das eingebettete Zitate werden nur verwendet, um zu behandeln, das argument als eine einzige Zeichenfolge, sondern als ein erforderlicher Teil der parameter, dann die folgenden verwendet werden können:

    • Zitieren, das gesamte argument-string, anstelle der Einbettung der Zitate in die Argumentation:

         '/p:Target=Data Source=(local)\SQL;Integrated Security=True'

      → /p:Target=Data Source=(local)\SQL;Integrated Security=True

    • Flucht alle PowerShell-Sonderzeichen mit backticks∗ (dies kann nur durchgeführt werden als in-line-argument):

         /p:Target=`"Data Source=`(local`)\SQL`;Integrated Security=True`"

      oder /p:Target=Data` Source=`(local`)\SQL`;Integrated` Security=True

      → /p:Target=Data Source=(local)\SQL;Integrated Security=True


    Die vollständige Befehlszeile Beispiel (unter Verwendung der zweiten 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 </Zielgruppe:Deploy> 
Arg 1 </p:UseSandboxSettings=False> 
Arg 2 </p:TargetDatabase=UpdatedTargetDatabase> 
Arg 3 </p:TargetConnectionString="Data Source=(local)\SQL;Integration Security=True"> 
Arg 4 ist <C:\program Dateien\MyProjectName.dbproj>

    Lange Version

    Aufrufen native Befehle ist etwas, dass taucht ganz ein bisschen wie Leute bewegen sich zwischen den legacy-cmd-system und PowerShell (fast so viel wie die "Trennung Parameter mit Kommata" gotcha ;).

    Habe ich versucht, und Summe up, alles, was ich weiß, zum Thema Kommando-Aufruf in der PowerShell (v2 und v3) hier, zusammen mit allen Beispielen und Referenzen, die ich aufbringen kann.

    1) Aufruf Nativer Befehle Direkt

    1.1) In seiner einfachsten Form, für eine ausführbare Datei befindet, in die Umgebungsvariable path der Befehl direkt aufgerufen werden könnengenauso, wie Sie Sie nennen würde, eine 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) Außerhalb der Umgebung Weg, für Befehle in ein bestimmtes Verzeichnis (inklusive der aktuellen), der vollständige oder relative Pfad zu dem Befehl kann verwendet werden,. Die Idee: die Betreiber erklären ausdrücklich "ich aufrufen möchte diese Datei", anstatt lassen Sie eine beliebige Datei, die zufällig den gleichen Namen laufen zu bekommen an seiner Stelle (sehen Sie, diese Frage für weitere Informationen über die PowerShell Sicherheit). Andernfalls verwenden Sie einen Pfad, wenn es erforderlich ist, führt zu einem "Begriff wird nicht erkannt" - Fehler.

    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), Wenn ein Pfad Sonderzeichen enthält, wird der Aufruf-operator oder escape-Zeichen verwendet werden können. Zum Beispiel, eine ausführbare Datei starten mit einer Nummer, oder die sich in einem Verzeichnis mit einem Leerzeichen.

    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) Aufruf Nativer Befehle Indirekt

    2.1)Wenn Sie nicht schreiben aus einem Befehl interaktiv, sondern haben stattdessen den Pfad in einer variable gespeichert, der Aufruf-operator kann auch verwendet werden, um den Befehl aufzurufen Namen in eine 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) Die übergebenen Argumente zu einem Befehl kann auch gespeichert werden in der Variablen. Argumente, die in Variablen übergeben werden können einzeln, oder in einem array. Für Variablen, die Leerzeichen enthalten, PowerShell wird automatisch die Flucht der Räume so, dass die native-command-sieht es als ein einziges argument. (Beachten Sie, dass der Aufruf-operator behandelt den ersten Wert als den Befehl und die übrigen Werte als Argumente, die Argumente sollten nicht kombiniert werden mit dem Befehl 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) Die array-format ist besonders nützlich für den Aufbau einer dynamischen Liste von Argumenten für einen nativen Befehl. Für jedes argument anerkannt werden, die als eigenständige parameter, ist es wichtig, die Argumente erhalten, gespeichert in einer array-Variablen, und nicht nur verwurschtelt zusammen in eine Zeichenfolge. (Beachten Sie, dass die gängige Abkürzung $args ist eine automatische variable in PowerShell, die kann dazu führen, die Werte der gespeicherten überschrieben wird; stattdessen ist es besser, verwenden Sie einen beschreibenden Namen wie $msbuildArgs zu vermeiden, den Namenskonflikt.)

    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) Auch für Skripts, Funktionen, cmdlets, und dergleichen, PowerShell v2 senden können benannte Argumente, die in einer hashtable mit einer Technik namens "splatting", ohne befürchten zu müssen, über parameter um. Dies funktioniert nicht mit native-Befehle, die nicht an der PowerShell-Objekt-Modell und können nur string-Werte.

    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) Aufruf Nativer Befehle Mit Komplizierten Argumenten

    3.1) Für einfache Argumente, die automatische escaping verwendet, für die native-Befehle ist in der Regel ausreichend. Jedoch, für Klammer, dollar-Zeichen, Leerzeichen und solche, Zeichen verwendet, die von PowerShell müssen escaped werden, um gesendet werden, um native Befehleohne dass Sie interpretiert durch den parser. Diese kann getan werden, mit der "backtick" escape-Zeichen, `oder, indem er das argument in einem einzigen-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) das ist Leider nicht so einfach, wenn doppelte Anführungszeichen beteiligt sind. Als Teil der argument-Verarbeitung für systemeigene Befehle die PowerShell-Prozessor versucht zu normalisieren, alle doppelten Anführungszeichen im argument so, dass der Inhalt des Arguments, sans Anführungszeichen, übergeben wird als einen einzelnen Wert zu den nativen Befehl. Die native-command-parameter-Verarbeitung erfolgt in einem separaten Schritt nach der Analyse, so normale Flucht wird nicht funktionieren, für "doppelte Anführungszeichen"; nur entging einfache Anführungszeichen oder backslash-Escape-Anführungszeichen können verwendet werden,.

    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 Hinzugefügt, eine neue stop-parsing-symbol --% (siehe about_Parsing). Wenn verwendet, bevor die komplizierten Argumente, --% werden Argumente übergeben werden wie Sie ist ohne jede Analyse oder variable expansion, außer für cmd-wie %ENVIRONMENT_VARIABLE% Werte.

    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>

    Diese können auch verwendet werden, um de-munge eine einzelne Zeichenfolge, die mehrere Argumente an, indem Sie die stop-parsing-symbol in einer Zeichenkette (string)∗ (obwohl die beste Vorgehensweise ist, um nicht munge Argumente in den ersten Platz).

    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) Debuggen Systemeigener Befehle

    Gibt es zwei wichtige tools, die für das Debuggen der Argumente PowerShell geht auf systemeigene Befehle.

    4.1) Die erste ist EchoArgs.exeeine Konsole-Anwendung aus der PowerShell Community Extensions , schreibt einfach wieder die Argumente übergeben werden zwischen Spitzen Klammern (siehe die Beispiele oben).

    4.2) Die zweite ist Trace-Commandein cmdlet kann, zeigen viele details, wie die PowerShell-Prozesse auf eine pipeline. Insbesondere die NativeCommandParameterBinder trace-Quelle wird zeigen, was PowerShell empfängt und weitergibt an einen nativen Befehl.

    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"

    Andere Ressourcen

    Artikel

    Fragen

    InformationsquelleAutor der Antwort Emperor XLII

  2. 11

    Das alles könnte sein, viel einfacher, wenn Sie die Start-Process - cmdlet mit dem -ArgumentList-parameter. Ich bin überrascht, dass dies noch nicht schon erwähnt.

    Beispiel:

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

    Hier ist eine Methode, die ich verwenden gerne ein bisschen besser, die es erlaubt, Variablen-Ersetzung:

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

    InformationsquelleAutor der Antwort Trevor Sullivan

  3. 4

    Setzen Sie den gesamten parameter in Anführungszeichen:

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

    Den extra-level zu zitieren, bedeutet, dass PSH nicht Prozess, den Inhalt mit PSH Regeln. (Alle single-quotes innerhalb des Strings müssen verdoppelt—dies ist die einzige Art von Flucht, die in einer PSH single quoted string).

    InformationsquelleAutor der Antwort Richard

  4. 1

    @Richard - Tests führt zu einer anderen Fehlermeldung, dass keine gültige Projekt-Datei bereitgestellt.
    Ich haben dies durch echoargs pscx Helfer zeigen einige ausführlichere Beispiele.

    1. Mit einzelnen quoatation Marken einwickeln der TargetConnectionString - Powershell wertet jeden Raum im connectionstring, wie eine neue Zeile ein:

      & 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>

    2. Trennt die einzelnen parameter mit backticks stellt das erste problem = keine Anführungszeichen um den connectionstring:

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

      c
      /p:TargetConnectionString="Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False"
      "C:\program Dateien\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>

    3. Hinzufügen backticks zu Anführungszeichen verhält sich wie in Beispiel 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"

    4. Mithilfe der @ - operator zu versuchen, teilen Sie die Parameter noch ignoriert die Zitate:

      $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

    5. Backticks zu entkommen, die connectionstring-line-Trennlinien - gleichen Ergebnissen wie in Beispiel 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"

    InformationsquelleAutor der Antwort JohnF

  5. 1

    Dein problem ist, dass die PowerShell nicht entziehen Anführungszeichen, wenn es geht Sie in Kommandozeilen-Applikationen. Ich lief in das ich und dachte, dass PowerShell aß die Anführungszeichen. Genau dies tun.

    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"

    InformationsquelleAutor der Antwort JasonMArcher

  6. 1

    Dank JohnF Antwort, ich war in der Lage, diese Figur ein, endlich.

    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>

    Kurz, aber backticks vor den Anführungszeichen UND das Semikolon. Etwas weniger (oder mehr!) wird es vermasseln.

    InformationsquelleAutor der Antwort moswald

  7. 1

    Es ist erwähnt in den Artikeln von diese Antwortaber mit PowerShell 3 Sie können --% zum stoppen der normalen parsing-PowerShell. 

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

    InformationsquelleAutor der Antwort Lars Truijens

Schreibe einen Kommentar