MSBuild ne copie pas les références (fichiers DLL) lors de l'utilisation de dépendances de projet dans la solution

Développement & Outils Pro Visual Studio & VS Code
1

MSBuild ne copie pas les références (fichiers DLL) lors de l’utilisation de dépendances de projet dans la solution

2

Je ne suis pas sûr de la raison pour laquelle c’est différent entre la compilation dans Visual Studio et MsBuild, mais voici ce que j’ai trouvé lorsque j’ai rencontré ce problème dans MsBuild et Visual Studio.

Explication

Pour un scénario d’exemple, disons que nous avons le projet X, l’assembly A et l’assembly B. L’assembly A référence l’assembly B, donc le projet X inclut une référence aux deux, A et B. De plus, le projet X contient du code qui référence l’assembly A (par exemple A.SomeFunction()). Maintenant, vous créez un nouveau projet Y qui référence le projet X.

La chaîne de dépendances ressemble donc à ceci : Y => X => A => B

Visual Studio / MSBuild essaie d’être intelligent et n’apporte dans le projet Y que les références qu’il détecte comme nécessaires pour le projet X ; il fait cela pour éviter la pollution des références dans le projet Y. Le problème est que, puisque le projet X ne contient en réalité aucun code qui utilise explicitement l’assembly B (par exemple B.SomeFunction()), VS/MSBuild ne détecte pas que B est nécessaire pour X, et donc ne le copie pas dans le répertoire bin du projet Y ; il ne copie que les assemblies X et A.

Solution

Vous avez deux options pour résoudre ce problème, les deux permettant de copier l’assembly B dans le répertoire bin du projet Y :

  • Ajouter une référence à l’assembly B dans le projet Y.

  • Ajouter du code factice dans un fichier du projet X qui utilise l’assembly B.

Personnellement, je préfère l’option 2 pour plusieurs raisons.

  • Si vous ajoutez un autre projet à l’avenir qui référence le projet X, vous n’aurez pas à vous souvenir d’inclure également une référence à l’assembly B (comme vous devriez le faire avec l’option 1).

  • Vous pouvez avoir des commentaires explicites expliquant pourquoi le code factice doit être là et ne doit pas être supprimé. Ainsi, si quelqu’un supprime le code par accident (par exemple avec un outil de refactoring qui cherche le code inutilisé), vous pouvez facilement voir dans le contrôle de source que le code est nécessaire et le restaurer. Si vous utilisez l’option 1 et que quelqu’un utilise un outil de refactoring pour nettoyer les références inutilisées, vous n’avez aucun commentaire ; vous verrez juste qu’une référence a été supprimée du fichier .csproj.

Voici un exempl

(Réponse tronquée)