especificar el archivo de proyecto de una solución usando msbuild


116

Quiero la línea de comando para construir un proyecto particular de una solución usando msbuild como lo hacemos con devenv.com. En devenv.com podemos especificar un proyecto de una solución usando la siguiente línea de comando

devenv.com /Build Release|x86 test.sln /project "testproject"

Usando la línea de comando anterior, puedo construir el proyecto de prueba en test.sln usando devenv.com. ¿Cuál es la línea de comando para msbuild para la misma solución?

Gracias


¿Alguna razón por la que no está pasando el proyecto de prueba a msbuild?
Mark Smith

2
Dado que ya no puedo editar mi comentario. Lo que quiero decir es hacer referencia al proyecto directamente en lugar de a la solución. "msbuild testproject / p: Configuration = Release / p: Platform = x86"
Mark Smith

Diferente tiempo tengo para construir diferentes proyectos. Usando devenv.com es fácil especificando el proyecto de esa solución
tjdoubts

Si ese es el único problema que tiene, debería poder usar msbuild para construir los proyectos necesarios en los momentos correctos. Ya tiene diferentes comandos que ejecuta en diferentes momentos en la solución, así que ¿por qué no simplemente hacer referencia a los proyectos en los momentos adecuados con diferentes comandos de msbuild? Si sus proyectos están configurados correctamente, deberían averiguar todas sus referencias sin usar el archivo sln.
Mark Smith

Respuestas:


202
msbuild test.sln /t:project /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false

Tenga en cuenta que lo que se asigna /tes el nombre del proyecto en la solución, puede ser diferente del nombre del archivo del proyecto.

Además, como se indica en Cómo: crear destinos específicos en soluciones mediante MSBuild.exe :

Si el nombre del proyecto contiene cualquiera de los caracteres %, $, @, ;, ., (, ), o ', reemplazarlos con una _en el nombre de destino especificado.

También puede crear varios proyectos a la vez:

msbuild test.sln /t:project;project2 /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false

Para reconstruir o limpia, el cambio /t:projectde /t:project:cleano/t:project:rebuild


98
Una nota importante: si su proyecto tiene un '.' en el nombre, deberá reemplazarlo con un '_' cuando lo especifique con / t
Watusimoto

4
@easton Para construir múltiples proyectos, el Synthax era para que mi msbuild repitiera el /tparámetro para cada proyecto a construir:msbuild test.sln /t:project /t:project2
Philippe

46
Además, si está utilizando una carpeta de solución, debe anteponer el nombre del proyecto con el nombre de la carpeta y una barra inclinada. Como @Watusimoto mencionado anteriormente, si tiene puntos (.) En el nombre, debe reemplazarlos con guiones bajos (_). Terminé con algo como esto: /t:SlnFolder\My_Project_name.
Travis Parks

28
@TravisParks: También vale la pena mencionar que la "carpeta de la solución" no se refiere a una carpeta del sistema de archivos, sino a una carpeta en la vista del Explorador de soluciones.
joshbodily

4
También tuve que reemplazar '(' y ')' con '_' en el nombre de la carpeta (proyectos generados por GYP). Supongo que todos los caracteres especiales se reemplazan por guiones bajos.
Maxime Viargues

15

MSBuild realmente funciona mediante el uso de proyectos, no la solución. La solución solo se usa para analizarlo en un archivo de proyecto temporal en MSBuild internamente. Debería poder construir el proyecto de interés directamente a través de MSBuild ejecutando el siguiente comando.

"msbuild testproject /p:Configuration=Release /p:Platform=x86"

Hay un problema importante que sé que podría encontrar al usar el proyecto directamente en lugar de la solución: si usa la solución para expresar dependencias entre los proyectos, en lugar de agregar las referencias al proyecto y dejar que el sistema de compilación resuelva las dependencias automáticamente .

