¿Debo cambiar de nant a msbuild?

StackOverflow https://stackoverflow.com/questions/10634

Pregunta

Actualmente uso nant, ccnet (control de crucero), svn, mbunit.Utilizo msbuild para hacer mi compilación sln solo porque era más sencillo desembolsar.

¿Tiene algún mérito cambiar todo mi script de compilación a MSBuild?Necesito poder ejecutar pruebas, pruebas de estilo Watir, implementación de xcopy.¿Es esto más fácil?

Actualizar:¿Alguna característica atractiva que me haga cambiar de nant a msbuild?

¿Fue útil?

Solución

Me gusta MSBuild.Una razón es que los archivos .csproj son archivos msbuild y compilar en VS es como compilar en la línea de comando.Otra razón es el buen soporte de TeamCity, que es el servidor CI que he estado usando.Si comienza a usar MSBuild y desea hacer más cosas personalizadas en su proceso de compilación, obtenga el Tareas de la comunidad de MSBuild.Te dan un montón de agradables tareas adicionales.No he usado NAnt desde hace varios años y no me arrepiento.

Además, como menciona Rubén, están los Tareas de la COSUDE tareas en CodePlex.

Para divertirse aún más, existe el Paquete de extensión MSBuild en CodePlex, que incluye una tarea de Twitter.

Otros consejos

Mi consejo es todo lo contrario: evite MSBuild como la plaga.NANT es mucho más fácil de configurar para realizar pruebas automáticas, implementar en múltiples entornos de producción, integrar con control de crucero para un entorno de entrada e integrar con control de fuente.Hemos pasado por mucho dolor con TFS/MSBuild (usando TFSDeployer, scripts de PowerShell personalizados, etc.) para lograr que haga lo que pudimos hacer con NANT listo para usar.No pierdas el tiempo.

La razón más convincente para usar MSBuild (al menos en .NET 3.5 y posteriores): el motor de compilación se puede compilar simultáneamente.

Esto significa una gran aceleración en sus compilaciones si tiene múltiples núcleos/procesadores.

Antes de la versión 3.5, MSBuild no realizaba compilaciones paralelas.

Siento que MSBuild y Nant son bastante comparables.Si está utilizando uno de estos, generalmente no cambiaría entre ellos a menos que faltara una característica atractiva en el producto que había seleccionado.

Yo personalmente uso MSBuild para cualquier proyecto nuevo, pero su kilometraje puede variar.

¡Espero que ayude!

Editar: @ChanChan: @Jon menciona que Nant no crea aplicaciones .NET 3.5.Esta puede ser una razón suficiente para cambiarlos o al menos usarlos en paralelo.A medida que me acerco más a MSBuild, probablemente no sea la persona más informada para destacar otros aspectos destacados de cualquiera de estas tecnologías.

Editar: Parece que Nant ahora crea aplicaciones .NET 3.5.

NAnt existe desde hace más tiempo y es un producto considerablemente más maduro y, en mi opinión, más fácil de usar.Existe una gran cantidad de conocimientos de la comunidad que puede aprovechar y también es multiplataforma, en caso de que esté interesado en crear aplicaciones que puedan ejecutarse en Mono, así como en .NET y Silverlight.Desde el primer momento, hace mucho más que MSBuild.Ah, sí, y puedes llamar a MSBuild desde NAnt (OK, desde NAntContrib) :-)

En el lado negativo, NAnt y su proyecto hermano NAntContrib parecen haberse estancado, siendo la actualización más reciente a finales de 2007.

Las principales ventajas que veo de MSBuild es que viene con .NET Framework, por lo que es un producto menos que instalar;y se está produciendo un desarrollo más activo (aunque en algunos lugares para alcanzar a la antigua NAnt).

Personalmente, encuentro su sintaxis un poco más difícil de aprender, pero estoy seguro de que la exposición continua a ti facilitaría las cosas.

¿Conclusión?Si está trabajando con scripts NAnt existentes, quédese con ellos, no vale la pena trasladarlos.Si está comenzando un nuevo proyecto y se siente aventurero, pruebe MSBuild.

También cambiamos de nant a msbuild.Si su compilación es bastante estándar, entonces no tendrá muchos problemas para configurarla, pero si tiene muchas tareas de compilación específicas, tendrá que escribir tareas de compilación de ms personalizadas, ya que hay muchas menos tareas personalizadas para msbuild.

