tfs - Opción para la herramienta de compilación: MSBuild, NANT o algo más?
(3)
Estoy haciendo automatización en mi empresa. Somos un taller de C #. Actualmente estoy trabajando en la compilación automatizada. NANT es una herramienta de control de flujo. Si bien NANT no se desarrolla activamente (el último binario lanzado en junio de 2012 y el repositorio de github no está activo), MSBuild es mejor. Por lo tanto, prefiero MSBuild, pero retirar NANT sigue siendo cuestionable: ¿cuál es el costo?
He presentado algunos pros y contras, pero sé que la inteligencia colectiva es mejor. ¡Gracias por tu ayuda!
Actualización : He leído la pregunta, pero la segunda respuesta me preocupa. En la máquina de compilación hay múltiples marcos .NET, ¿será problemático?
MSBuild
Pros :
- Soporte comercial
- La comunidad esta creciendo
- Integrado con VS y TFS
- Mantén el ritmo con .Net
Contras :
- Reescribe la secuencia de comandos actual
- No es familiar para las personas.
NANT
Pros :
- Ya en uso
- Familiar por personas
Contras :
- No actualizado durante mucho tiempo (desde 2012)
- La comunidad no está activa.
- Falta de nuevo soporte .Net
Escribimos FlubuCore (reescritura de Flubu). Es una biblioteca C # de código abierto para construir proyectos y ejecutar scripts de implementación utilizando el código C #.
Las principales ventajas de flubu que veo son:
- Soporte de .Net Core.
- Fácil de aprender y usar porque escribe el script de compilación completamente en C #.
- Interfaz fluida e intelisense.
- Muchas tareas integradas (compilar, ejecutar pruebas, administrar iis, crear paquetes de implementación, publicar paquetes nuget, ejecutar scripts de PowerShell ...)
- Escriba su propio código C # personalizado en el script y ejecútelo.
- Ejecute cualquier programa externo o comando en script con RunProgramTask.
- Haga referencia a cualquier biblioteca .net o archivo de código fuente de c # en buildscript. Ahora también está disponible la opción para hacer referencia al paquete nuget en el script de compilación.
- Escriba pruebas, depure su script de compilación.
- Use tareas flubu en cualquier otra aplicación .net.
- La API web está disponible para flubu. Útil para implementaciones automatizadas de forma remota.
- Escriba sus propias tareas de flubu y extienda la interfaz fluida de flubu con ellas.
Puedes encontrar flubu en nuget:
Busque FlubuCore.Runner si lo necesita para el proyecto .net
Busque dotnet-flubu si lo necesita para el proyecto principal de.net
Ejemplo de cómo se usa flubu en .net:
protected override void ConfigureBuildProperties(IBuildPropertiesContext context) {
context.Properties.Set(BuildProps.NUnitConsolePath,
@ "packages/NUnit.ConsoleRunner.3.6.0/tools/nunit3-console.exe");
context.Properties.Set(BuildProps.ProductId, "FlubuExample");
context.Properties.Set(BuildProps.ProductName, "FlubuExample");
context.Properties.Set(BuildProps.SolutionFileName, "FlubuExample.sln");
context.Properties.Set(BuildProps.BuildConfiguration, "Release");
}
protected override void ConfigureTargets(ITaskContext session) {
var loadSolution = session.CreateTarget("load.solution")
.SetAsHidden()
.AddTask(x => x.LoadSolutionTask());
var updateVersion = session.CreateTarget("update.version")
.DependsOn(loadSolution)
.SetAsHidden()
.Do(TargetFetchBuildVersion);
session.CreateTarget("generate.commonassinfo")
.SetDescription("Generates common assembly info")
.DependsOn(updateVersion)
.TaskExtensions().GenerateCommonAssemblyInfo()
var compile = session.CreateTarget("compile")
.SetDescription("Compiles the solution.")
.AddTask(x => x.CompileSolutionTask())
.DependsOn("generate.commonassinfo");
var unitTest = session.CreateTarget("unit.tests")
.SetDescription("Runs unit tests")
.DependsOn(loadSolution)
.AddTask(x => x.NUnitTaskForNunitV3("FlubuExample.Tests"));
session.CreateTarget("abc").AddTask(x => x.RunProgramTask(@ "packages/LibZ.Tool/1.2.0/tools/libz.exe"));
session.CreateTarget("Rebuild")
.SetDescription("Rebuilds the solution.")
.SetAsDefault()
.DependsOn(compile, unitTest);
}
//// Some custom code
public static void TargetFetchBuildVersion(ITaskContext context) {
var version = context.Tasks().FetchBuildVersionFromFileTask().Execute(context);
int svnRevisionNumber = 0; //in real scenario you would fetch revision number from subversion.
int buildNumber = 0; // in real scenario you would fetch build version from build server.
version = new Version(version.Major, version.Minor, buildNumber, svnRevisionNumber);
context.Properties.Set(BuildProps.BuildVersion, version);
}
Ejemplo de cómo se usa flubu en .net core
public class MyBuildScript : DefaultBuildScript
{
protected override void ConfigureBuildProperties(IBuildPropertiesContext context)
{
context.Properties.Set(BuildProps.CompanyName, "Flubu");
context.Properties.Set(BuildProps.CompanyCopyright, "Copyright (C) 2010-2016 Flubu");
context.Properties.Set(BuildProps.ProductId, "FlubuExample");
context.Properties.Set(BuildProps.ProductName, "FlubuExample");
context.Properties.Set(BuildProps.SolutionFileName, "FlubuExample.sln");
context.Properties.Set(BuildProps.BuildConfiguration, "Release");
}
protected override void ConfigureTargets(ITaskContext context)
{
var buildVersion = context.CreateTarget("buildVersion")
.SetAsHidden()
.SetDescription("Fetches flubu version from FlubuExample.ProjectVersion.txt file.")
.AddTask(x => x.FetchBuildVersionFromFileTask());
var compile = context
.CreateTarget("compile")
.SetDescription("Compiles the VS solution and sets version to FlubuExample.csproj")
.AddCoreTask(x => x.UpdateNetCoreVersionTask("FlubuExample/FlubuExample.csproj"))
.AddCoreTask(x => x.Restore())
.AddCoreTask(x => x.Build())
.DependsOn(buildVersion);
var package = context
.CreateTarget("Package")
.CoreTaskExtensions()
.DotnetPublish("FlubuExample")
.CreateZipPackageFromProjects("FlubuExample", "netstandard2.0", "FlubuExample")
.BackToTarget();
//// Can be used instead of CreateZipPackageFromProject. See MVC_NET4.61 project for full example of PackageTask
//// context.CreateTarget("Package2").AddTask(x =>
x.PackageTask("FlubuExample"));
var test = context.CreateTarget("test")
.AddCoreTaskAsync(x => x.Test().Project("FlubuExample.Tests"))
.AddCoreTaskAsync(x => x.Test().Project("FlubuExample.Tests2"));
context.CreateTarget("Rebuild")
.SetAsDefault()
.DependsOn(compile, test, package);
}
}
La presentación detallada y la documentación se pueden encontrar aquí: https://github.com/flubu-core/flubu.core
Puede encontrar ejemplos completos aquí: https://github.com/flubu-core/examples
Gracias por todas las respuestas Hemos decidido usar Cake ya que somos un taller de C #.
Hay una propiedad
nant.settings.currentframework
que se utiliza para establecer el marco de destino en caso de que tenga múltiples marcos .net
<property name="nant.settings.currentframework" value="net-2.0" />
- nant.settings.currentframework El marco de destino actual, por ejemplo. ''net-1.0''.
- nant.settings.currentframework.description En desuso . Descripción del marco objetivo actual.
- nant.settings.currentframework.frameworkdirectory Desaprobado. El directorio marco del marco objetivo actual.
- nant.settings.currentframework.sdkdirectory Desaprobado . El directorio del framework SDK del framework de destino actual.
- nant.settings.currentframework.frameworkassemblydirectory En desuso . El directorio de ensamblaje de marco del marco de destino actual.
- nant.settings.currentframework.runtimeengine En desuso . El motor de tiempo de ejecución del marco de destino actual si se usa, por ejemplo. mono.exe.