.net msbuild automation nant

.net - NAnt o MSBuild, ¿cuál elegir y cuándo?



automation (14)

Soy consciente de que hay otras preguntas relacionadas con NAnt y MSBuild en Stack Overflow, pero no pude encontrar una comparación directa entre las dos y esta es la pregunta.

¿Cuándo se debe elegir NAnt sobre MSBuild? ¿Cuál es mejor para qué? ¿NAnt es más adecuado para proyectos domésticos / de código abierto y MSBuild para proyectos de trabajo? ¿Cuál es la experiencia con cualquiera de los dos?

Aunque no estoy muy familiarizado con MsBuild, tengo la impresión de que algunas de las diferencias clave en ambos lados se pueden complementar con adiciones:

Recientemente tuve que construir un proyecto de Silverlight en Nant. Descubrí que la vida sería más fácil si solo hiciera esto con MsBuild: terminé llamando a una tarea de MsBuild desde un script de Nant, así que supongo que no es demasiado fuera de lo común mezclar y combinar los dos.

Más allá de eso, supongo que se tratará de una cuestión de preferencia personal; obviamente, puedes administrar parte o la mayoría de la funcionalidad de MsBuild desde Visual Studio, si eso es lo tuyo. Nant parece ser más flexible y más adecuado si prefiere escribir guiones a mano, y si proviene del mundo de Java, probablemente se sienta como en casa con él.

He hecho una investigación similar esta semana. Esto es lo que he podido determinar:

NAnt:

  • Multiplataforma (compatible con Linux / Mono). Puede ser útil para instalar un sitio web en varios destinos (es decir, Linux Apache y Windows IIS), por ejemplo.
  • 95% similar en sintaxis a Ant (fácil para los usuarios actuales de Ant o constructores de Java)
  • Integración con NUnit para ejecutar pruebas unitarias como parte de la compilación, y con NDoc para documentación de productivos.

MSBuild:

  • Incorporado a .NET.
  • Integrado con Visual Studio
  • Fácil de empezar con MSBuild en Visual Studio: todo está detrás de escena. Si quiere profundizar, puede editar manualmente los archivos.

Diferencias subjetivas: (YMMV)

  • La documentación de NAnt es un poco más directa. Por ejemplo, la Referencia de tareas de MSBuild enumera "Tarea Csc - Describe la tarea Csc y sus parámetros". (¿Gracias por la "ayuda"?), Frente a la Referencia de tareas NAnt "csc - Compila programas C #". ACTUALIZACIÓN: Me he dado cuenta de que la documentación de MSBuild se ha mejorado y ahora está mucho mejor (probablemente a la par con NAnt).
  • No es fácil averiguar cómo editar el origen del script de compilación (archivo *. * Proj) directamente desde Visual Studio. Con NAnt, solo tengo que Visual Studio trate el script .build como un archivo XML.
  • Aparentemente, en Visual Studio, los proyectos de aplicaciones web no obtienen un archivo *. * Proj de manera predeterminada, así que tuve grandes dificultades para encontrar la manera de conseguir que MSBuild se ejecute en el mío para crear un script de implementación.
  • NAnt no está incorporado en Visual Studio y debe agregarse, ya sea con un complemento o como una "herramienta externa". Esto es un poco difícil de configurar.
  • (Editar :) Uno de mis compañeros de trabajo lo mencionó: si desea configurar una máquina de compilación usando CruiseControl para una integración continua, CruiseControl se integra con NAnt muy bien. ACTUALIZACIÓN: CruiseControl también tiene una tarea MSBuild .
  • Por favor, consulte los comentarios a continuación para una discusión completa y actualizada de las diferencias subjetivas.

La documentación y los tutoriales disponibles para NAnt hacen que sea más fácil comenzar a aprender a construir scripts con NAnt. Una vez que entendí NAnt y creé scripts de compilación comencé a traducir ese conocimiento a MSBuild (hice X en NAnt, ¿cómo hago X en MSBuild?). La documentación de Microsoft generalmente asume un nivel bastante alto de conocimiento antes de que sea útil.

La razón para cambiar de NAnt a MSBuild es porque MSBuild es más actual. Lamentablemente, el último lanzamiento de NAnt fue el 8 de diciembre de 2007, mientras que MSBuild 4.0 (.NET 4.0) no está lejos. Parece que el proyecto NAnt ha muerto.

Si encuentra buena documentación para alguien que recién comienza a aprender a crear scripts de construcción usando MSBuild, salte NAnt y vaya directamente a MSBuild. Si NAnt alguna vez sale con un nuevo lanzamiento, entonces consideraría seguir con NAnt, pero ahora están rezagados.