Si desea mostrar resultados de compilación razonables, tendrá que utilizar registradores personalizados, etc.Toda la estructura del equipo no está tan madura como lo está Nant.

Pero el beneficio real es la integración con los servicios de generación de informes y control de fuente de TFS.Si no utiliza TFS como sistema de control de fuente, no vale la pena.

  • No cambies a menos que tengas una razón muy convincente (al menos).
  • NAnt es de código abierto y si no lo fuera no podría personalizar nuestro sistema de compilación, MSBuild no lo es.
  • NAnt puede ejecutar MSBuild fácilmente, no estoy seguro de lo contrario.
  • Los scripts de MSBuild ya están escritos para usted si usa VS2005 o una versión más reciente (los archivos del proyecto son archivos MSBuild.)
  • Si usa NAnt y usa VS para editar archivos, ajustes y configuraciones del proyecto, tendrá que escribir una herramienta de conversión/sincronización para actualizar sus archivos NAnt desde los archivos del Proyecto VS.

@Brad Leach

Por lo general, no cambiaría entre ellos a menos que faltara una característica atractiva.

¿Cuáles son las razones de peso para utilizar msbuild?¿Hay desventajas?

Hasta ahora estoy obteniendo un "no, no te molestes" bastante bueno con tu respuesta.

Creo que son relativamente comparables tanto en características como en facilidad de uso.Simplemente por estar basado en C#, encuentro que es más fácil trabajar con msbuild que con nants, aunque esa no es una razón convincente para cambiar.

¿Qué es exactamente lo que Nant no hace por ti?¿O simplemente esperas que haya alguna característica interesante que te estés perdiendo?:)

Una cosa muy buena de C# es que si tienes .net framework, tienes todo lo que necesitas para ejecutar msbuild.Esto es fantástico cuando trabajas en grandes equipos/proyectos y tienes rotación de personal/hardware.

Personalmente prefiero SCons a ambos :)

La razón principal por la que sigo usando nAnt en lugar de msbuild para mis compilaciones automatizadas es que tengo un control más granular sobre mis compilaciones.Debido a que msbuild usa csproj tiene su archivo de compilación, todo el código fuente de ese proyecto se compila en un solo ensamblaje.Lo que hace que tenga muchos proyectos en mi solución para proyectos grandes en los que separo la lógica.Bueno, con nant, puedo organizar mi compilación de manera que pueda compilar lo que quiero en múltiples ensamblajes de un proyecto.

Me gusta esta ruta porque me evita tener muchos archivos de proyecto en mi solución.Puedo tener un proyecto con carpetas que dividen las capas y luego usar nant para construir cada capa en su propio ensamblaje.

Sin embargo, uso nant y msbuild juntos para algunas tareas de compilación, como la creación de aplicaciones WPF.Es mucho más fácil compilar una aplicación WPF con el objetivo msbuild dentro de nant.

Para terminar con esto y el punto de mi respuesta es que me gusta usarlos uno al lado del otro, pero cuando uso msbuild en esta configuración, generalmente es para compilar directamente, sin realizar ninguna tarea de automatización de compilación como copiar archivos a un directorio, generar la documentación de ayuda o ejecutar mis pruebas unitarias, por ejemplo.

De hecho, todavía estoy tratando de resolver esta pregunta por mí mismo, pero aquí hay una gran ventaja para MSBuild:usar el mismo archivo de compilación para la integración continua local llamando a msbuild.exe directamente, y al mismo tiempo poder usar la integración continua del lado del servidor de VSTS con el mismo archivo de compilación (aunque probablemente con propiedades/configuraciones diferentes).

es decir.en comparación con el soporte de TeamCity para scripts de MSBuild, VSTS solo ¡Admite scripts de MSBuild!He solucionado esto en el pasado ejecutando NAnt desde MSBuild;He visto a otros recomendar esta práctica y también lo contrario, pero a mí me parece una torpeza, así que trato de no hacerlo si puedo evitarlo.Por lo tanto, cuando utilice "la pila completa de Microsoft" (VSTS y TFS), le sugiero que se quede con los scripts de MSBuild.

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

MSBuild tarda un poco en entenderse, pero una vez que lo haces, es muy bueno.

Aprendiendo materiales:

No veo ninguna razón para cambiar.MsBuild mismo lo bloquea en el marco que está utilizando.Si usa NAnt, puede usarlo en muchos marcos y pagarle a msbuild para que realice la tarea de construcción por usted.

Soy fanático de NAnt en este sentido porque te desacopla un poco del marco.

