Interne NuGet-Paketverwaltung in großen Lösungen

Als wir unser neuestes Projekt (großes Framework) starteten, begannen wir mit ProGet für unseren Paketserver und TeamCity für Build (Visual Studio Team Services ist der SC). Eine der Lösungen im Framework enthält fast 60 Bibliotheken unseres Codes, die alles von Redis bis zu Wrappern für externe APIs und allgemeine Modelle implementieren. Jede dieser Bibliotheken ist ein kleines Paket. Zu Beginn des Projekts war es sehr einfach, eine Kernbibliothek zu ändern, sie einzuchecken, TeamCity zu erstellen und zu aktualisieren und zu aktualisieren, und Sie konnten loslegen.

In Kürze wurde dies jedoch nicht mehr handhabbar und das Team entschied, dass sich während der Entwicklung keine Nuget-Pakete in der allgemeinen Bibliothekslösung über ihr Paket gegenseitig referenzieren würden, sondern dass sie direkte Referenzen wären. Dies beschleunigte natürlich das Tempo der Entwicklung, hatte aber eine unangenehme Nebenwirkung auf die konsumierenden Apps. Obwohl die Common Libraries direkte Referenzen waren, erhielten die 7 Hauptteile des Microservice-Frameworks (Web API, Multiple Mvc und einige Worker-Rollen) beim Update eines unserer internen Pakete mehrere Kopien der gleichen Core-Bibliotheken, von denen alle anderen Bibliotheken abhängen auf.

Zum Beispiel gibt es eine einzelne Bibliothek mit dem Namen "core", die die Bausteine ​​enthält, für die in den allgemeinen Bibliotheken fast alles aufgebaut ist. Es hat viele Schnittstellen, etc ... Nun, da alle anderen Bibliotheken es direkt nutzen, erhalten sie alle eine Kopie des Kerns direkt in ihrer Ausgabe und noch mehr darüber, dass unser Teamcity-Server die Versionierung für uns übernimmt, also nicht nur sie jeder hat eine Kopie des Kerns, aber seine Version stimmt mit der des nuget-Pakets überein, das es verbraucht.

Obwohl das nicht großartig ist, ist das immer noch nicht der Kern des Problems. Bei Nuget-Updates in den konsumierenden Apps kann jede Bibliothek innerhalb der App auf eine andere Version des Kerns verweisen, abhängig von der Reihenfolge, in der die Pakete aktualisiert wurden, was gelegentlich zu Buildfehlern und zur Suche nach der Rogue-Referenz führt.

Jetzt, da das Projekt in die letzte Phase geht, möchte ich das dauerhaft lösen, aber ich bin mir nicht sicher, wie.

Damit die nuget-Pakete sich gegenseitig als nuget-Pakete konsumieren, kann ein einzelnes Update Stunden dauern, wenn ein abhängiges Paket aktualisiert wird, Sie neu erstellen, ein anderes nuget-Paket erzeugen, das ein Paket in der Kette benötigt usw.

Die Versionsverwaltung ist jedoch von entscheidender Bedeutung, da wir, wenn Änderungen auftreten, die einzelnen Abhängigkeiten nutzen wollen, um Upgrades dort zu verhindern, wo sie benötigt werden.

Ist jemand anderes dazu gekommen und hat es gelöst? Es scheint, als wäre es ziemlich häufig, wenn nuget vollständig von jedem Entwicklungsteam übernommen wird, das ein umfangreiches Projekt erstellt.

Aktualisierung:

Beispiel was unter der Motorhaube passiert.

CoreLib (Schnittstellen, etc ...) Lib1 (verweist direkt auf Corelib, aktuelle Version = v1.0.17) Lib2 (verweist direkt auf Corelib, aktuelle Version = v1.0.99)

Sowohl Lib1 als auch Lib2 sind Nugget-Pakete. Es wird ein Update auf Lib1 durchgeführt, das eine nicht-brechende Änderung an CoreLib beinhaltet. Wenn Lib1 eingecheckt ist, startet TeamCity einen Build und ein neues nugget-Paket wird erstellt, v1.0.18).

Wenn das Lib1-Paket in den konsumierenden Projekten aktualisiert wird, ist Lib1s Kopie von CoreLib, v1.0.18, da AssemblyVersion von TeamCity verwaltet wird, eine niedrigere Version als Lib2s Version (v1.0.99), obwohl es eine Version dahinter ist .

Das Endziel ist es, all diese voneinander abhängigen Pakete neu aufzubauen, zu aktualisieren und neu zu packen, aber wie dies automatisch geschieht, entkommt mir wirklich.