Publicar evento de compilación ejecutar PowerShell

85

¿Es posible configurar un proyecto .NET con un evento posterior a la compilación para ejecutar un script de PowerShell? Estoy usando este script para generar algunos archivos.

También puedo pasar si se trata de una compilación de depuración o versión de script. Un ejemplo de esto sería genial.

c# .net powershell msbuild aficionado
fuente
No tengo un ejemplo, pero aquí hay algunos enlaces que pueden ser útiles: - stackoverflow.com/q/813003/402706 - stackoverflow.com/q/5006619/402706 - Re: Ejecución de PowerShell desde el evento posterior a la generación ignorando ExecutionPolicy - Creación de eventos previos y posteriores a la compilación de Powershell para proyectos de Visual Studio
Brandon Boone

Respuestas:

118

Aquí hay un ejemplo :

En primer lugar : debe tener en cuenta el hecho de que PowerShell debe estar configurado para ejecutar scripts. La siguiente línea permite a PowerShell ejecutar scripts:

Set-ExecutionPolicy RemoteSigned

Mención especial aquí : si está ejecutando un sistema de 64 bits, debe ocuparse del hecho de que 'devenv.exe ', el ejecutable de Visual Studio 2010 es un exe de 32 bits, por lo que debe permitir que PowerShell 32 ejecute scripts.

Una vez aquí, puede ir a las propiedades de su proyecto y configurar la compilación posterior como se muestra aquí en (lo siento en francés):

Publicar compilación en VS 2010

Por ejemplo :

Ejemplo de postbuild con powershell

Aquí está el archivo " psbuild.ps1", crea un " test.txt" en la ruta de destino con el nombre de configuración dentro. Puse en el comentario diferentes formas de depurar su script de postbuild (cuadro de mensaje, sonido, mensaje en la salida)

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
JPBlanc
fuente
8
Buena respuesta. Solo agregaría que no debe establecer la política de ejecución como sin restricciones, sino en remotas. Unrestricted permite que se ejecute cualquier script, mientras que el control remoto requiere que los scripts descargados estén firmados con una clave confiable.
beefarino
2
Hum, ¿prueba para descargar un archivo .PS1 en una unidad Fat32 o usa el FTP cmdline básico para descargar un archivo .PS1 con "remotesigned"? ¿No es una especie de "seguridad humeante"?
JPBlanc
3
+1 por la mención especial para los sistemas de 64 bits. Me estaba volviendo loco hasta que leí que también necesitaba permitir la ejecución en PowerShell de 32 bits. ¡Gracias!
Guðmundur H
desafortunadamente no hay archivos de imagen: i.stack.imgur.com/gZoPi.png i.stack.imgur.com/VTIRW.png
Andrzej Martyna
7
Si utiliza: c: \ windows \ sysnative \ windowspowershell \ v1.0 \ powershell.exe para la ruta, se invocará la versión de 64 bits de powershell. % systemroot% \ sysnative es un alias especial para decirle al redirector que deje de redireccionar y permita el acceso real a% systemroot% \ system32.
Peter Oehlert
15

El comando Set-ExecutePolicy establecerá temporalmente la política de ejecución en la sesión actual. Si configura esto en powershell y ejecuta el comando de compilación posterior en vs, aún no se le permitirá. Así que configure primero y luego ejecute su script ps1 como se muestra a continuación

powershell -ExecutionPolicy Unrestricted $(ProjectDir)Deploy.ps1 -ProjectDir $(ProjectDir) -TargetPath $(TargetPath)
Ariwibawa
fuente
11

En lugar de jugar con la configuración de todo el sistema y tener que diferenciar entre entornos de 32 y 64 bits, un enfoque mucho más fácil y confiable es especificar el ExecutionPolicyen la llamada a PowerShell, de la siguiente manera:

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

Tenga en cuenta en el código anterior cómo llamar Get-ExecutionPolicy le indican el modo actual. También tenga en cuenta cómo se especifica este modo en la llamada a PowerShell, que se puede combinar con un nombre de archivo de script:

contenido de test.ps1:

echo ('The current policy is ' + (Get-ExecutionPolicy)).ToString()

Llamar a test.ps1 con Unrestrictedpolítica en un sistema que tiene scripts deshabilitados:

C:\Users\xyz>PowerShell -ExecutionPolicy Unrestricted -file test.ps1
The current policy is Unrestricted

También tenga en cuenta que la llamada anterior no requiere derechos de administrador, por lo que se puede llamar en el paso previo a la compilación de Visual Studio o similar.

Miguel
fuente
9

Antes de llamar al script de power-shell desde Visual Studio, configure ExecutionPolicy en RemoteSigneddesde la ventana de Power-Shell de esta manera ...

Set-ExecutionPolicy -Scope CurrentUser;
ExecutionPolicy: RemoteSigned;

luego llame al script de powershell de la siguiente manera ...

(no es necesario pasar la ruta completa del archivo "powershell.exe")

powershell.exe $(SolutionDir)Setup.ps1 -SolutionDir $(SolutionDir) -ProjectPath $(ProjectPath)

ingrese la descripción de la imagen aquí

luego, en el script, siempre puede leer el parámetro así ...

param([string]$SolutionDir,
     [string]$ProjectPath);
#Write-Host ($SolutionDir +" Call this script with following aruments");
#Write-Host ($ProjectPath +" Call this script with following aruments");
Narottam Goyal
fuente
6

Lo hice con el siguiente comando en el comando incluso posterior a la compilación:

PowerShell -NoProfile -ExecutionPolicy unrestricted -file $(SolutionDir)AutomationScript\DBAutomationScript.ps1 -target $(SolutionDir)MUFG.SECMOD.Data\SqlScripts -generatedFileName $(SolutionDir)MUFG.SECMOD.Data\SqlScripts\DeploymentDBScript.sql

Contenido de DBAutomationScript.ps1:

param ([string]$target, [string]$generatedFileName)
jnm
fuente