Projektreferenzen v NuGet-Abhängigkeiten

Question

Ich bin dabei, NuGet in unseren Software-Entwicklungsprozess einzuführen, sowohl für externe Binärdateien (z. B. Moq, NUnit) als auch für interne Bibliotheksprojekte mit gemeinsamer Funktionalität.

TeamCity erstellt NuGet-Pakete aus unseren internen Bibliotheksprojekten und veröffentlicht sie in einem lokalen Repository. Meine modifizierten Lösungsdateien verwenden das lokale Repository für den Zugriff auf die NuGet-Pakete.

Betrachten Sie die folgenden Quellcode Lösungen:

1. Company.Interfaces.sln baut Company.Interfaces.1.2.3.7654.nupkg.
2. Company.Common.sln enthält einen Verweis auf Company.Interfaces über seine NuGet Paket, und baut Company.Common.1.1.1.7655.nupkg mit Company.Interfaces.1.2.3.7654 als Abhängigkeit enthalten.
3. Die Company.DataAccess.sln verwendet das Company.Common nupkg, um Company.Interfaces und Company.Common als Verweise hinzuzufügen. Es erstellt Company.DataAccess.1.0.8.7660.nupkg, einschließlich Company.Common.1.1.1.7655 als abhängige Komponente.
4. Company.Product.A ist eine Website-Lösung, die Verweise auf alle drei Bibliotheksprojekte enthält (hinzugefügt durch Auswahl des Company.DataAccess NuGet-Pakets).

Fragen:

Wenn es eine Änderung Company.Interfaces Quellcode ist, muss ich immer neu zu nummerieren und die Zwischenpakete (Company.Common und Company.DataAccess) wieder aufzubauen und die Pakete aktualisieren in Unternehmen.Produkt.A?

Oder dass nicht davon abhängen, ob der Quellcode Änderung war

• ein Bugfix oder
• eine neue Funktion oder
• eine Bruch Änderung?

In Wirklichkeit habe ich 8 Ebenen von abhängigen Bibliothekspaketen. Gibt es Werkzeugunterstützung für die Aktualisierung eines ganzen Paketbaums, falls dies notwendig sein sollte?

Ich weiß über Semantic Versioning.

Wir verwenden VS2012, C# 4.0, TeamCity 7.1.5.

Answer 1

Es ist eine gute Idee, alles bei jedem Check-in zu aktualisieren, um es früh zu testen.

Das, was Sie beschreiben, kann leicht mithilfe von Artefaktabhängigkeiten (http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies) und Build Build-Auslösern (oder auch nur "Nuget Dependency Trigger") verwaltet werden.

Answer 2

Wir haben unsere eigene Build-Konfiguration auf dem Basisprojekt geschrieben (wäre Company.Interfaces.sln in diesem Fall), die den gesamten Baum auf einmal erstellt und aktualisiert. Es überprüft aktualisierte packages.config-Dateien und .Nuspec-Dateien auf dem Weg. Ich kann nicht sagen, wie viel Zeit das für uns bedeutet hat, auch wenn es am Anfang wie ein Overkill klingen mag.

Eine Sache, auf die man achten sollte: Das Skript, das wir geschrieben haben, überprüft die Dateien, selbst wenn die Kette dazwischen fehlschlägt, um uns die Möglichkeit zu geben, es auf unserem lokalen Rechner zu reparieren.