Abhängigkeiten

Die primäre Methode zum Hinzufügen von Abhängigkeiten zu einer .NET-Bibliothek ist das Verweisen auf NuGet-Pakete. NuGet-Paketverweise ermöglichen Es Ihnen, bereits geschriebene Funktionen schnell wiederzuverwenden und zu nutzen, aber sie sind eine häufige Quelle von Reibung für .NET-Entwickler. Die ordnungsgemäße Verwaltung von Abhängigkeiten ist wichtig, um zu verhindern, dass Änderungen in anderen .NET-Bibliotheken Ihre .NET-Bibliothek unterbrechen, und umgekehrt!

Rautenabhängigkeiten

Es ist üblich, dass ein .NET-Projekt mehrere Versionen eines Pakets in seiner Abhängigkeitsstruktur enthält. Eine App hängt beispielsweise von zwei NuGet-Paketen ab, die jeweils von einer anderen Version desselben Pakets abhängig sind. Eine Diamond-Abhängigkeit ist jetzt im Abhängigkeitsdiagramm der App vorhanden.

Zur Buildzeit analysiert NuGet alle Pakete, von denen ein Projekt abhängig ist, einschließlich der Abhängigkeiten von Abhängigkeiten. Wenn mehrere Versionen eines Pakets erkannt werden, werden Regeln ausgewertet, um eines zu wählen. Das Vereinheitlichen von Paketen ist erforderlich, da das Ausführen von parallelen Versionen einer Assembly in derselben Anwendung in .NET problematisch ist.

Die meisten diamantförmigen Abhängigkeiten sind einfach zu lösen; sie können jedoch unter bestimmten Umständen Probleme verursachen.

• Konflikte verursachende NuGet-Paketverweise verhindern, dass eine Version während der Paketwiederherstellung aufgelöst wird.
• Breaking Changes zwischen den Versionen verursachen Fehler und Ausnahmen während der Laufzeit.
• Die Paketassembly weist einen starken Namen auf, die Assemblyversion wurde geändert, und die App wird im .NET Framework ausgeführt. Assemblybindungsumleitungen sind erforderlich.

Es ist nicht möglich zu wissen, welche Pakete zusammen mit Ihren eigenen verwendet werden. Eine gute Möglichkeit, um die Wahrscheinlichkeit zu verringern, dass eine Diamantabhängigkeit Ihre Bibliothek unterbricht, besteht darin, die Anzahl der Pakete zu minimieren, von denen Sie abhängig sind.

✔️ ÜBERPRÜFEN Sie Ihre .NET-Bibliothek auf unnötige Abhängigkeiten.

NuGet-Abhängigkeitsversionsbereiche

Ein Paketverweis gibt den zulässigen Bereich gültiger Pakete an. In der Regel ist die Paketreferenzversion in der Projektdatei die Mindestversion, und es gibt kein Maximum.

<!-- Accepts any version 1.0 and above. -->
<PackageReference Include="ExamplePackage" Version="1.0" />

Die Regeln, die NuGet beim Auflösen von Abhängigkeiten verwendet, sind komplex, aber NuGet sucht standardmäßig nach der niedrigsten anwendbaren Version. NuGet bevorzugt die niedrigste anwendbare Version gegenüber der höchsten verfügbaren Version, da die niedrigste Version die wenigsten Kompatibilitätsprobleme aufweisen wird.

Aufgrund der niedrigsten anwendbaren Versionsregel von NuGet ist es nicht erforderlich, eine obere Version oder einen genauen Bereich für Paketverweise zu platzieren, um das Abrufen der neuesten Version zu vermeiden. NuGet versucht bereits, die niedrigste, kompatibelste Version für Sie zu finden.

<!-- Accepts 1.0 up to 1.x, but not 2.0 and higher. -->
<PackageReference Include="ExamplePackage" Version="[1.0,2.0)" />

<!-- Accepts exactly 1.0. -->
<PackageReference Include="ExamplePackage" Version="[1.0]" />

