2016-11-30 53 views
5

Robię automatyzację w mojej firmie. Jesteśmy warsztatem C#. Obecnie pracuję nad zautomatyzowaną kompilacją. NANT jest narzędziem kontroli przepływu. Podczas gdy NANT nie jest aktywnie rozwijany (ostatni plik binarny wydany na czerwiec 2012 a repozytorium github nie jest aktywne), MSBuild jest lepszy. Dlatego wolę MSBuild, ale przejście na emeryturę NANT jest nadal wątpliwe - jaki jest koszt?Wybór narzędzia do kompilacji: MSBuild, NANT czy coś innego?

Mam kilka plusów i minusów, ale wiem, że zbiorowa inteligencja jest lepsza. Dzięki za pomoc!


Aktualizacja: Czytałem pytanie, ale druga odpowiedź wzrasta troska o mnie. Na komputerze z buildem istnieje wiele frameworków .NET, czy będzie to kłopotliwe?


msbuild

Plusy:

  • wsparcie komercyjne
  • Społeczność rośnie
  • Zintegrowany z VS i TFS
  • Trzymaj tempo z .Net

Wady:

  • Przepisz skrypt prąd
  • Nie zna przez ludzi

NANT

Plusy:

  • już w użyciu
  • Familiar przez ludzi

minusy:

  • nie są aktualizowane przez długi czas (od 2012)
  • wspólnotowym jest nieaktywne
  • brak nowych .Net wsparcia
+0

Poss ible duplikat [NAnt lub MSBuild, który z nich należy wybrać i kiedy?] (http://stackoverflow.com/questions/476163/nant-or-msbuild-which-one-to-choose-and-when) –

+0

PSake may Ciekawe również dla Ciebie: https://github.com/psake/psake – jessehouwing

+1

Dzięki za wszystkie odpowiedzi. Zdecydowaliśmy się użyć Cake, ponieważ jesteśmy warsztatem C#. – DSakura

Odpowiedz

-1

Istnieje właściwość nant.settings.currentframework który służy do ustawiania ramy docelowej w przypadku masz kilka.Net Framework

<property name="nant.settings.currentframework" value="net-2.0" /> 

As per .92 build:

  • nant.settings.currentframework Obecne ramy docelowej, np. "net-1.0".
  • nant.settings.currentframework.descriptionPrzestarzałe. Opis obecnych ram docelowych.
  • nant.settings.currentframework.frameworkdirectory Przestarzałe. Katalog szkieletu bieżącego środowiska docelowego.
  • nant.settings.currentframework.sdkdirectoryPrzestarzałe. Katalog SDK ramy bieżącego celu.
  • nant.settings.currentframework.frameworkassemblydirectoryPrzestarzałe. Katalog katalogu szkieletowego bieżącego środowiska docelowego.
  • nant.settings.currentframework.runtimeenginePrzestarzałe. Silnik środowiska wykonawczego bieżącej struktury docelowej, jeśli jest używany np. mono.exe.
1

Napisaliśmy FlubuCore (przepisanie Flubu). Jest to biblioteka C# o otwartym kodzie źródłowym do budowania projektów i wykonywania skryptów wdrażania za pomocą kodu C#.

Główne zalety flubu że widzę to:

  • wsparcie bazowa netto (działa także na platformie Linux i MacOS).
  • Łatwy do nauczenia się i używania, ponieważ piszesz skrypt budujący w całości w C#.
  • Dość dużo wbudowanych zadań (kompilacja, uruchamianie testów, zarządzanie iis, tworzenie pakietu wdrażania, publikowanie pakietów nuget, wykonywanie skryptów powłoki) ...
  • Napisz swój własny kod C# w skrypcie i go uruchom.
  • Uruchom dowolny program zewnętrzny w skrypcie.
  • Odwołaj się do dowolnej biblioteki .net lub pliku kodu źródłowego C# w buildscript.
  • Płynny interfejs i intelisense.
  • Web api jest dostępny dla flubu. Przydatny do zdalnych zautomatyzowanych wdrożeń.
  • Napisz własne zadania flubu i rozszerz płynny interfejs Flubu z nimi.

można znaleźć flubu na Nuget:

Szukaj FlubuCore.Runner jeśli u trzeba go do projektu .net

Search dla dotnet-flubu jeśli u jej potrzebujesz for.net projekt rdzenia

Przykład użycia flubu.netto:

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); 
} 

Przykład jak flubu jest stosowany w rdzeniu .net

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); 
} 

}

można znaleźć pełne przykładów tutaj: https://github.com/flubu-core/examples

Wiki można znaleźć tutaj: https://github.com/flubu-core/flubu.core/wiki