¿Por qué debería usar MSBuild en lugar de los archivos de Visual Studio Solution?

21

Estamos usando TeamCity para una integración continua y está creando nuestras versiones a través del archivo de solución (.sln). He usado Makefiles en el pasado para varios sistemas pero nunca msbuild (lo que he escuchado es como Makefiles + XML mashup). He visto muchas publicaciones sobre cómo usar msbuild directamente en lugar de los archivos de solución, pero no veo una respuesta muy clara sobre por qué hacerlo.

Entonces, ¿por qué deberíamos molestarnos en migrar de los archivos de solución a un 'makefile' de MSBuild? Tenemos un par de lanzamientos que difieren en un #define (compilaciones emplumadas) pero en su mayor parte todo funciona.

La mayor preocupación es que ahora tendríamos que mantener dos sistemas al agregar proyectos / código fuente.

ACTUALIZAR:

¿Pueden las personas arrojar luz sobre el ciclo de vida y la interacción de los siguientes tres componentes?

  1. El archivo .sln de Visual Studio
  2. Los muchos archivos .csproj de nivel de proyecto (que entiendo son secuencias de comandos msbuild "sub")
  3. El script personalizado de msbuild

¿Es seguro decir que .sln y .csproj se consumen / mantienen como de costumbre desde la GUI de Visual Studio IDE mientras el script msbuild personalizado está escrito a mano y generalmente consume el .csproj individual "como está"? Esa es una forma en que puedo ver reducir la superposición / duplicación en el mantenimiento ...

Agradecería un poco de luz sobre esto de la experiencia operativa de otras personas

DeepSpace101
fuente
So, why should we bother migrating from solution files to an MSBuild 'makefile'?Primero tienes que decirte por qué lo estás considerando? ¿No es suficiente el archivo de solución?
jgauffin
3
Porque tiene fama de ser una mejor práctica. Para tu última pregunta; tal vez lo sea, tal vez no lo sea. Es por eso que esta pregunta para explorarlo y obtener una respuesta más clara.
DeepSpace101
2
Because it's reputed to be better practice¿dónde?
jgauffin 01 de
3
La segregación del IDE (archivo sln) de la compilación es ciertamente un buen diseño SE. Jeff ha escrito sobre esto en codinghorror.com/blog/2007/10/… si desea detalles. Además, es bueno iniciar pruebas e incluso paquetes de software (setup.exe o msi) como parte del script de compilación de lanzamiento en lugar de simplemente compilar la compilación.
DeepSpace101
1
@jgauffin: sedodream.com/2010/03/19/…
Josh Noe

Respuestas:

16

El primer punto de hecho es que el archivo de la solución se convierte mágicamente en un archivo de MSBuild cuando MSBuild lo ejecuta, que es lo que sucede cuando compila la solución en Visual Studio. Además, todos esos archivos de proyecto son solo archivos msbuild administrados por Visual Studio. De hecho, los archivos del proyecto manejan la mayor parte del trabajo sucio real aquí, sin importar si está construyendo a partir de soluciones o construyendo desde un script msbuild personalizado.

También usamos TeamCity para compilar y publicar aplicaciones y, por lo general, terminaremos con scripts de msbuild personalizados para la mayoría de los proyectos. El papel que desempeñan estos scripts, que no es realmente fácil con un archivo de solución, es empaquetar el proyecto para su implementación o distribución. Por lo general, estos scripts manejan algunos aspectos más operativos de las cosas, como construir el proyecto web en una carpeta en particular o copiar en las configuraciones en ejecución en lugar de las configuraciones de desarrollo. El trabajo pesado tiende a manejarse en los propios archivos del proyecto: el script de compilación solo hace referencia a ellos, no intentamos recrear esa rueda. En general, funciona muy bien y en realidad no es mucho código duplicado.

Wyatt Barnett
fuente
¿Entonces usa sln + csproj en Visual Studio y luego el mismo script de msbuild + personalizado de csproj's en el servidor de compilación? He aclarado la pregunta un poco. ¡Gracias!
DeepSpace101
Sí, son funcionalmente iguales.
Wyatt Barnett
15

El archivo MAKE para msbuild es el archivo .sln (o archivo vcproj).

Una línea de comando típica de msbuild sería algo así como:

msbuild /p:Configuration=Release BigProject.sln

El punto de usar msbuild es para que puedas escribir y automatizar el proceso de compilación. Ya sea que lo supieras o no, TeamCity ha estado usando msbuild todo el tiempo.

Charles E. Grant
fuente
¿Qué piensa sobre la última parte, sobre la posible superposición de los diversos componentes? He aclarado (¡con suerte!) La pregunta un poco más ... gracias
DeepSpace101
3

Permítanme ofrecer mi opinión sobre esta pregunta.

Aunque ciertamente puede simplemente usar su archivo .SLN como su 'proceso de compilación', el archivo en sí mismo realmente no constituye un proceso de compilación. El archivo de solución es realmente solo una parte de Visual Studio y se utiliza para el desarrollo. Pero Visual Studio es solo una parte del proceso de compilación y lanzamiento. No puede confiar en las soluciones para administrar su compilación, y las soluciones ciertamente no ofrecen una situación de compilación escalable.