Obere Versionsbeschränkungen führen dazu, dass NuGet fehlschlägt, wenn ein Konflikt vorliegt. Beispielsweise akzeptiert eine Bibliothek genau 1.0, während eine andere Bibliothek 2.0 oder höher benötigt. Während bahnbrechende Änderungen möglicherweise in Version 2.0 eingeführt wurden, führt eine strikte oder obere Begrenzung der Versionsabhängigkeit garantiert zu einem Fehler.

❌ Verwenden Sie keine NuGet-Paketverweise ohne Mindestversion.

❌ VERMEIDEN Sie NuGet-Paketverweise, die eine genaue Version erfordern.

❌ VERMEIDEN SIE NuGet-Paketverweise mit einer oberen Versionsgrenze.

Weitere Informationen finden Sie unter Paketversionsverwaltung.

Freigegebene NuGet-Quellpakete

Eine Möglichkeit, externe NuGet-Paketabhängigkeiten zu reduzieren, besteht darin, auf freigegebene Quellpakete zu verweisen. Ein freigegebenes Quellpaket enthält Quellcodedateien , die in einem Projekt enthalten sind, wenn darauf verwiesen wird. Da Sie nur Quellcodedateien einschließen, die mit dem Rest Ihres Projekts kompiliert werden, gibt es keine externe Abhängigkeit und keine Konfliktwahrscheinlichkeit.

Freigegebene Quellpakete eignen sich hervorragend zum Einschließen kleiner Funktionen. Sie können beispielsweise auf ein freigegebenes Quellpaket mit Hilfsmethoden für HTTP-Aufrufe verweisen.

<PackageReference Include="Microsoft.Extensions.Buffers.Testing.Sources" PrivateAssets="All" Version="1.0" />

Freigegebene Quellpakete haben einige Einschränkungen. Sie können nur von PackageReferencereferenziert werden, sodass ältere packages.config Projekte ausgeschlossen werden. Außerdem können freigegebene Quellpakete nur von Projekten mit derselben Sprache verwendet werden. Aufgrund dieser Einschränkungen werden freigegebene Quellpakete am besten verwendet, um Funktionen innerhalb eines Open-Source-Projekts freizugeben.

✔️ ZIEHEN SIE IN BETRACHT, auf freigegebene Quellpakete für kleine, interne Funktionen zu verweisen.

✔️ ERWÄGEN Sie, Das Paket als freigegebenes Quellpaket zu erstellen, wenn es kleine, interne Funktionen bereitstellt.

✔️ Verweisen Sie auf freigegebene Quellpakete mit PrivateAssets="All".

Diese Einstellung teilt NuGet mit, dass das Paket nur zur Entwicklungszeit verwendet werden soll und nicht als öffentliche Abhängigkeit verfügbar gemacht werden soll.

❌ Verwenden Sie KEINE geteilten Quellpakettypen in Ihrer öffentlichen API.

Gemeinsam genutzte Quelltypen werden in der referenzierenden Assembly kompiliert und können nicht über Assemblygrenzen hinweg ausgetauscht werden. Ein IRepository-Typ mit freigegebenen Quellen in einem Projekt ist ein anderer Typ als der gleiche IRepository-Typ mit freigegebenen Quellen in einem anderen Projekt. Typen in freigegebenen Quellpaketen sollten mit internal-Sichtbarkeit versehen sein.

❌ Veröffentlichen Sie keine freigegebenen Quellpakete für NuGet.org.

Freigegebene Quellpakete enthalten Quellcode und können nur von Projekten mit demselben Sprachtyp verwendet werden. Beispielsweise kann ein freigegebenes C#-Quellpaket nicht von einer F#-Anwendung verwendet werden.

Veröffentlichen Sie freigegebene Quellpakete in einem lokalen Feed oder MyGet , um sie intern in Ihrem Projekt zu nutzen.

ZurückWeiter