Soy consciente de que hay otras preguntas relacionadas con NAnt y MSBuild sobre Stack Overflow, pero no pude encontrar una comparación directa entre las dos y aquí está 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 alguno de los dos?
Respuestas:
He hecho una investigación similar esta semana. Esto es lo que he podido determinar:
NAnt:
MSBuild:
Diferencias subjetivas: (YMMV)
Uno de los principales atractivos de MSBuild para mí (en plataformas Windows) es que viene como parte de .NET. Eso significa que cualquier máquina con Windows que esté actualizada con Windows Update tendrá MSBuild disponible. Agregue a esto el hecho de que el compilador de C # también es parte de .NET y tiene una plataforma que puede construir proyectos en máquinas limpias. No es necesario instalar Visual Studio behemoth. NAnt, por otro lado, debe instalarse explícitamente antes de que se pueda activar una compilación.
Solo para el registro, he usado NMake, Make, Ant, Rake, NAnt y MSBuild en compilaciones no triviales en el pasado (en ese orden). Mi favorito es MSBuild, sin dudas (y no lo favorezco porque "eso es lo que usa Visual Studio"). En mi humilde opinión, es una herramienta de construcción muy poco apreciada.
Yo compararía NAnt vs. MSBuild con la diferencia entre programación funcional y de procedimiento. NAnt es bastante sencillo y 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 algunas cosas increíbles con él.
Por lo tanto, recomendaría mirar MSBuild si también gravita hacia una 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 vale la pena y usted puede hacer cosas más poderosas de manera más eficiente).
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ácil de editar 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, creo a mano un script NAnt para hacer cosas como copiar archivos construidos, limpiar, etc., y llamar a MSBuild para hacer la parte real de "convertir mi código fuente C # en ensamblajes".
Si quieres un ejemplo de eso, mira mi archivo de compilación de Protocol Buffers . (No diría que es un fabuloso script de NAnt, pero hace el trabajo).
NAnt tiene más funciones listas para usar , pero MSBuild tiene una estructura fundamental mucho mejor (rocas de metadatos de elementos) que hace que sea mucho más fácil construir scripts de MSBuild reutilizables.
MSBuild tarda un tiempo en comprenderlo, pero una vez que lo hace, es muy agradable.
Aprendiendo materiales:
BESO = Usar MSBuild.
¿Por qué agregar algo más a la mezcla cuando tienes algo que hará un trabajo razonable fuera de la caja? Cuando llegó MSBuild, NAnt murió. Y Mono tendrá una implementación de MSBuild, ( xbuild ).
DRY = Usar MSBuild.
Pregúntese qué quiere de un sistema de compilación. Quiero un sistema de compilación que también use mi IDE en lugar de mantener dos configuraciones diferentes.
Personalmente, me encantaría escuchar algunos argumentos reales para NAnt, porque no puedo pensar en ninguno que realmente aguante.
Una cosa que noté que mencionan varios carteles fue 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:
También vale la pena agregar que MSBuild está prácticamente garantizado para trabajar con todas las versiones nuevas de .NET y Visual Studio tan pronto como se publiquen, mientras que NAnt puede tener algún retraso.
Utilizo ambos en que mis scripts NAnt llaman a MSBuild. Mi razón principal para quedarme con NAnt es el aislamiento . Déjame explicarte por qué siento que esto es importante:
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, por lo que son 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 podía compilar, porque las tareas de la comunidad MSBuild no estaban instaladas. Lo que encuentro particularmente frustrante es que Visual Studio simplemente no se construyó y arrojó un montón de errores que me hicieron perder tiempo depurando. Esto, a pesar del hecho de que la compilación solicitada 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 .
No confío en Visual Studio por lo que pude lanzar a su equipo de desarrollo. Esto se remonta a los primeros días de Visual Studio cuando masacraría mi HTML. Todavía no uso el diseñador, por ejemplo (en una conferencia recientemente encontré 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 compilar solo en modo de depuración. Para la producción, uso NAnt para controlar todo externamente . Visual Studio simplemente no puede interferir más si construyo usando NAnt.
PD: Soy desarrollador web y no desarrollo Windows Forms.
Si bien 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 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 Nant, así que supongo que no es demasiado común mezclar y combinar los dos.
Más allá de eso, supongo que será una cuestión de preferencia personal: obviamente, puede administrar algunas / la mayoría de las funciones de MsBuild desde Visual Studio, si eso es lo que le gusta. Nant parece más flexible y más adecuado si prefieres escribir scripts a mano, y si vienes del mundo Java es probable que estés en casa con él.
Terminé usando ambos. Al rediseñar nuestro sistema de compilación, me enfrentaba a un problema complicado. Es decir, no podía deshacerme de .vcproj (y 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 esta razón, decidí mantener los archivos 'proj' de VS y usar MSBuild (son archivos MSBuild, al menos VS2005 y VS2008 usan archivos de proyecto 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 de NAnt, que para la construcción usaban MSBuild.
Una nota final: ¡MSBuild NO admite proyectos de instalación! Así que estás atrapado en llamar a DevEnv.com o usar Visual Studio directamente. Eso es lo que terminé haciendo, pero desactivé el proyecto de configuración de forma predeterminada en todas las configuraciones de soluciones, ya que los desarrolladores normalmente no necesitarían compilarlas, y si lo hacen, pueden seleccionar manualmente para compilarlas.
Recientemente me cambié de NAnt a MSBuild debido a su capacidad para crear soluciones VS. Sin embargo, todavía uso NAnt ocasionalmente.
También puede consultar las tareas de la comunidad MSBuild, que es como NAntContrib.
La documentación y los tutoriales disponibles para NAnt hacen que sea más fácil comenzar a aprender scripts de compilación con NAnt. Una vez que aprendí 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 supone 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, la última versión 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 compilación utilizando MSBuild, omita 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.
Usamos ambos NAnt es responsable de todas las cosas de "secuencias de comandos", como copiar, implementar en IIS , crear paquetes y MSBuild es responsable de crear la solución. Entonces podemos evitar problemas con .NET 4.0 no compatible con una nueva versión de NAnt.
NAnt también es más escalable. Si queremos migrar los scripts de implementación a los servidores de producción, solo copiamos el archivo de compilación e instalamos una versión adecuada de .NET, sin problemas de Visual Studio con archivos csproj :)
YDeliver by Manoj es un marco de compilació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 producción.
Úselo junto con TeamCity , CruiseControl o cualquier cosa que pueda ejecutar PowerShell .
Usamos FlubuCore. Es una biblioteca C # de código abierto para construir proyectos y ejecutar scripts de implementación utilizando 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