Ajouter une référence à la DLL par rapport à l'ajout d'un package NuGet dans un projet .NET Standard

Question

J'ai un projet .NET Standard 2.0 dans ma solution et j'utilise l'interface IConfiguration. Lorsque j'écris le nom, VS suggère que je fasse référence à Microsoft.Extensions.Configuration.Abstractions.dll. Si je le fais, il est ajouté sous le nœud de référence. Cependant, je peux également l'ajouter en tant que package NuGet. Les deux façons semblent fonctionner. Je suppose que la référence suggérée par VS est ajoutée via le SDK .NET Standard référencé dans le projet.

Quelle est la méthode recommandée pour ajouter cette référence? Quels sont les avantages et les inconvénients de chaque approche?

Martin Ullrich · Accepted Answer

Référencer un DLL directement à partir d'un package NuGet téléchargé manuellement ou installé à un emplacement connu) peut accélérer le processus de restauration et de génération, mais présente quelques dangers.

Un package NuGet peut faire un certain nombre de choses lorsqu'il est référencé qu'un fichier DLL ne peut pas. Si vous voulez référencer un DLL à partir d'un package, faites assurez-vous que le package ne fait pas l'une des actions suivantes/compte pour les possibilités suivantes:

Des packages NuGet supplémentaires peuvent être extraits en tant que dépendances. Si vous mettez à niveau le DLL à partir d'un package plus récent, vous devez vérifier si les dépendances ont changé et mettre à jour le projet en conséquence.
Les packages NuGet peuvent fournir différents assemblages de référence et d'implémentation - par exemple un package NuGet peut donner une dll "surface API" dans son ref/ dossier, puis contiennent différents assemblys d'implémentation pour .NET Framework .NET Core, Xamarin et plus dans son lib/. dossier. Vous devez faire attention à sélectionner le bon fichier DLL à référencer pour le type de projet - une bibliothèque .NET Standard peut avoir besoin de référencer un ref-Assembly (par exemple ref/netstandard1.4/foo.dll pendant la compilation et une application .NET Framework qui utilise cette bibliothèque doit référencer l'assembly, par exemple lib/net452/foo.dll.
Les packages NuGet peuvent contenir des détails supplémentaires spécifiques à l'exécution et/ou du contenu spécifique au framework cible qui sont ajoutés à la sortie de la génération. Il peut s'agir de bibliothèques natives (.dll sur windows, .so sur linux etc. - à partir d'un runtime/ sous-dossier) ou tout fichier de contenu. Faire cela sans NuGet est délicat, car le .nuspec le fichier peut également définir des actions de génération pour les fichiers de contenu.
La logique de génération peut être incluse dans les packages NuGet qui définissent certaines propriétés ou exécutent des cibles pendant la génération qui est nécessaire pour que le produit soit utilisé correctement. Il est impossible de le faire manuellement sans modifier le .csproj fichier dans le bon sens.

Si le package NuGet n'utilise aucun des éléments ci-dessus (que vous devez vérifier manuellement), vous pouvez généralement référencer le DLL à la place. Cependant, la mise à jour du DLL et ses dépendances est beaucoup de travail et plus facile à faire avec NuGet.

En outre, vous avez mentionné que vous faites référence directement à partir du dossier de remplacement de nuget à partir de l'outillage .NET Core. Ce dossier n'est pas garanti pour contenir des versions spécifiques de DLL dans d'autres installations (selon les versions du SDK installées) et peut même être installé à un emplacement différent sur différentes machines, rendant votre fichier de projet inutilisable pour les autres personnes qui y travaillent (ainsi que pour construire sur des machines autres que Windows).