2009-05-01 12 views
17

Integración continua

He estado trabajando en un script de PowerShell para mantener nuestro proceso de desarrollo optimizado. Estaba planeando ejecutarlo como un evento de construcción posterior, pero estoy teniendo algunos problemas.Script de PowerShell en PostBuild

De los PowerShell rápidas, los siguientes funciona de maravilla:

PS C:\> ./example.ps1 

Sin embargo, al intentar ejecutar esto desde cmd.exe de la siguiente manera:

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

El script se ejecuta pero consigo una ronda de errores volver desde PowerShell, que consiste principalmente en errores de resolución de ruta de la función resolve-path:

Resolver-Ruta: no se puede encontrar la ruta 'C: \ Documents and Settings \ bdunbar \ Mis documentos \ Visual Studio 2008 \ Projects \ CgmFamilyComm \ FamilyComm \ iirf \ cms \ isapirewrite4.dl l' porque no existe. en C: \ Documents and Settings \ bdunbar \ Mis documentos \ Visual Studio 2008 \ Projects \ C gmFamilyComm \ scripts \ cms.ps1: 4 Char: 27 + $ iirfpath = (determinación de la ruta < < < < ../ IIRF/cms/isapirewrite4.dll) .Path,

Resolve-Path: no encontraste ruta 'C: \ Documents and Settings \ bdunbar \ Mis documentos \ Visual Studio 2008 \ Projects \ CgmFamilyComm \ familyComm \ familycomm' porque do es no existe. en C: \ Documents and Settings \ bdunbar \ Mis documentos \ Visual Studio 2008 \ Projects \ C gmFamilyComm \ scripts \ cms.ps1: 5 Char: 27 + $ vdirpath = (determinación de la ruta < < < < ../ familycomm) .path

¿Hay alguna forma de solucionar este problema? ¿Podría ser un problema ejecutar resolve-path en cmd.exe?

[Actualización]

que he sido capaz de cambiar las cosas para moverse por los errores que se están produciendo, pero sigo recibiendo errores que funcionan perfectamente bien desde el símbolo del sistema de PowerShell. No puedo entender cuál es la diferencia.

+0

Lo dijo Jason. La diferencia probablemente tiene que ver con su línea de camino de resolución. Si tiene dudas, intente que su script funcione sin usar resolve-path en absoluto. –

Respuesta

25

He hecho este trabajo en el pasado (ver http://sharepointpdficon.codeplex.com/SourceControl/changeset/view/13092#300544 si está interesado):

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)

Luego arroje estos parámetros en la primera línea de su script post-build (si y ou piensa que puede ser capaz de utilizarlas):

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

También debo señalar, no estoy utilizando esta actualmente.Me gustó usarlo como un bloc de notas rápido para volver a cargar datos de prueba para ejecutar pruebas de integración.

+0

Gracias por la respuesta Peter, esto funciona perfectamente. Cuál es el . por delante del nombre del archivo y ¿cómo supiste ponerlo allí? Gracias de nuevo, +1 de mi parte. – brad

+0

jaja, ojalá lo supiera. Arreglé el mío a partir de un script que encontré en un hilo del foro de Channel 9, creo que ahora no puedo encontrarlo. –

+0

Puedo adivinar que es un punto, incluido el guión, aunque no pensé que pudiera incluir puntos y pasar argumentos a un guión. Interesante. De todos modos, resolve-path funcionaría de manera diferente si ejecutaste & -executed versus dot-incluyó el script. –

3

Parece que su problema es cómo se resuelven las rutas relativas. Las rutas relativas se resuelven según la ubicación actual (almacenada en $ pwd) y no en función de la ubicación de la secuencia de comandos. Entonces, si lanzaste el script desde C: \, definitivamente no funcionaría.

yo sugeriría que caculate los caminos basado en un argumento (como Peter Seale muestra), o agarrar la ubicación real de la secuencia de comandos de:

$MyInvocation.MyCommand.Path 
Cuestiones relacionadas