Afhankelijkheden

De primaire manier om afhankelijkheden toe te voegen aan een .NET-bibliotheek is het verwijzen naar NuGet-pakketten. Met NuGet-pakketverwijzingen kunt u snel de reeds geschreven functionaliteit hergebruiken en gebruiken, maar ze zijn een veelvoorkomende bron van wrijving voor .NET-ontwikkelaars. Het correct beheren van afhankelijkheden is belangrijk om te voorkomen dat wijzigingen in andere .NET-bibliotheken uw .NET-bibliotheek breken en omgekeerd.

Ruitafhankelijkheden

Het is gebruikelijk dat een .NET-project meerdere versies van een pakket in de afhankelijkheidsstructuur heeft. Een app is bijvoorbeeld afhankelijk van twee NuGet-pakketten, die elk afhankelijk zijn van een andere versie van hetzelfde pakket. Er bestaat nu een ruitafhankelijkheid in de afhankelijkheidsgrafiek van de app.

Tijdens de build analyseert NuGet alle pakketten waarvan een project afhankelijk is, inclusief de afhankelijkheden van afhankelijkheden. Wanneer meerdere versies van een pakket worden gedetecteerd, worden regels geëvalueerd om er een te kiezen. Het samenvoegen van pakketten is nodig omdat het uitvoeren van side-by-side versies van een assembly in dezelfde toepassing problematisch is in .NET.

De meeste diamantafhankelijkheden kunnen eenvoudig worden opgelost; In bepaalde omstandigheden kunnen ze echter problemen creëren:

• Conflicterende NuGet-pakketverwijzingen voorkomen dat een versie wordt opgelost tijdens het herstellen van pakketten.
• Wijzigingen die fouten veroorzaken tussen de versies veroorzaken fouten en uitzonderingen tijdens runtime.
• De pakketassembly is sterk benoemd, de assemblyversie is gewijzigd en de app wordt uitgevoerd op .NET Framework. Assemblybindingsomleidingen zijn vereist.

Het is niet mogelijk om te weten welke pakketten naast u worden gebruikt. Een goede manier om de kans op een diamantafhankelijkheid te verminderen die uw bibliotheek breekt, is door het aantal pakketten waarvan u afhankelijk bent te minimaliseren.

✔️ Controleer uw .NET-bibliotheek op onnodige afhankelijkheden.

NuGet-versiebereiken voor afhankelijkheid

Een pakketreferentie geeft het bereik aan geldige pakketten op dat is toegestaan. Normaal gesproken is de pakketreferentieversie in het projectbestand de minimale versie en is er geen maximum.

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

De regels die NuGet gebruikt bij het oplossen van afhankelijkheden zijn complex, maar NuGet zoekt standaard naar de laagste toepasselijke versie. NuGet geeft de voorkeur aan de laagste toepasselijke versie ten opzichte van het gebruik van de hoogst beschikbare, omdat het laagste compatibiliteitsproblemen heeft.

Vanwege de laagst toepasselijke versieregel van NuGet is het niet nodig om een hogere versie of exact bereik op pakketverwijzingen te plaatsen om te voorkomen dat de nieuwste versie wordt weergegeven. NuGet probeert al de laagste, meest compatibele versie voor u te vinden.

<!-- 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]" />

Limieten voor hogere versies leiden ertoe dat NuGet mislukt als er een conflict is. Eén bibliotheek accepteert bijvoorbeeld precies 1.0, terwijl voor een andere bibliotheek 2.0 of hoger is vereist. Hoewel belangrijke wijzigingen mogelijk zijn geïntroduceerd in versie 2.0, garandeert een strikte of bovengrensversieafhankelijkheid een fout.

❌ Geen NuGet-pakketverwijzingen zonder minimale versie hebben.

❌ VERMIJD NuGet-pakketverwijzingen die een exacte versie vragen.

❌ VERMIJD NuGet-pakketverwijzingen met een bovengrens voor een versie.

Zie Pakketversiebeheer voor meer informatie.

NuGet-gedeelde bronpakketten

Een manier om externe NuGet-pakketafhankelijkheden te verminderen, is om te verwijzen naar gedeelde bronpakketten. Een gedeeld bronpakket bevat broncodebestanden die zijn opgenomen in een project wanneer ernaar wordt verwezen. Omdat u alleen broncodebestanden opslaat die zijn gecompileerd met de rest van uw project, is er geen externe afhankelijkheid en kans op conflict.

Gedeelde bronpakketten zijn ideaal voor het opnemen van kleine stukjes functionaliteit. U kunt bijvoorbeeld verwijzen naar een gedeeld bronpakket met helpermethoden voor het maken van HTTP-aanroepen.

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

Gedeelde bronpakketten hebben enkele beperkingen. Naar deze projecten kan alleen worden verwezen, PackageReferencezodat oudere packages.config projecten worden uitgesloten. Gedeelde bronpakketten kunnen ook alleen worden gebruikt door projecten met dezelfde taal. Vanwege deze beperkingen kunnen gedeelde bronpakketten het beste worden gebruikt om functionaliteit binnen een opensource-project te delen.

✔️ OVERWEEG om te verwijzen naar gedeelde bronpakketten voor kleine, interne onderdelen van functionaliteit.

✔️ OVERWEEG uw pakket een gedeeld bronpakket te maken als het kleine, interne functionaliteit biedt.

✔️ DO reference shared source packages with PrivateAssets="All".

Deze instelling vertelt NuGet dat het pakket alleen moet worden gebruikt tijdens de ontwikkeling en niet als een openbare afhankelijkheid mag worden weergegeven.

❌ U hebt geen gedeelde bronpakkettypen in uw openbare API.

Gedeelde brontypen worden gecompileerd in de verwijzende assembly en kunnen niet worden uitgewisseld over de grenzen van de assembly. Een type gedeelde bron IRepository in het ene project is bijvoorbeeld een afzonderlijk type van dezelfde gedeelde bron IRepository in een ander project. Typen in gedeelde bronpakketten moeten een internal zichtbaarheid hebben.

❌ Publiceer geen gedeelde bronpakketten naar NuGet.org.

Gedeelde bronpakketten bevatten broncode en kunnen alleen worden gebruikt door projecten met hetzelfde taaltype. Een gedeeld C#-bronpakket kan bijvoorbeeld niet worden gebruikt door een F#-toepassing.

Publiceer gedeelde bronpakketten naar een lokale feed of MyGet om ze intern in uw project te gebruiken.

VorigeVolgende