Duplicar posible:
NAnt or MSBuild, which one to choose and when?Mejor Herramienta de Construcción .NET
¿Cuál es la mejor herramienta de construcción de .NET?
Actualmente uso NAnt pero solo porque tengo experiencia con Ant. ¿Se prefiere MSBuild?
realidad Utilizamos una combinación de NAnt y MSBuild con CruiseControl. NAnt se utiliza para el control de flujo de scripts y llama a MSBuild para compilar proyectos. Una vez que se desencadena la compilación física, NAnt se utiliza para publicar los resultados de compilación de proyectos individuales en una ubicación compartida.
No estoy seguro de que esto sea el mejor proceso. Creo que muchos de nosotros todavía estamos buscando una gran herramienta de compilación. Una cosa prometedora que escuché recientemente en .NET Rocks, episode 362, es James Kovac's PSake, un sistema de compilación basado totalmente en PowerShell. Parece realmente prometedor, ya que lo que se puede hacer con PowerShell es bastante ilimitado en teoría.
En general, tengo la impresión de que NAnt ofrece más flexibilidad en comparación con MSBuild, mientras que (con mis necesidades relativamente simples) he estado bien con este último hasta el momento.
Utilizamos MSBuild, porque empezamos con Visual Studio 2005 (ahora Visual Studio 2008), y MSBuild ya estaba "construido en" para el SDK - hay menos mantenimiento en el servidor de compilación. En realidad, es un clon de NAnt: ambas herramientas son infinitamente flexibles ya que le permiten crear tareas de compilación personalizadas en código, y ambas tienen un conjunto decente de tareas de creación de comunidad ya creadas.
He usado ambos y prefiero NAnt. Es realmente difícil para mí decir que uno es "mejor" que el otro.
He usado tanto MSBuild como NAnt, y prefiero MSBuild, principalmente porque requiere mucha menos configuración por defecto. Aunque puede complicar demasiado las cosas y cargar MSBuild con una gran cantidad de basura de configuración también, en su forma más simple, puede apuntarla a un archivo de solución/proyecto y hacer que funcione, la mayoría de las veces, para la mayoría de los casos, es suficiente.
También depende de lo que está construyendo. El MSBuild SDC Task library tiene un par de tareas especiales. Por ejemplo, para AD, BizTalk, etc.
Hay más de 300 tareas incluidas en esta biblioteca que incluye tareas para: creación de sitios web, creando grupos de aplicaciones, creando usuarios ActiveDirectory, corriendo FxCop, configuración de servidores virtuales, creando archivos zip, configurar COM+, la creación de acciones de carpeta, la instalación en el GAC, configurar SQL Server, configuración de BizTalk 2004 y BizTalk 2006, etc.
Me gustaría lanzar FinalBuilder a la mezcla. No es gratis, pero si estás harto de editar los archivos XML y quieres un entorno un poco más agradable (IMO) para trabajar, lo probaría.
He trabajado con todos ellos y siempre he vuelto a FinalBuilder.
+1 de mí. FinalBuilder * es * una gran herramienta, sin dudas. –
Uso MSBuild completamente para la construcción. Aquí está mi script MSBuild genérica que busca en el árbol de archivos Csproj y las construye:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<UsingTask AssemblyFile="$(MSBuildProjectDirectory)\bin\xUnit\xunitext.runner.msbuild.dll" TaskName="XunitExt.Runner.MSBuild.xunit"/>
<PropertyGroup>
<Configuration Condition="'$(Configuration)'==''">Debug</Configuration>
<DeployDir>$(MSBuildProjectDirectory)\Build\$(Configuration)</DeployDir>
<ProjectMask>$(MSBuildProjectDirectory)\**\*.csproj</ProjectMask>
<ProjectExcludeMask></ProjectExcludeMask>
<TestAssembliesIncludeMask>$(DeployDir)\*.Test.dll</TestAssembliesIncludeMask>
</PropertyGroup>
<ItemGroup>
<ProjectFiles Include="$(ProjectMask)" Exclude="$(ProjectExcludeMask)"/>
</ItemGroup>
<Target Name="Build" DependsOnTargets="__Compile;__Deploy;__Test"/>
<Target Name="Clean">
<MSBuild Projects="@(ProjectFiles)" Targets="Clean"/>
<RemoveDir Directories="$(DeployDir)"/>
</Target>
<Target Name="Rebuild" DependsOnTargets="Clean;Build"/>
<!--
===== Targets that are meant for use only by MSBuild =====
-->
<Target Name="__Compile">
<MSBuild Projects="@(ProjectFiles)" Targets="Build">
<Output TaskParameter="TargetOutputs" ItemName="AssembliesBuilt"/>
</MSBuild>
<CreateItem Include="@(AssembliesBuilt -> '%(RootDir)%(Directory)*')">
<Output TaskParameter="Include" ItemName="DeployFiles"/>
</CreateItem>
</Target>
<Target Name="__Deploy">
<MakeDir Directories="$(DeployDir)"/>
<Copy SourceFiles="@(DeployFiles)" DestinationFolder="$(DeployDir)"/>
<CreateItem Include="$(TestAssembliesIncludeMask)">
<Output TaskParameter="Include" ItemName="TestAssemblies"/>
</CreateItem>
</Target>
<Target Name="__Test">
<xunit Assembly="@(TestAssemblies)"/>
</Target>
</Project>
(. Lo siento si es un poco densa de rebajas parece estar excluyendo las líneas en blanco.)
Es muy sencillo aunque una vez que entiendes los conceptos y todas las dependencias se manejan automáticamente. Debo señalar que usamos archivos de proyecto de Visual Studio, que tienen mucha lógica incorporada, pero este sistema permite a las personas crear casi idénticamente dentro del IDE de Visual Studio o en la línea de comandos y aún así le da la flexibilidad de agregar cosas a la construcción canónica como la prueba xUnit que ves en el script de arriba.
El único PropertyGroup es donde ocurre toda la configuración y las cosas se pueden personalizar, como excluir ciertos proyectos de la compilación o agregar nuevas máscaras de ensamblaje de prueba.
El ItemGroup es donde ocurre la lógica que encuentra todos los archivos .csproj en el árbol.
Luego están los objetivos, que la mayoría de las personas que están familiarizadas con make, nAnt o MSBuild deberían poder seguir. Si llama al objetivo de compilación, llama a __Compile, __Deploy y __Test. El objetivo Limpio llama a MSBuild en todos los archivos de proyecto para que limpien sus directorios y luego se elimina el directorio de despliegue global. Reconstruye las llamadas Limpiar y luego compilar.
Usar un lenguaje de scripts dinámico como Python, BOO, Ruby, etc. para crear y mantener scripts de compilación puede ser una buena alternativa a uno basado en XML como NAnt. (Tienden a ser más limpios de leer que XML.)
Uso un software comercial, Automated Build Studio para la construcción.
UppercuT utiliza NAnt para compilar 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.
Algunas buenas explicaciones aquí: UppercuT
El primer enlace está muerto. El proyecto probablemente ya no está en desarrollo activo. – kaskelotti
UppercuT se está preparando para implementar Cake, por lo que el desarrollo está a punto de desaparecer. Pero tienes razón, ese enlace se actualizó. – ferventcoder
Hay otra nueva herramienta de construcción (un envoltorio muy inteligente) llamada NUBuild. Es liviano, de código abierto y extremadamente fácil de configurar y proporciona un mantenimiento casi sin contacto. Realmente me gusta esta nueva herramienta, y la hemos convertido en una herramienta estándar para nuestra construcción e integración continua de nuestros proyectos (tenemos alrededor de 400 proyectos en 75 desarrolladores). Pruébalo.
que estamos usando Bounce, un marco para scripts de compilación más limpios en C#.
Rake y Albacore es una excelente combinación. El poder de Ruby y no XML.
.NET Open Source 5 - .NET Automation with Rake and Albacore by Liam McLennan [Tekpub.com]
fue un video épico, estoy comenzando a usar esto también como mi herramienta de compilación :), una vez que hayas visto el video, mira http://code-magazine.com/Article.aspx?QuickID=1006101 – dbones
Hey Peter - que hacen lo mismo, pero con plantilla Nant y hacen que sea reutilizable. Con lo que terminamos lanzamos como un producto llamado UppercuT - http://projectuppercut.org – ferventcoder
Lo comprobaré.He pensado en varias ocasiones sobre la creación de plantillas del script NAnt, pero no he llegado a eso. El mayor punto de dolor en nuestro proceso es el tedioso ciclo copiar/pegar/editar para configurar un nuevo proyecto para compilación. Es fácil porque ahora tenemos convenciones bien definidas, pero, como dije, es tedioso ... Gracias por la información. –