Gibt es einen empfohlenen Ansatz zum Konfigurieren eines NuGet-Pakets, das auf mehrere Frameworks in TeamCity mit MSBuild abzielt?

Question

Ich habe eine Handvoll Posts gelesen (siehe Referenzen unten) und muss noch einen Leitfaden zu Best Practices finden, der speziell für meinen Tech-Stack gilt.

Das Ziel: Erstellen Sie ein einzelnes NuGet-Paket, das auf mehrere .NET-Frameworks abzielt, die aus einer einzelnen .csproj-Datei über TeamCity mit MSBuild und NuGet erstellt werden.

Die Einschränkungen:

1. den Code aus dem VCS nur einmal ziehen.
2. Alle kompilierten Baugruppen sollten identisch versioniert werden.
3. Einzelne .csproj (nicht eine pro Zielframework).

Ich habe zwei Ansätze im Sinn:

1. Erstellen Sie eine einzelne Build-Konfiguration. Es würde drei Build-Schritte enthalten: .NET 3.5 kompilieren, .NET 4.0 kompilieren, mit NuGet packen. Jeder Bauschritt wäre vom Erfolg des letzten abhängig. Das einzige wirkliche Problem, das ich bei diesem Ansatz sehe (und hoffentlich gibt es eine Lösung, die mir nicht bekannt ist) ist, dass jeder Build-Schritt eine eigene Reihe von Build-Parametern benötigt (zB system.TargetFrameworkVersion und system.OutputPath) eindeutiger Speicherort für die DLL (z. B. bin \ release \ v3.5 und bin \ release \ v4.0), damit der NuGet-Pack-Schritt seine Aufgabe basierend auf dem Abschnitt "Files" in der .nuspec-Datei ausführen kann.

2. Erstellen Sie mehrere Build-Konfigurationen. Eine Build-Konfiguration für die oben beschriebenen Build-Schritte. Mit diesem Ansatz ist es einfach, das TargetFrameworkVersion- und das OutputPath-Buildparameterproblem zu lösen, aber ich muss nun Snapshot-Abhängigkeiten erstellen und die Assemblyversionsnummer über die Builds hinweg teilen. Es verschlingt auch Build-Konfiguration Slots, die für uns ok (aber nicht optimal) ist, da wir eine Enterprise-Lizenz haben.

Option # 1 scheint die offensichtliche Wahl zu sein. Optionen # 2 fühlt sich schmutzig an.

Also meine beiden Fragen sind:

1. Ist es möglich, Parameter zu erstellen, die zu einem Build-Schritt einzigartig sind?
2. Gibt es einen dritten, besseren Ansatz?

Referenzen:

1. Multi-framework NuGet build with symbols for internal dependency management
2. Nuget - packing a solution with multiple projects (targeting multiple frameworks)
3. http://lostechies.com/joshuaflanagan/2011/06/23/tips-for-building-nuget-packages/
4. http://msdn.microsoft.com/en-us/library/hh264223.aspx
5. https://stackoverflow.com/a/1083362/607701
6. http://confluence.jetbrains.com/display/TCD7/Configuring+Build+Parameters
7. http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package

Answer 1

Hier ist meine bevorzugte Lösung (Option 1):

Die Magie beruht auf einer unglücklichen Abhilfe. Wenn Sie diesen Kompromiss eingehen möchten, funktioniert diese Lösung. Wenn Sie nicht sind, können Sie the issue that I opened on JetBrains' issue tracker folgen.

Die einzige Build-Konfiguration sieht wie folgt aus:

Notieren Sie sich den Namen der ersten beiden Build-Schritte. Sie werden tatsächlich explizit als die TargetFrameworkVersion-Werte für .NET 3.5 und 4.0 bezeichnet.

Dann im Build-Parameter Abschnitt habe ich konfiguriert die folgenden Parameter:

Und schließlich hat der Nuget Pack-Schritt die Übersetzung Dateipfad nach meiner .nuspec der Abschnitt Dateien:

Hier

<files> 
    <file src="bin\release\v3.5\*.*" target="lib\net35" /> 
    <file src="bin\release\v4.0\*.*" target="lib\net40" /> 
</files> 

Answer 2

ist eine Lösung, den zweiten Ansatz:

Das Projekt enthält die folgenden Buildkonfigurationen und Vorlage:

Das Shared Build-Number Generator die erste Build in der Kette ist. Es erstellt nur eine Build-Nummer, die die abhängigen Builds gemeinsam nutzen. Ich benutze das TeamCity-referenzierte Plugin Shared Build Number von Nicholas Williams.

Und hier sind die bemerkenswerten Konfigurationen in der Build-Vorlage:

Beachten Sie die Build-Nummer wird von der Build-ID des gemeinsam genutzten Number Generator oben erwähnte beim Aufbau kommen. In diesem Fall ist die ID dieses Builds 14. Beachten Sie auch die Variable% TargetFrameworkVersion% im Artefaktpfad. Glücklicherweise unterstützt TeamCity die variable Interpolation fast überall.

für die Vorlage Um die Build-Nummer zu nutzen, muss es eine Momentaufnahme Abhängigkeit Konfiguration in diesem Build: identisch

Und schließlich (in Bezug auf die Vorlage), sind die Build-Parameter nahezu zu den Parametern in meiner bevorzugten Lösung. Beachten Sie jedoch den zusätzlichen Konfigurationsparameter. Dies ist, was durch die Vererbungs Build-Konfigurationen außer Kraft gesetzt werden:

Dann in den abhängigen baut, um einen Schnappschuss Abhängigkeit verkabeln müssen, so dass die Build-Nummer (aus der Vorlage übernommen) tatsächlich funktioniert, indem auch eine Abhängigkeit von der gemeinsamen Build-Nummer Build-Konfiguration unter:

Und natürlich müssen Sie den tatsächlichen gezielten Rahmen setzen:

Nachdem die tatsächlichen Builds konfiguriert wurden, können Sie jetzt die NuGet Pack-Buildkonfiguration konfigurieren. Sie brauchen nicht zu einem VCS Wurzel befestigen:

Aber Sie müssen eine Reihe von Abhängigkeiten (beide Snapshot und Artefakt) konfigurieren:

Und schließlich Sie sind fertig.