Dépendances

La principale façon d’ajouter des dépendances à une bibliothèque .NET fait référence à des packages NuGet. Les références de package NuGet vous permettent de réutiliser et tirer rapidement parti des fonctionnalités déjà écrites, mais elles sont une source courante de friction pour les développeurs .NET. La gestion correcte des dépendances est importante pour empêcher les modifications apportées à d’autres bibliothèques .NET de rompre votre bibliothèque .NET, et vice versa !

Dépendances de diamant

Il est courant pour un projet .NET d’avoir plusieurs versions d’un package dans son arborescence de dépendances. Par exemple, une application dépend de deux packages NuGet, dont chacun dépend d’une version différente du même package. Une dépendance de diamant existe désormais dans le graphique de dépendances de l’application.

Au moment de la génération, NuGet analyse tous les packages dont dépend un projet, y compris les dépendances des dépendances. Lorsque plusieurs versions d’un package sont détectées, les règles sont évaluées pour en choisir une. L’unification des packages est nécessaire, car l’exécution de versions côte à côte d’un assembly dans la même application est problématique dans .NET.

La plupart des dépendances de diamant sont facilement résolues ; toutefois, ils peuvent créer des problèmes dans certaines circonstances :

• Les références de package NuGet en conflit empêchent la résolution d’une version pendant la restauration du package.
• Les modifications de rupture entre les versions provoquent des bogues et des exceptions au moment de l’exécution.
• Un nom fort est attribué à l’assembly de package, la version d’assembly est modifiée et l’application exécutée sur .NET Framework. Des redirection des liaisons d'assembly sont requises.

Il n’est pas possible de savoir quels packages seront utilisés en même temps que vos propres packages. Une bonne façon de réduire la probabilité d’une dépendance de diamant cassant votre bibliothèque consiste à réduire le nombre de packages dont vous dépendez.

✔️ Passez en revue votre bibliothèque .NET pour connaître les dépendances inutiles.

Plages de versions de dépendances de NuGet

Une référence de package spécifie la plage de packages valides qu’elle autorise. En règle générale, la version de référence du package dans le fichier projet est la version minimale et il n’y a pas de maximum.

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

Les règles que NuGet utilise lors de la résolution des dépendances sont complexes, mais NuGet recherche par défaut la version la plus basse applicable. NuGet préfère la version la plus basse possible plutôt que d'utiliser la version la plus élevée disponible, car cela présente le moins de problèmes de compatibilité.

En raison de la règle de version la plus basse applicable de NuGet, il n’est pas nécessaire de placer une version supérieure ou une plage exacte sur les références de package pour éviter d’obtenir la dernière version. NuGet tente déjà de trouver la version la plus basse et la plus compatible pour vous.

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

Les limites de version supérieures entraînent l’échec de NuGet en cas de conflit. Par exemple, une bibliothèque accepte exactement 1.0, tandis qu’une autre bibliothèque nécessite 2.0 ou version ultérieure. Alors que les modifications importantes peuvent avoir été introduites dans la version 2.0, une dépendance de version stricte ou supérieure d’une limite garantit une erreur.

❌ PAS de références de packages NuGet sans version minimale.

❌ ÉVITEZ les références de package NuGet qui demandent une version exacte.

❌ ÉVITEZ les références de package NuGet avec une limite supérieure de version.

Pour plus d’informations, consultez Gestion des versions du package.

Packages NuGet à code source partagé

Une façon de réduire les dépendances de package NuGet externes consiste à référencer des packages sources partagés. Un package source partagé contient des fichiers de code source inclus dans un projet lorsqu’ils sont référencés. Étant donné que vous incluez simplement des fichiers de code source compilés avec le reste de votre projet, il n’existe aucune dépendance externe et risque de conflit.

Les packages sources partagés sont parfaits pour inclure de petits éléments de fonctionnalité. Par exemple, vous pouvez référencer un package source partagé de méthodes d’assistance pour effectuer des appels HTTP.

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

Les packages sources partagés présentent certaines limitations. Ils ne peuvent être référencés que par PackageReference, de sorte que les projets plus anciens packages.config sont exclus. En outre, les packages sources partagés sont utilisables uniquement par les projets avec le même langage. En raison de ces limitations, les packages sources partagés sont mieux utilisés pour partager des fonctionnalités au sein d’un projet open source.

✔️ ENVISAGEZ de référencer des packages sources partagés pour les petits éléments de fonctionnalité internes.

✔️ ENVISAGEZ de créer un package source partagé s’il fournit de petites fonctionnalités internes.

✔️ RÉFÉRENCER des packages à code source partagé avec PrivateAssets="All".

Ce paramètre indique à NuGet que le package doit être utilisé au moment du développement et ne doit pas être exposé en tant que dépendance publique.

❌ N’avez pas de types de package source partagés dans votre API publique.

Les types de sources partagées sont compilés dans l’assemblage de référence et ne peuvent pas être échangés au-delà des frontières d’assemblage. Par exemple, un type de source IRepository partagée dans un projet est un type distinct de la même source IRepository partagée dans un autre projet. Les types dans les paquets source partagés doivent avoir une visibilité internal.

❌ NE PAS publier de packages sources partagés sur NuGet.org.

Les packages sources partagés contiennent du code source et ne peuvent être utilisés que par des projets avec le même type de langage. Par exemple, un package source partagé C# ne peut pas être utilisé par une application F#.

Publiez des packages sources partagés dans un flux local ou MyGet pour les consommer en interne dans votre projet.