Script PowerShell in PostBuild

Question

Integrazione continua

Ho lavorato a uno script PowerShell per mantenere il nostro processo di sviluppo ottimizzato. Avevo intenzione di eseguirlo come evento post-build, ma ho qualche problema.

Dalle PowerShell prompt, il seguente funziona a meraviglia:

PS C:\> ./example.ps1 

Tuttavia, quando si tenta di eseguire questo da cmd.exe come segue:

C:\> powershell -command "&\"C:\path to script\example.ps1\"" 

lo script viene eseguito, ma ho un giro di errori indietro da PowerShell, composta prevalentemente da errori di risoluzione percorso dalla funzione resolve-path:

Resolve-Path: impossibile trovare il percorso 'C: \ Documents and Settings \ bdunbar \ Documenti \ Visual Studio 2008 \ Projects \ CgmFamilyComm \ FamilyComm \ iirf \ cms \ isapirewrite4.dl l' perché non esiste. in C: \ Documents and Settings \ bdunbar \ Documenti \ Visual Studio 2008 \ Projects \ C gmFamilyComm \ scripts \ cms.ps1: 4 char: 27 + $ iirfpath = (volontà-path < < < < ../ IIRF/cms/isapirewrite4.dll) .path,

Resolve-Path: Impossibile trovare il percorso 'C: \ Documents and Settings \ bdunbar \ Documenti \ Visual Studio 2008 \ Projects \ CgmFamilyComm \ familyComm \ familycomm' perché do es non esiste. in C: \ Documents and Settings \ bdunbar \ Documenti \ Visual Studio 2008 \ Projects \ C gmFamilyComm \ scripts \ cms.ps1: 5 char: 27 + $ vdirpath = (volontà-path < < < < ../ familycomm) .path

C'è un modo per aggirare questo problema? Potrebbe essere un problema con l'esecuzione di resolve-path in cmd.exe?

[Update]

Sono stato in grado di cambiare le cose per aggirare gli errori che si verificano, ma io continuo a ricevere gli errori che funzionano perfettamente bene dal prompt dei comandi PowerShell. Non riesco a capire qual è la differenza.

Answer 1

Ho fatto questo lavoro in passato (vedi http://sharepointpdficon.codeplex.com/SourceControl/changeset/view/13092#300544 se interessati):

C: \ WINDOWS \ system32 \ WindowsPowerShell \ v1.0 \ powershell.exe -nologo -NonInteractive -Command. '$ (ProjectDir) Deployment \ PostBuildScript.ps1' -ProjectDir: '$ (ProjectDir)' -ConfigurationName: '$ (ConfigurationName)' -TargetDir: '$ (TargetDir)' -TargetFileName: '$ (TargetFileName)' -TargetName : '$ (TargetName)

Quindi lanciare questi parametri nella prima riga del copione post-compilazione (se si ou credo che si può essere in grado di usarli):

param($ProjectDir, $ConfigurationName, $TargetDir, $TargetFileName)

Inoltre vorrei sottolineare, non sto usando questo attualmente.Mi è piaciuto usarlo come un veloce blocco per ricaricare i dati dei test per eseguire test di integrazione.

Answer 2

Sembra che il problema sia come vengono risolti i percorsi relativi. I percorsi relativi vengono risolti in base alla posizione corrente (memorizzati in $ pwd) e non in base alla posizione dello script. Quindi, se avessi lanciato lo script da C: \, sicuramente non funzionerebbe.

Vorrei suggerire di caculate i percorsi sulla base di un argomento (come Peter Seale mostra), o afferrare la posizione attuale dello script da:

$MyInvocation.MyCommand.Path