dotnet pack Projektreferenzen

Question

Ich mag die Trennung von Funktionalität über einige wenige Baugruppen, zum Beispiel eine Fassade zu einem Datenprovider, Verträge für den Datenprovider und die Datenprovider-Implementierung selbst ... meiner Meinung nach ist es einfach zu Einheit Testen Sie die einzelnen Komponenten einer Funktionalität und tauschen Sie in Zukunft einfach eine aus (im Falle meines Beispiels kann der Datenprovider einfach ausgetauscht werden).

Wenn ich eine Lösung mit 3 Projekten erstellen und Projektreferenzen verwenden, werden alle Referenzen in den Ausgabeordner kopiert, wenn ich auf die Eingabeassembly baue. Wenn ich das Entry-Assembly-Projekt zum Erstellen eines NuGET-Pakets mit dotnet packe, wird nur die Entry-Assembly (nicht die Verträge oder der Datenprovider) in das NuGET-Paket eingefügt.

Dies scheint von Entwurf zu sein; die documentation für .NET Core-Dotnet-Pack besagt, dass

Projekt-to-Projektreferenzen innerhalb des Projektes nicht verpackt. Derzeit müssen Sie pro Projekt ein Paket haben, wenn Sie Projekt-zu-Projekt-Abhängigkeiten haben.

Meine Frage ist - warum ist das der Fall? Wenn ich meinen Code in logische Assemblys aufteilen möchte, muss ich entweder separate NuGET-Pakete erstellen und diese referenzieren oder einfach meinen gesamten Code in einer einzigen Assembly zusammenfassen. Gibt es eine Möglichkeit, Projektreferenzen in ein NuGET-Paket aufzunehmen?

Ich verwende VS2017/.NET-Core v1.1 (csproj, nicht xproj)

Answer 1

ein bisschen spät, aber lassen Sie mich versuchen zu erklären, warum ich will nicht alle referenzierten Projekte Baugruppen innerhalb verpackt werden das Eingangspaket standardmäßig.

Die .NET Core-Infrastruktur ist modular aufgebaut und basiert auf dem Paketmodell. Grundsätzlich arbeiten .NET Core SDK und dotnet muxer (.NET core bootstrapper und host process) zuerst mit Paketen und deren Metadaten und nicht mit dlls, die Core CLR sind, die direkt mit ihnen arbeiten. Daher ist in .NET Core auf der höchsten Ebene die Paket-ID/Version primär und der DLL-Name/die DLL-Version innerhalb des Pakets ist sekundär.

Das Paket selbst (obwohl es ein Archiv mit etwas Inhalt ist) ist eine Abstraktion, die durch Name und Version identifiziert wird.

Angenommen, wir hatten das wünschenswerte dotnet pack Verhalten und alle Referenzen sind in der gleichen Eintrittspaket verpackt. Nun, wenn wir eine Projektreferenzkette hätten, bekommen wir ein einzelnes Paket mit allen dlls drin. Sie paßt wohl gut genug für unsere Bedürfnisse, aber es verstößt auch:

• .NET modulare Idee Core (da wir die dlls eher als abstraktes Paket denken, die nur eine ID/Version ist - es würde hinzufügen eine Menge Verwirrung und Komplexität, da würden wir auch die Option benötigen, nicht All-in-One-Paket zu haben, Dlls Duplikation zu vermeiden, dlls Auflösung im Falle mehrerer Versionen, etc.
• SRP (wenn einige der der referenzierte DLLs müssen neu erstellt werden, wir müssen das ganze Paket aktualisieren).

In Bezug auf die Frage, ich denke, eine Möglichkeit, eine benutzerdefinierte .nuspec Datei zu verwenden, die erforderlich zu erreichen, ist, wo Sie die DLLs angeben können Sie diese

<PropertyGroup> 
    <NuspecFile>App.nuspec</NuspecFile> 
</PropertyGroup> 

Mit verpackt werden soll, wird dotnet pack produzieren das Paket in Bezug auf MyPackage.nuspec.

Wenn Sie außerdem 3 Projekte mit Verträgen und Implementierung haben und nicht 3 Paketverweise hinzufügen möchten, können Sie ein Paket erstellen, das einfach diese 3 als Abhängigkeiten hat und dieses einzelne Paket referenziert.

Um das Ganze abzurunden, ist das aktuelle Paket-pro-Projekt-Modell recht einfach und bleibt dennoch flexibel für benutzerdefinierte Anwendungsfälle.