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

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

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.

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.

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

¡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.