projects-and-solutions - org - visual studio nuget options



NuGet und mehrere Lösungen (3)

Wir haben zwei Lösungen: foo.sln und bar.sln

Ich habe eine gemeinsame Bibliothek, die sowohl von Foo als auch von Bar verwendet wird. Common.csproj wird von beiden verwendet.

Wenn ich foo öffne und Nuget-Referenzen aktualisiere, verweisen alle Referenzen in Common.csproj auf foo / packages /. Wenn ich später die Leiste öffne und Nuget-Referenzen aktualisiere, werden alle Referenzen auf die in bar / packages / gesetzt. Natürlich pisst das foo-Team ab, da es zu Inkompatibilitäten zwischen Common.csproj und Foo-spezifischen Dingen wie Foo.Data.csproj kommen kann, was immer noch auf foo / packages hinweist.

Es muss eine andere offensichtliche Lösung geben als: "Erstellen Sie eine riesige Lösung, die alle Ihre Projekte enthält. Wenn Sie Nuget berühren müssen, tun Sie dies nur von dieser Lösung aus."

Es scheint ein Problem mit Codeplex zu geben (das Top-Thema, das übrigens gewählt wurde), aber offensichtlich bin ich zu dick, um zu verstehen, wie dieses Problem gelöst wird. Kann jemand erklären, wie man das beheben kann?

https://code.i-harness.com


Dieses Problem liegt vor NuGet. Wenn Sie ein Projekt in zwei Lösungen referenziert haben und Assemblyreferenzen im Projekt ändern, wenn es in einer Lösung geöffnet ist, ändert es natürlich den Referenzpfad für dieses Projekt, wenn es in der anderen Lösung geöffnet ist. Dies war immer der Fall, unabhängig davon, wie die Referenz geändert wurde (mit NuGet oder auf andere Weise).

Aber das eigentliche Problem ist, dass die aktualisierten Pakete bei einem Update nicht im Verzeichnis foo / packages angezeigt werden, oder?

Die einfache Lösung besteht darin, Common.csproj in eine eigene Lösung mit eigenen Referenzen, Paketordnern, Erstellungs- und Freigabeprozessen zu verschieben. Dann erstellen Sie ein eigenes NuGet-Paket mit allen relevanten Abhängigkeiten. Dann können Sie Ihr Common-Paket sowohl in Foo als auch in Bar installieren. Anschließend kann das Foo-Team auf die neueste Version von Common aktualisieren, sobald diese verfügbar ist.

Das Hauptargument, das ich dagegen gehört habe, ist, dass Sie beim Debuggen möglicherweise den allgemeinen Code schrittweise durchgehen möchten. Dies ist jedoch kein Problem mehr mit Visual Studio 2010.

Die grundlegende Frage, die Sie sich stellen müssen, lautet: Wem gehört Common.csproj? Ist es das Foo-Team oder das Bar-Team?


Ich behebe das Problem, indem Sie den Hinweispfad in der Projektdatei so ändern, dass er die Variable $ (SolutionDir) enthält:

Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <HintPath>$(SolutionDir)packages\EntityFramework.6.1.3\lib\net40\EntityFramework.dll</HintPath>

Verwenden Sie common.csproj nicht als separate Assembly, auf die Sie verweisen, und hat eigene Abhängigkeiten und nicht die der Lösung.

Auf diese Weise schützen Sie common vor entweder foo oder bar, um das referenzierte Paket zu aktualisieren und zu brechen.