El propósito completo de establecer un proceso de compilación es crear compilaciones confiables. Es decir, el proceso de compilación es tan confiable que no importa la configuración de compilación, obtendrá un resultado de compilación predecible. Cada vez, cada máquina. El resultado de una construcción predecible y confiable es que el proceso de prueba, implementación y lanzamiento puede ser altamente automatizado, reduciendo aún más el riesgo de error humano.

Establecer un proceso de construcción requiere una inversión, pero en ciertos casos, se requiere la inversión. Aquí hay algunos factores que favorecen un proceso de msbuild:

  • Su producto tiene varios equipos (multifuncionales o de otro tipo) que trabajan en el mismo proyecto de equipo.
  • Su organización tiene solo un proyecto de equipo (debería ser el caso del 99% de las tiendas tradicionales, incluso aquellas con más de 200 desarrolladores)
  • Tiene más de 20 proyectos que deben construirse, algunos de los cuales dependen de otros y son mantenidos por diferentes equipos.
  • Su producto incorpora múltiples tecnologías .NET (C #, C ++, VB, F #, ASP.NET, etc.), o incluso tecnologías que no son .NET (Grunt, node, npm, Java, etc.)
  • Su producto tiene dependencias de peso pesado o está construido sobre una plataforma de peso pesado. SharePoint, como ejemplo

Permítanme dar un ejemplo para ampliar mi último punto. Mi empresa actual hace desarrollo de SharePoint. El desarrollo de SharePoint como mínimo requiere que se instale SharePoint Foundation para realizar compilaciones en proyectos de SharePoint. Hablando en términos de un servidor de compilación liviano, es completamente impráctico requerir que el servidor de compilación tenga instalado SharePoint. SharePoint no solo es una bestia con altos requisitos, sino que también tendría serias implicaciones de rendimiento en una compilación, y se supone que las compilaciones son lo más rápidas y sencillas posible. Aprovechar MSBuild me permite eliminar este requisito de instalación en el servidor de compilación. De hecho, nuestro servidor de compilación no tiene requisitos de instalación que no sean .NET Framework (requerido por MSBuild) y Node.

Como referencia, recomendaría consultar este libro de Sayed Ibrahim Hashimi: http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1?ie=UTF8&qid=1412014650&sr= 8-1-fkmr0 & keywords = msbuild + confiable + compilación

Mike Gilmore
fuente
1
¿Qué tiene que ver el uso de archivos msbuild en lugar de archivos sln con no tener que instalar SharePoint en el servidor de compilación? Estos son conceptos completamente no relacionados. El archivo de solución no tiene ninguna dependencia de nada. Además, se puede ciertamente confía en archivos de solución para gestionar su construcción, ya que esto es lo que nuestra compañía ha estado haciendo durante años sin problemas. Creo que puede confundir los archivos de solución y msbuild con la herramienta msbuild, que también admite archivos de solución. No estamos utilizando Visual Studio para compilar la solución en la máquina de compilación.
julealgon
+1 para su explicación de "Su organización tiene un solo proyecto de equipo". Me duele ver a las personas que utilizan múltiples proyectos de equipo como límites para cosas como 'productos' o 'proyectos' en tiendas tan pequeñas. Tomé el enfoque de proyecto de equipo único y espero que nunca tenga que volver.
JohnZaj
2

¡Esta es exactamente la pregunta que me hice hace unos meses! Teníamos todo bien organizado:

  • Archivo de solución muy bien en la raíz de los repositorios
  • Crear pasos configurados en Teamcity, como
    • Restaurar paquetes NuGet
    • Construir solución
    • Ejecutar pruebas unitarias
    • Configuración del entorno de prueba de integración
    • Ejecute pruebas de integración
    • Derribar el entorno de prueba de integración
    • Crear un paquete de implementación
    • Construir script de migración

Y luego, cuando se trata de reproducibilidad, se hizo evidente que esto obtuvo un puntaje bajo. Cuando deja que TeamCity sea su script de compilación, se hace difícil reproducir resultados similares, confiables, en su propia máquina de desarrollo.

Cuando tiene un script de compilación, el script de compilación sabe todo lo que debe hacerse y tiene todas las variables en su lugar. Cuando usa un servidor CI como su script de compilación, y ocurre algún problema, como una falla de prueba compleja o la necesidad de compilar un paquete de implementación manualmente (como en mi ejemplo), necesita unir todos los pasos de la compilación manualmente.

Entonces, en resumen , ¿por qué un script de compilación (MS)? Porque terminarás teniendo más requisitos cuando se trata de tu construcción. Probablemente desee ejecutar algunas pruebas y generar algunos artefactos a partir de eso. Probablemente quieras hacer implementaciones. Y cuando todo lo que desea debe ser ejecutable, ya sea en un servidor de compilación o en su máquina, no puede terminar en otro lugar que no sea un script de compilación.

Sebazzz
fuente
1
++ Solo estaba teniendo esta discusión con nuestro líder hoy. Su compilación debe ser ejecutable desde cualquier lugar , no solo una GUI en algún servicio en la nube.
RubberDuck