Pasé de NAnt a MSBuild recientemente debido a su capacidad para crear soluciones de VS. Todavía uso NAnt ocasionalmente, sin embargo.

También es posible que desee comprobar MsBuildTasks que es como NAntContrib.

Personalmente, uso ambos, para el mismo proyecto.

MSBuild es excelente para crear soluciones y proyectos de Visual Studio, para eso está hecho.

NAnt es más fácilmente editable a mano, en mi opinión, especialmente si ya conoces a Ant. NAnt puede llamar a MSBuild muy fácilmente con NAntContrib. Por lo tanto, hago un script NAnt a mano para hacer cosas como copiar archivos construidos, limpiar, etc. y llamo a MSBuild para que haga la parte real "convertir mi código fuente C # en ensamblajes".

Si quieres un ejemplo de eso, mira mi archivo de compilación Protocol Buffers . (No diría que es un script NAnt fabuloso, pero cumple su función).

Terminé usando ambos. Al rediseñar nuestro sistema de compilación, me enfrentaba a un problema complejo. A saber, no pude deshacerme de .vcproj (y su familia) porque todos estábamos usando VS para actualizar los archivos, configuraciones y configuraciones del proyecto. Entonces, sin un gran proceso de duplicación y propensión a errores, no podríamos basar nuestro sistema de compilación en un nuevo conjunto de archivos.

Por este motivo, decidí conservar los archivos ''proj'' de VS y usar MSBuild (son archivos de MSBuild, al menos VS2005 y VS2008 usan archivos de proyecto de MSBuild). Para todo lo demás (configuración personalizada, pruebas unitarias, empaquetado, preparación de documentación ...) utilicé NAnt.

Para una integración continua, utilicé CruiseControl. Así que teníamos scripts CC que activaban trabajos NAnt, que para construir usaban MSBuild.

Una nota final: ¡MSBuild NO es compatible con los proyectos de configuración! Por lo tanto, tiene problemas para llamar a DevEnv.com o usar Visual Studio directamente. Eso es lo que terminé haciendo, pero deshabilité el proyecto de configuración de forma predeterminada de todas las configuraciones de solución, ya que los desarrolladores normalmente no necesitarían construirlas, y si lo hacen, pueden seleccionarlas manualmente para compilarlas.

Una cosa que noté es que varios carteles mencionaron tener que editar manualmente los archivos .csproj (o .vbproj, etc.).

MSBuild permite la personalización de estos archivos * .proj mediante el uso de archivos .user. Si tengo un proyecto llamado MyCreativelyNamedProject.csproj y quiero personalizar las tareas de MSBuild dentro de él, puedo crear un archivo llamado MyCreativelyNamedProject.csproj.user y usar CustomBeforeMicrosoftCommonTargets y CustomAfterMicrosoftCommonTargets para personalizar esos archivos.

Además, tanto NAnt como MSBuild se pueden personalizar al contenido del corazón a través de tareas personalizadas de MSBuild y mediante extensiones de NantContrib.

Entonces, usar NAnt o MSBuild realmente se reduce a la familiaridad:

  • Si ya está familiarizado con Ant, use NAnt. La curva de aprendizaje será muy fácil.
  • Si no está familiarizado con ninguna de las herramientas, MSBuild ya está integrado con Visual Studio y no requiere herramientas adicionales.

También vale la pena agregar que MSBuild está prácticamente garantizado para funcionar con todas las versiones nuevas de .NET y Visual Studio tan pronto como se publiquen, mientras que NAnt puede tener cierto retraso.

Uno de los mayores atractivos de MSBuild para mí (en plataformas Windows) es que viene como parte de .NET. Eso significa que cualquier máquina de Windows que esté actualizada con Windows Update tendrá MSBuild disponible. Agregue a esto el hecho de que el compilador C # también es parte de .NET y tiene una plataforma que puede construir proyectos en máquinas limpias. No es necesario instalar el gigante de Visual Studio. NAnt, por otro lado, tiene que estar explícitamente instalado antes de que se pueda activar una compilación.

Solo para el registro, he usado NMake, Make, Ant, Rake, NAnt y MSBuild en versiones no triviales en el pasado (en ese orden). Mi favorito es MSBuild, sin dudas (y no me gusta porque "eso es lo que Visual Studio usa"). En mi humilde opinión, es una herramienta de construcción muy poco apreciada.

Compararía NAnt vs. MSBuild con la diferencia entre la programación de procedimiento y la funcional. NAnt es bastante directo y tú-obtienes lo que ves. MSBuild, por otro lado, requiere un poco más de reflexión. La curva de aprendizaje es más pronunciada. Pero una vez que "lo entiendes", puedes hacer cosas increíbles con él.