Creé un marco que incluye convenciones en compilaciones automatizadas y lo construí en NAnt.Se llama UppercuT y es increíblemente fácil de usar Build Framework.

¡Compilaciones automatizadas tan fáciles como (1) nombre de la solución, (2) ruta de control de fuente, (3) nombre de la empresa para la mayoría de los proyectos!

http://code.google.com/p/uppercut/

Algunas buenas explicaciones aquí: Uppercut

La integración de MSBuild con Visual Studio brinda a los programadores menos fricción para usar el sistema de compilación.Básicamente, todo se reduce a que solo tienen que ir a "Crear solución" y todo funciona, en lugar de tener que usar pasos de compilación personalizados y otras cosas similares, o, peor aún, obligar a los desarrolladores a compilar iniciando algún tipo de script externo.

Ahora, tiendo a preferir MSBuild a NAnt porque es más simple.Claro, NAnt tiene muchas más funciones, es más potente, etc., pero puede salirse de control rápidamente.Si usted y sus ingenieros de compilación tienen la disciplina para mantener simples los scripts NAnt, entonces todo está bien.Sin embargo, he visto demasiados sistemas basados ​​en NAnt llegar al punto en el que ya nadie entiende lo que está haciendo, y no hay una forma real de depurarlo además de hacer el equivalente a un buen printf.En el momento en que comienzas a usar alguna declaración if/else o un bucle for, ahí es donde, en mi humilde opinión, comienza a oler mal.

Por otro lado, MSBuild tiene una base sólida basada en metadatos y una sintaxis menos detallada.Su simplicidad (o falta de características...dependiendo de cómo lo vea) le obliga a escribir lógica en código .NET mediante nuevas tareas, en lugar de escribir lógica en formato XML.Esto fomenta la reutilización y, sobre todo, le permite depurar su sistema de compilación en un depurador real.

El único problema con MSBuild es el error no tan ocasional (especialmente en la primera versión) o el comportamiento oscuro (aunque documentado).Y si ese es el tipo de cosas que realmente te molestan, estar vinculado a Microsoft.

Cambié de NANT a MSBuild.El proyecto se ejecuta en .Net 4.0.

Mi experiencia en Nant fue buena.El proyecto murió.Y cuando apareció .Net 4.0, llegó el momento de reevaluar el proceso de construcción.

Desde que se lanzó Nant por última vez, MSBuild ha avanzado mucho.En este punto, MSBuild es el camino a seguir.Es fácil de usar, tiene muchas extensiones.Reescribí mis guiones de Nant en un día y medio.El script de MSBuild tiene 1/3 del tamaño de los scripts de Nant.

Gran parte del trabajo en el guión de Nant consistió en configurar los diferentes entornos.En MsBuild/.Net 4.0 está integrado.

yo uso MSBuild junto a Nant, porque la versión actual de Nant aún no puede compilar aplicaciones .NET 3.5 (lo mismo ocurrió cuando apareció .NET 2.0 por primera vez).

La única razón que veo para usar msbuild es si desea utilizar un servidor de compilación automatizado como el control de crucero.Si no vas a cambiar, lo dejaría así.

Yo uso Nant y me encanta.Usé MSBuild y lo odié por estos:

  1. Microsoft te obliga a seguir su propio procedimiento de compilación que es tan intrínseco a sus acciones que al menos yo no pude hacerlo funcionar (tuve que compilar NET1.1, así que tuve que mezclar Nant y MSbuild).Sé que puedes crear tu propio archivo MSBuild, pero pensé que era complejo de entender y mantener.

  2. Los tipos de elementos para realizar operaciones con archivos son demasiado difíciles de seguir.Puede hacer que Nant haga exactamente lo mismo y sea mucho más fácil y directo (tuve que crear una lista de ItemType y luego pasar a las operaciones de archivo).

  3. En MsBuild tienes que crear tu propia dll de tarea, en Nant puedes hacer esto o puedes incrustar código C# dentro de tu script, por lo que es mucho más fácil avanzar y simplemente construir todo el proyecto.

  4. Nant funciona con Net1.1, MsBuild no.

  5. Para instalar nant, incluso puedo descomprimirlo y ubicarlo dentro de mi propio repositorio para ejecutarlo.Instalar MsBuild es mucho más difícil ya que depende de muchas cosas de Visual Studio, etc.(tal vez me equivoque aquí, pero esa parece ser la verdad).

Bueno estas son mis opiniones...

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top