È possibile impostare un progetto .NET con un evento post build per eseguire uno script PowerShell? Sto usando questo script per generare alcuni file.
Inoltre posso passare se si tratta di una build di debug o di rilascio allo script. Un esempio di questo sarebbe fantastico.
Risposte:
Ecco un esempio:
Prima di tutto : devi essere consapevole del fatto che PowerShell deve essere configurato per eseguire gli script. La riga seguente consente a PowerShell di eseguire gli script:
Set-ExecutionPolicy RemoteSigned
Menzione speciale qui : se si esegue un sistema a 64 bit, è necessario fare attenzione al fatto che "devenv.exe " l'eseguibile di Visual Studio 2010 è un exe a 32 bit, quindi è necessario consentire a PowerShell 32 di eseguire gli script.
Una volta qui puoi andare nelle proprietà del tuo progetto e configurare la post build come mostrato qui sotto (scusate in francese):
Per esempio :
Ecco il file " psbuild.ps1", crea un " test.txt" nel percorso di destinazione con il nome della configurazione all'interno. Ho inserito nei commenti diversi modi per eseguire il debug del tuo script postbuild (finestra di messaggio, suono, messaggio sull'output)
param ([string]$config, [string]$target)
#[void][Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
#[void][System.Windows.Forms.MessageBox]::Show("It works.")
#[Console]::Beep(600, 800)
#Write-Host 'coucou'
set-content $target -Value $config -Force
comando Set-ExecutePolicy imposterà temporaneamente il criterio di esecuzione nella sessione corrente. Se lo imposti in PowerShell ed esegui il comando post build in vs non sarai comunque autorizzato. Quindi imposta prima quindi esegui il tuo script ps1 come sotto
powershell -ExecutionPolicy Unrestricted $(ProjectDir)Deploy.ps1 -ProjectDir $(ProjectDir) -TargetPath $(TargetPath)
Invece di fare confusione con le impostazioni a livello di sistema e dover distinguere tra ambienti a 32 e 64 bit, molto approccio più semplice e affidabile consiste nello specificare ExecutionPolicynella chiamata a PowerShell, come segue:
C:\Users\xyz>PowerShell -ExecutionPolicy Unrestricted
PS C:\Users\xyz> Get-ExecutionPolicy
Unrestricted
PS C:\Users\xyz> exit
C:\Users\xyz>PowerShell -ExecutionPolicy RemoteSigned
PS C:\Users\xyz> Get-ExecutionPolicy
RemoteSigned
Nota nel codice sopra come la chiamata Get-ExecutionPolicyti dice la modalità corrente. Notare anche come questa modalità viene specificata nella chiamata a PowerShell stesso, che può essere combinato con un nome file di script:
contenuti di test.ps1:
echo ('The current policy is ' + (Get-ExecutionPolicy)).ToString()
Chiamare test.ps1 con Unrestricted policy su un sistema con script disabilitati:
C:\Users\xyz>PowerShell -ExecutionPolicy Unrestricted -file test.ps1
The current policy is Unrestricted
Si noti inoltre che la chiamata precedente non richiede diritti di amministratore, quindi può essere chiamata nella fase di pre-compilazione di Visual Studio o simile.
Prima di chiamare lo script power-shell da visual studio, impostare ExecutionPolicy su RemoteSigneddalla finestra power-shell in questo modo ...
Set-ExecutionPolicy -Scope CurrentUser;
ExecutionPolicy: RemoteSigned;
quindi chiama lo script PowerShell nel modo seguente ...
(non è necessario passare il percorso completo del file "powershell.exe")
powershell.exe $(SolutionDir)Setup.ps1 -SolutionDir $(SolutionDir) -ProjectPath $(ProjectPath)
quindi nello script, puoi sempre leggere il parametro in questo modo ...
param([string]$SolutionDir,
[string]$ProjectPath);
#Write-Host ($SolutionDir +" Call this script with following aruments");
#Write-Host ($ProjectPath +" Call this script with following aruments");
L'ho fatto con il comando sotto nel comando post-build anche:
PowerShell -NoProfile -ExecutionPolicy unrestricted -file $(SolutionDir)AutomationScript\DBAutomationScript.ps1 -target $(SolutionDir)MUFG.SECMOD.Data\SqlScripts -generatedFileName $(SolutionDir)MUFG.SECMOD.Data\SqlScripts\DeploymentDBScript.sql
Contenuti DBAutomationScript.ps1:
param ([string]$target, [string]$generatedFileName)