Actualmente uso nant, ccnet (control de crucero), svn, mbunit. Yo uso msbuild para hacer mi construcción sln solo porque era más simple de pagar.¿Debo cambiar de nant a msbuild?
¿Hay algún fundamento para cambiar mi script de compilación completo a MSBuild? Necesito poder ejecutar pruebas, pruebas de estilo watir, implementación de xcopy. ¿Es esto más fácil?
Actualización: ¿Alguna característica convincente que me haga cambiar de nant a msbuild?
me gusta MSBuild. Una razón es que los archivos .csproj son archivos de msbuild, y construir en VS es como construir en la línea de comando.Otra razón es la buena asistencia de TeamCity, que es el servidor de 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 MSBuild Community Tasks. Te dan un montón de bonitas tareas adicionales. No he usado NAnt desde hace varios años, y no me he arrepentido.
Además, como menciona Ruben, están las tareas SDC Tasks en CodePlex.
Para aún más diversión, está el MSBuild Extension Pack on CodePlex, que incluye una tarea de twitter.
También están las tareas de SDC. Y el libro de Hashimi. –
Siento que MSBuild y Nant son bastante comparables. Si está utilizando uno de estos, generalmente no cambiaría entre ellos a menos que hubiera una característica convincente que faltaba 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. Esto puede ser razón suficiente para cambiar, o al menos usarlos en paralelo. Como me he movido más hacia MSBuild, probablemente no soy la persona más informada para destacar cualquier otro showtoppers con cualquiera de las tecnologías.
Editar: Parece que Nant ahora construye aplicaciones .NET 3.5.
NANT crea aplicaciones .net 3.5 ahora. –
@Brad Leach
por lo general no cambiarían entre ellos a menos que hubiera una característica atractiva que faltaba
¿cuáles son las razones de peso para utilizar msbuild? ¿Hay contras?
Hasta ahora estoy obteniendo una muy buena, "no te molestes" de tu respuesta.
Utilizo MSBuild junto con Nant, porque la versión actual de Nant aún no puede compilar aplicaciones .NET 3.5 (lo mismo ocurrió cuando salió .NET 2.0 por primera vez).
La única razón que puedo ver para usar msbuild es si desea utilizar un servidor de compilación automático como el control de crucero. Si no vas a cambiar, entonces lo dejaría en paz.
cruisecontrol.net tiene tareas para nant y msbuild fuera de la caja –
Creo que son relativamente comparables tanto en características como en facilidad de uso. Solo por estar basado en C#, me resulta 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 está haciendo por usted? ¿O solo esperas que haya alguna característica interesante que te puedas perder? :)
Una cosa súper 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 personas/hardware.
personalmente prefiero SCons sobre ambos :)
NAnt escrito en C# –
El motivo más convincente para utilizar MSBuild (al menos en .NET 3.5 y versiones posteriores): el motor de compilación puede compilar al mismo tiempo.
Esto significa una gran velocidad en sus compilaciones ya que tiene múltiples núcleos/procesadores.
Anterior a 3.5, MSBuild no hacía construcciones paralelas.
Mi consejo es todo lo contrario: evitar MSBuild como la peste. NANT es mucho más fácil de configurar para construir para realizar pruebas automáticas, implementar en múltiples entornos de producción, integrarse con cruisecontrol para un entorno de entrada, integrarse con el control de origen. Hemos sufrido tanto con TFS/MSBuild (utilizando TFSDeployer, secuencias de comandos de PowerShell personalizadas, etc.) para lograr que haga lo que pudimos hacer con NANT de fábrica. No pierdas tu tiempo.
+1 MSBuild tiene su lugar, pero NAnt es mucho más poderoso. No he encontrado una razón convincente para cambiar, especialmente cuando existe una tarea
He usado ambos extensivamente, mientras que me gusta la forma en que Microsoft ha copiado básicamente NAnt, MSBuild es más fácil de desarrollar tareas personalizadas, y si combina MSBuild Community Tasks con MSBuild Extension Pack, entonces tiene una amplia gama de herramientas. MSBuild gana porque está integrado en proyectos de MS. – si618
Si, estás equivocado. 1) CustomTasks en NANT tan simple como sea posible - una subclase de la Tarea 2) NANT tiene NANTContrib así como mucho más apoyo de la comunidad que MSBuild 3) Integro NANT en mis proyectos MS escribiendo un archivo por lotes para ejecutar NANT .exe. Esto es una construcción, no una cirugía de cohete. – Jim
La razón principal por la que todavía uso nAnt sobre msbuild para mis compilaciones automáticas es que tengo un control más granular en mis compilaciones. Debido a que msbuild usa csproj como archivo de compilación, todas las fuentes de ese proyecto se compilan en un ensamblaje. Lo que me lleva a tener muchos proyectos en mi solución para proyectos grandes donde estoy separando la lógica. Bueno, con nant, puedo organizar mi compilación donde puedo compilar lo que quiero en múltiples ensambles de un proyecto.
Me gusta esta ruta porque me impide tener muchos archivos de proyectos en mi solución. Puedo tener un proyecto con carpetas dividiendo las capas y luego usar nant para construir cada capa en su propio ensamblaje.
Sin embargo, utilizo tanto nant como msbuild conjuntamente para algunas tareas de compilación, como crear aplicaciones WPF. Es mucho más fácil compilar una aplicación WPF con el objetivo msbuild dentro de nant.
Para terminar 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 compilación directa, sin realizar ninguna tarea de automatización de compilación como copiar archivos a un directorio, generando la documentación de ayuda o ejecutando las pruebas de mi unidad, por ejemplo.
puede configurar msbuild para producir ensamblajes separados en el mismo proyecto. Por defecto, eso no es lo que VS2008 hace, pero no es difícil de hacer. – Cheeso
estas cosas son fácilmente realizables con msbuild. –
Todavía estoy tratando de resolver esta pregunta yo mismo, pero hay una gran ventaja para MSBuild aquí: usar el mismo archivo de compilación para la integración continua local llamando directamente a msbuild.exe, mientras que también se puede usar VSTS's integración continua del lado del servidor con el mismo archivo de compilación (aunque muy probablemente diferentes propiedades/configuraciones).
es decir, en comparación con el apoyo de TeamCity para los scripts de MSBuild, VSTS única soporta scripts de MSBuild! He pirateado esto en el pasado al ejecutar NAnt de MSBuild; He visto a otros recomendar esta práctica, así como la inversa, pero me parece tonta, así que trato de no hacerlo si puedo evitarlo. Por lo tanto, cuando utilizas "la pila completa de Microsoft" (VSTS y TFS), te sugiero que solo sigas con los scripts de MSBuild.
También cambiamos de nant a msbuild.Si su compilación es bastante estándar, no tendrá muchos problemas para configurarla, pero si tiene muchas tareas de compilación específicas, tendrá que escribir tareas personalizadas de compilación de ms, ya que hay mucho menos tareas personalizadas para msbuild.
Si desea mostrar resultados de construcción razonables, tendrá que meterse con los registradores personalizados, etc. La construcción del equipo completo no está tan madura como lo es nant.
Pero el beneficio real es la integración con los servicios de informes y control de fuente TFS. Si no está utilizando TFS como su sistema de control de origen, no lo vale.
NAnt ha existido por más tiempo, y es un producto considerablemente más maduro, y también más fácil de usar. Hay un montón de conocimiento de la comunidad para aprovechar, y también es multiplataforma, en caso de que esté interesado en crear aplicaciones que puedan ejecutarse tanto en Mono como en .NET y Silverlight. Fuera de la caja, hace mucho más de lo que hace MSBuild. Oh, sí, y se le puede llamar MSBuild de Nant (OK, desde NAntContrib) :-)
En el lado negativo, de NAnt y su proyecto hermano NAntContrib parecen haberse estancado, con la actualización más reciente de las cuales finales de 2007.
Las principales ventajas que veo de MSBuild es que se incluye con .NET Framework, por lo que es un producto menos para instalar; y hay un desarrollo más activo (aunque en lugares para alcanzar al NAnt más viejo).
Personalmente, creo que su sintaxis es un poco más difícil de recoger, pero estoy seguro de que la exposición continuada a TI facilitaría las cosas.
Conclusión? Si está trabajando con scripts existentes de NAnt, quédese con ellos, no vale la pena la molestia de portarlos. Si estás comenzando un nuevo proyecto y te sientes aventurero, dale una oportunidad a MSBuild.
Nant tiene más características de la caja, pero MSBuild tiene una estructura mucho mejor fundamental (rocas elemento de metadatos), que hace que sea mucho más fácil de construir secuencias de comandos de MSBuild reutilizables.
MSBuild toma un tiempo para entender, pero una vez que lo haces es muy agradable.
materiales de aprendizaje:
el argumento más convincente que he escuchado para msbuild es clickonce. Sin embargo, considero que el clickonce es fundamentalmente problemático, así que lo evito y lo uso como un buen argumento contra msbuild. – DevelopingChris
¿Por qué ClickOnce sería problomático (no es que yo esté de acuerdo con eso) tenga alguna relación con MSBuild? –
No veo ningún motivo para cambiar. MsBuild en sí mismo te encierra en el marco que estás usando. Si usa NAnt, puede usarlo en muchos frameworks y pagar a msbuild para que realmente haga la tarea de construir para usted.
Soy un fanático de NAnt en este sentido, porque te desacopla del marco un poco.
He creado un marco que pone las convenciones en versiones automatizadas y lo construí en NAnt. Se llama UppercuT y es increíblemente fácil de usar Build Framework.
Automatizado Se compila tan fácil como (1) nombre de la solución, (2) ruta de control de origen, (3) nombre de la compañía para la mayoría de los proyectos.
http://code.google.com/p/uppercut/
Algunas buenas explicaciones aquí: UppercuT
MSBuild está integrado con Visual Studio proporciona a los programadores menos fricción a utilizar el sistema de construcción. Básicamente se trata solo de tener que ir a "Build Solution" y todo funciona, en lugar de tener que usar Custom Build Steps y otras cosas similares, o, lo que es peor, forzar a los desarrolladores a crear mediante el lanzamiento de algún tipo de script externo.
Ahora, suelo preferir MSBuild en lugar de 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 construcción tienen la disciplina para mantener los scripts NAnt simples, entonces todo está bien. Sin embargo, he visto demasiados sistemas basados en NAnt ir al sur hasta el punto en que nadie entiende lo que está haciendo nunca más, y no hay una manera real de depurarlo además de hacer el equivalente a un buen viejo printf. En el momento en que empiezas a utilizar alguna instrucción if/else o para el ciclo, ahí es donde, en mi humilde opinión, comienza a oler.
Por otro lado, MSBuild tiene una base sólida basada en metadatos y una sintaxis menos detallada. Su simplicidad (o la falta de características ... dependiendo de cómo lo vea) le obliga a escribir la lógica en el código .NET a través de nuevas tareas, en lugar de escribir la lógica en el marcado 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 cosa que realmente te molesta, estar ligado a Microsoft.
Cambié de NANT a MSBuild. El proyecto se está ejecutando en .Net 4.0.
Mi experiencia en Nant fue buena. El proyecto tipo de murió. Y cuando apareció .Net 4.0, era hora de volver a evaluar el proceso de compilación.
Desde que Nant fue lanzado por última vez, MSBuild ha recorrido un largo camino. En este punto, MSBuild es el camino a seguir. Es fácil de usar, tiene muchas extensiones. Reescribí mis scripts de Nant en un día y medio. El script MSBuild tiene 1/3 del tamaño de los scripts de Nant.
Gran parte del trabajo en la secuencia de comandos de Nant estaba configurando los diferentes entornos. En MsBuild/.Net 4.0 está incorporado.
Uso Nant y me encanta.Solía MSBuild y odiaba a causa de estos:
Microsoft le obliga a seguir su propio procedimiento de generación que es tan intrínseco a sus obras que yo al menos no fue capaz de hacer que funcione (tuve que recopilar 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.
ItemTypes para hacer operaciones de archivos son demasiado difíciles de seguir. Puedes hacer que Nant haga exactamente las mismas cosas y sea mucho más fácil y directo (tuve que crear una lista ItemType y luego pasar a las operaciones del archivo).
En MsBuild tienes que crear tu propia dll de tareas, en Nant puedes hacer esto o puedes insertar código C# en tu script, por lo que es mucho más fácil avanzar y solo construir todo el proyecto.
Nant funciona con Net1.1, MsBuild no.
Para instalar nant, incluso puedo descomprimir 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 estoy equivocado aquí, pero esa parece ser la verdad).
Bueno estas son mis opiniones ...
MSBuild 4.0 admite tareas en línea; consulte http://msdn.microsoft.com/en-us/library/dd722601.aspx. – BCran
Bueno, pero eso está en VS2012. Estoy hablando de una aplicación VS2003.Es tan frustrante para mí que la MS te obliga a actualizar toda tu pila de desarrollo para obtener nuevas funciones. Si pudieran liberar cada cosa por separado, sería mucho menos doloroso. –
http://stackoverflow.com/questions/476163/nant-or-msbuild-which-one-to-choose-and-when – webwesen
webwesen tiene descubrió un agujero recursivo en este universo, al ubicar una referencia a una pregunta que no había existido, ¿no debería ser al revés? – DevelopingChris