Evento posterior a la compilación de Visual Studio: copiar a la ubicación relativa del directorio


228

En una compilación exitosa, deseo copiar el contenido del directorio de salida a una ubicación diferente en la misma carpeta "base" . Esta carpeta principal es una parte relativa y puede variar según la configuración del control de origen.

He enumerado algunos de los valores de Macro disponibles para mí ...

$ (SolutionDir) = D: \ GlobalDir \ Version \ AppName \ Solution1 \ build

$ (ProjectDir) = D: \ GlobalDir \ Version \ AppName \ Solution1 \ Version \ ProjectA \

Quiero copiar el contenido del Dir de salida a la siguiente carpeta:

D: \ GlobalDir \ Version \ AppName \ Solution2 \ Project \ Dependency

La ubicación base "D: \ GlobalDir \ Version \ AppName" debe recuperarse de una de las macros anteriores. Sin embargo, ninguno de los valores de macro enumera solo la ubicación principal.

¿Cómo extraigo solo la ubicación base para el comando post build copy?

Respuestas:



293

Esto es lo que desea poner en la línea de comando del evento Post-build del proyecto:

copy /Y "$(TargetDir)$(ProjectName).dll" "$(SolutionDir)lib\$(ProjectName).dll"

EDITAR: O si su nombre de destino es diferente al nombre del proyecto.

copy /Y "$(TargetDir)$(TargetName).dll" "$(SolutionDir)lib\$(TargetName).dll"

1
Buen consejo. Olvidé las citas.
Matt Montag

3
No me funcionó porque olvidé el /Y. Gracias por mostrar todo el comando.
Mark

10
Se puede usar xcopycon comodines y los interruptores apropiados para lograr un resultado similar, mientras se mantiene la estructura de la carpeta de origen (árbol), como:xcopy /i /e /s /y /f "<source>\MyFolder\*" "<destination>\MyFolder"
Dr1Ku

44
Sugeriría usar $ (TargetName) en lugar de $ (ProjectName) en la parte fuente.
Alexander Schmidt

2
actualizar a mi anterior. comentario: copy /Y "$(TargetPath)" "$(SolutionDir)somewhere\"sin la barra invertida adicional, ya que $ (SolutionDir) incluye una barra invertida final (al menos en VS2012)
helado el


10

Creo que esto está relacionado, pero tuve un problema al construir directamente usando msbuild línea de comandos (desde un archivo por lotes) vs construir desde dentro de VS.

Usando algo como lo siguiente:

<PostBuildEvent>
  MOVE /Y "$(TargetDir)something.file1" "$(ProjectDir)something.file1"
  start XCOPY /Y /R "$(SolutionDir)SomeConsoleApp\bin\$(ConfigurationName)\*" "$(ProjectDir)App_Data\Consoles\SomeConsoleApp\"
</PostBuildEvent>

(nota: en start XCOPYlugar deXCOPY usarse para solucionar un problema de permisos que impedía la copia)

La macro se $(SolutionDir)evaluó ..\cuando se ejecutó msbuild desde un archivo por lotes, lo que provocó un error en el XCOPYcomando. De lo contrario, funcionó bien cuando se creó desde Visual Studio. Confirmado usando/verbosity:diagnostic para ver la salida evaluada.

En $(ProjectDir)..\cambio, usar la macro , que equivale a lo mismo, funcionó bien y conservó la ruta completa en ambos escenarios de compilación.


1
entrecruzar con el mismo truco en caso de que olvide dar crédito ...
drzaus

Startfuncionó para mí ( xcopyen una carpeta compartida).
AgentFire

4

¿No tendría sentido usar msbuild directamente? Si está haciendo esto con cada compilación, ¿puede agregar una tarea msbuild al final? Si solo desea ver si no puede encontrar otro valor de macro que no se muestre en el IDE de Visual Studio, puede activar las opciones de msbuild para diagnóstico y eso le mostrará todas las variables que podría usar, como así como su valor actual.

Para activar esto en Visual Studio, vaya a Herramientas / Opciones, luego desplácese hacia abajo en la vista de árbol a la sección llamada Proyectos y soluciones, expanda eso y haga clic en Compilar y ejecutar, a la derecha hay un menú desplegable que especifica la verbosidad de salida de compilación , configurando eso como diagnóstico, le mostrará qué otros valores de macro podría usar.

Debido a que no sé a qué nivel te gustaría ir y qué tan complejo quieres que sea tu construcción, esto podría darte una idea. Recientemente he estado haciendo scripts de compilación, que incluso ejecutan código SQL como parte de la compilación. Si desea más ayuda o incluso algunos scripts de compilación de muestra, hágamelo saber, pero si es solo un pequeño proceso que desea ejecutar al final de la compilación, quizás el script completo de msbuild sea un poco exagerado .

Espero que ayude a Rihan


Gracias Rihan, pero aparentemente VS 2003 no parece apoyar esto. Por supuesto, estoy bastante contento con el evento posterior a la compilación ;-)
Preets

No me di cuenta de que era vs2003, y por lo tanto, el uso de msbuild como una posible solución, si recuerdo que vs2003 era anterior a la era de msbuild. Gracias por la respuesta. La mejor de las suertes con VS 2003, no miré hacia atrás después de mudarme a VS2005
Rihan Meij
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.