Czy można skonfigurować projekt .NET ze zdarzeniem po kompilacji, aby wykonać skrypt PowerShell? Używam tego skryptu do generowania plików.
Mogę również przekazać, czy jest to kompilacja debugowania lub wydania do skryptu. Przykład tego byłby świetny.
Odpowiedzi:
Oto przykład :
Po pierwsze : musisz mieć świadomość, że PowerShell musi być skonfigurowany do wykonywania skryptów. Poniższy wiersz umożliwia programowi PowerShell wykonywanie skryptów:
Set-ExecutionPolicy RemoteSigned
Specjalna wzmianka tutaj : jeśli używasz 64-bitowego systemu, musisz uważać na fakt, że „devenv.exe ” plik wykonywalny Visual Studio 2010 jest plikiem exe 32-bitowym, więc musisz pozwolić PowerShell 32 na wykonywanie skryptów.
Tutaj możesz przejść do właściwości projektu i skonfigurować post build, jak pokazano tutaj (przepraszam po francusku):
Na przykład :
Oto plik „ psbuild.ps1”, tworzy „ test.txt” w ścieżce docelowej z nazwą konfiguracji w środku. W komentarzu umieściłem różne sposoby debugowania skryptu postbuild (komunikat, dźwięk, komunikat na wyjściu)
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
polecenie Set-ExecutePolicy tymczasowo ustawi zasady wykonywania w bieżącej sesji. Jeśli ustawisz to w programie PowerShell i uruchomisz polecenie po kompilacji w vs, nadal nie będziesz mógł. Więc ustaw najpierw, a następnie uruchom skrypt ps1 jak poniżej
powershell -ExecutionPolicy Unrestricted $(ProjectDir)Deploy.ps1 -ProjectDir $(ProjectDir) -TargetPath $(TargetPath)
Zamiast majstrować przy ustawieniach całego systemu i rozróżniać środowiska 32- i 64-bitowe, znacznie łatwiejszym i bardziej niezawodnym podejściem jest określenie ExecutionPolicyw wywołaniu programu PowerShell w następujący sposób:
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
Zwróć uwagę w powyższym kodzie, w jaki sposób wywołanie Get-ExecutionPolicyinformuje o aktualnym trybie. Zwróć również uwagę, jak ten tryb jest określony w wywołaniu samego programu PowerShell, który można połączyć z nazwą pliku skryptu:
zawartość testu.ps1:
echo ('The current policy is ' + (Get-ExecutionPolicy)).ToString()
Wywołanie test.ps1 z Unrestrictedpolityką w systemie z wyłączonymi skryptami:
C:\Users\xyz>PowerShell -ExecutionPolicy Unrestricted -file test.ps1
The current policy is Unrestricted
Należy również zauważyć, że powyższe wywołanie nie wymaga uprawnień administratora, więc można je wywołać w kroku poprzedzającym kompilację programu Visual Studio lub podobnym.
Przed wywołaniem skryptu Power-Shell z programu Visual Studio, ustaw ExecutionPolicy na RemoteSignedz okna Power-Shell w następujący sposób ...
Set-ExecutionPolicy -Scope CurrentUser;
ExecutionPolicy: RemoteSigned;
następnie wywołaj skrypt PowerShell w następujący sposób ...
(nie ma potrzeby przekazywania pełnej ścieżki do pliku „powershell.exe”)
powershell.exe $(SolutionDir)Setup.ps1 -SolutionDir $(SolutionDir) -ProjectPath $(ProjectPath)
wtedy w skrypcie zawsze możesz odczytać parametr w ten sposób ...
param([string]$SolutionDir,
[string]$ProjectPath);
#Write-Host ($SolutionDir +" Call this script with following aruments");
#Write-Host ($ProjectPath +" Call this script with following aruments");
Zrobiłem to za pomocą poniższego polecenia w poleceniu nawet po kompilacji:
PowerShell -NoProfile -ExecutionPolicy unrestricted -file $(SolutionDir)AutomationScript\DBAutomationScript.ps1 -target $(SolutionDir)MUFG.SECMOD.Data\SqlScripts -generatedFileName $(SolutionDir)MUFG.SECMOD.Data\SqlScripts\DeploymentDBScript.sql
Zawartość DBAutomationScript.ps1:
param ([string]$target, [string]$generatedFileName)