Así que recomendaría mirar MSBuild si también gravitan hacia la programación de estilo funcional o lógico, si está dispuesto a invertir un poco de tiempo y esfuerzo antes de ver resultados tangibles (por supuesto, también creo firmemente que la inversión finalmente rinde frutos y usted puede hacer cosas más poderosas de manera más eficiente).

Usamos FlubuCore. Es una biblioteca de código abierto C # para crear proyectos y ejecutar scripts de despliegue usando el código C #.

Ejemplo simple de cómo se usa flubu:

protected override void ConfigureTargets(ITaskContext session) { var compile = session.CreateTarget("compile") .SetDescription("Compiles the solution.") .AddTask(x => x.CompileSolutionTask()) .DependsOn("generate.commonassinfo"); }

Puede encontrar más información sobre flubu y cómo comenzar aquí: choice-for-build-tool-msbuild-nant-or-something-else

Utilizo ambos en que mis scripts NAnt llaman a MSBuild. Mi razón principal para quedarme con NAnt es el aislamiento . Déjame explicar por qué siento que esto es importante:

  1. Agregar dependencias a su proyecto. El archivo de compilación NAnt es ajeno a Visual Studio (en mi caso, lo considero un profesional), por lo que Visual Studio no intenta hacer nada con él. Las tareas de MSBuild están integradas así que forman parte de la solución y pueden referirse a otras tareas de MSBuild. Recibí el código fuente de otra persona solo para descubrir que no pude compilar, porque las tareas de la comunidad MSBuild no estaban instaladas. Lo que encuentro particularmente frustrante es que Visual Studio simplemente no compila y arrojó un montón de errores que me hicieron perder tiempo de depuración. Esto, a pesar de que la compilación que se solicita podría haber seguido adelante (como una compilación de depuración, por ejemplo) sin algunos de los extras de la tarea MSBuild. En resumen: no me gusta agregar dependencias a mi proyecto si puedo evitarlo .

  2. No confío en Visual Studio por lo que pude arrojar a su equipo de desarrollo. Esto se remonta a los primeros días de Visual Studio cuando masacraba mi HTML. Todavía no uso el diseñador, por ejemplo (en una conferencia recientemente descubrí que mis colegas hicieron lo mismo). He descubierto que Visual Studio puede arruinar las dependencias y los números de versión en el archivo DLL (no puedo replicar esto, pero sucedió en un proyecto de manera consistente y causó mucho dolor y tiempo perdido). He recurrido a un procedimiento de compilación que usa Visual Studio para crear solo el modo de depuración. Para producción, utilizo NAnt para controlar todo externamente . Visual Studio simplemente no puede interferir más si compilo usando NAnt.

PD: soy un desarrollador web y no desarrollo Windows Forms.

KISS = Usar MSBuild.

¿Por qué agregar algo más a la mezcla cuando tienes algo que hará un trabajo razonable desde el primer momento? Cuando llegó MSBuild, NAnt murió. Y Mono tendrá una implementación de MSBuild, ( xbuild ).

DRY = Usar MSBuild.

Pregúntese qué desea de un sistema de construcción? Quiero un sistema de compilación que también use mi IDE lugar de mantener dos configuraciones diferentes.

Personalmente, me encantaría escuchar algunos argumentos reales para NAnt, porque simplemente no puedo pensar en ninguno que realmente contenga agua.

YDeliver by Manoj es un marco de construcción construido sobre PSake. Tiene un amplio conjunto de funciones de biblioteca, capacidad para definir flujos de trabajo, y lo hemos utilizado para entregar más de seis proyectos empresariales a la producción.

Úselo junto con TeamCity , CruiseControl o cualquier otra cosa que pueda ejecutar PowerShell .

NAnt tiene más funciones listas para usar , pero MSBuild tiene una estructura fundamental mucho mejor (rocas de metadatos de elementos) lo que hace que sea mucho más fácil construir scripts de MSBuild reutilizables.

MSBuild toma un tiempo para entender, pero una vez que lo haces es muy agradable.

Aprendiendo materiales:

Usamos ambos. NAnt es responsable de todo lo relacionado con los "scripts", como copiar, implementar en IIS , crear paquetes y MSBuild es responsable de desarrollar la solución. Entonces podemos evitar problemas con .NET 4.0 no soportado por una nueva versión de NAnt.

NAnt también es más escalable. Si queremos migrar las secuencias de comandos de implementación a los servidores de producción, solo copiamos el archivo de construcción e instalamos una versión adecuada de .NET, no hay problemas de Visual Studio con los archivos de csproj :)