Si está aplicando una orden de compilación utilizando el archivo sln, le recomiendo trabajar esas dependencias directamente en los archivos proj y eliminarlas del archivo sln. Esto le permitirá invocar cualquier archivo de proyecto desde MSBuild directamente y todos los proyectos se construirán de forma independiente sin ningún trabajo adicional. Realmente debería tratar el archivo sln como un grupo de proyectos para facilitar el trabajo en Visual Studio y no como una entrada de compilación.


4
Indique cómo se puede hacer cumplir el orden de construcción desde los archivos del proyecto. Gracias.
ProgramCpp

4
Aquí hay otro problema al usar el nombre del proyecto directamente. Por ejemplo, tiene 5 proyectos en su solución. Algunos proyectos tienen configuración DebugPro y otros proyectos no la tienen. Si crea un proyecto con la configuración que todos los proyectos tienen, todo es un archivo pero solo el archivo de solución, sepa qué configuración de proyecto usar para cada proyecto si seleccionó la configuración de solución DebugPro.
Alex

@ProgramCpp Cuando agrega referencias de un proyecto a otro, automáticamente se da cuenta de que el proyecto al que se hace referencia debe compilarse primero.
jpaugh

Otra desventaja de este enfoque es que la ruta relativa en el proyecto se resuelve en relación con el archivo de solución. Una vez que construya el proyecto directamente, la ruta relativa cambiará. La salida puede estar en otro lugar y las pruebas unitarias pueden buscar directorios incorrectos.
Tomas Kubes

También pueden aparecer problemas si usa variables de solución en la configuración del proyecto, como $ (SolutionDir)
Alex Che

8

Publicar como información para futuros buscadores

Agregue lo siguiente al script de compilación y ejecútelo una vez. Esto generará los objetivos exactos y otra información que realmente utilizará msbuild.

Por ejemplo: si tiene .en el nombre del proyecto o carpetas, msbuild esperará _en lugar de ..

set MSBuildEmitSolution=1

Después de obtener la información, actualice el script de compilación con los detalles requeridos.


6
'Si tiene'. ' en el nombre del proyecto o carpetas, msbuild esperará '_' en lugar de '.'. `
dhcgn

2

Para hacer esto, necesita saber cuál es el nombre-objetivo del proyecto , no necesariamente el nombre del proyecto.

Una forma de averiguarlo es usar MSBuild contra su SLN con los parámetros previstos después de establecer una variable de entorno especial llamada MSBuildEmitSolutional valor de 1.

set MSBuildEmitSolution=1
msbuild my_stuff.sln /t:rebuild /p:Configuration=Release /p:Platform=x64

Recientemente tuve que hacer esto debido a un nombre muy específico para un objetivo en directorios anidados. Entonces, de mi archivo generado, my_stuff.sln.metaprojencontré esta línea:

<Target Name="Utils\Firewall\FirewallUtils:Rebuild">

Eso significa que la línea de comandos a usar termina siendo,

msbuild my_stuff.sln /t:Utils\Firewall\FirewallUtils:Rebuild /p:Configuration=Release /p:Platform=x64

2
Esto era lo que necesitaba. Sugerencia si no desea ejecutar esto: su destino es la estructura de carpetas de la ruta actual a su archivo de proyecto, menos la extensión del archivo de proyecto ( .csprojen mi caso). Yo <3 ¡ASÍ!
No hay reembolsos No hay devoluciones

1

Solo para agregar información adicional, la ejecución de msbuild en la carpeta del proyecto construirá de forma predeterminada el archivo del proyecto, ya que es el único allí.

>msbuild

Hay muchas variaciones del uso de msbuild de esta manera. Puede especificar el archivo de proyecto directamente.

>msbuild helloworld.csproj -t:Build.

Revise la documentación de msbuild para conocer el uso, los requisitos del archivo de proyecto y los beneficios de crear el proyecto en lugar de la solución.

Documentación de MS MSBuild

Hay beneficios de construir de esta manera como lo mencionó Mark-Smith anteriormente.

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.