La DLL dépendante n'est pas copiée dans le dossier de sortie de la compilation dans Visual Studio.

Question

J'ai une solution Visual Studio. J'ai plusieurs projets dans cette solution. Il y a un projet principal qui agit comme le démarrage et utilise d'autres projets. Il y a un projet appelé "ProjectX". Sa référence est ajoutée au projet principal. Le ProjectX fait référence à une autre dll .NET (disons abc.dll) qui ne fait pas partie de la solution.

Maintenant, cette abc.dll devrait être copiée dans le dossier bin/debug du projet principal, mais elle n'y est pas copiée. Pourquoi n'est-elle pas copiée, y a-t-il des raisons connues ?

Answer 1

Je ne sais pas si cela peut vous aider, mais pour moi, il arrive souvent que je fasse référence à une DLL (ce qui l'ajoute automatiquement au dossier bin, bien sûr). Cependant, cette DLL peut avoir besoin de DLL supplémentaires (en fonction des fonctions que j'utilise). Je ne veux PAS les référencer dans mon projet car elles doivent simplement se retrouver dans le même dossier que la DLL que j'utilise réellement.

Je réalise cela dans Visual Studio en "ajoutant un fichier existant". Vous devriez pouvoir l'ajouter n'importe où, sauf dans le dossier Add_data. Personnellement, je l'ajoute simplement à la racine.

Puis changez les propriétés de ce fichier en ...

Build Action = None (si cette valeur est définie sur quelque chose comme Content, la version "Root" est en fait copiée dans la racine, et une copie est placée dans la corbeille).

Copy to output folder = Copy if Newer (En fait, il est placé dans le dossier BIN seulement s'il est manquant, mais ne le fait pas après).

Lorsque je publie mes DLL ajoutées n'existent que dans le dossier BIN et nulle part ailleurs dans l'emplacement de publication (ce qui est ce que je veux).

Answer 2

Vous pouvez également vérifier que les DLLs que vous recherchez ne sont pas incluses dans le GAC. Je crois que Visual Studio fait preuve d'intelligence en ne copiant pas ces fichiers s'ils existent déjà dans le GAC sur la machine de construction.

J'ai récemment été confronté à une situation où je testais un paquet SSIS qui nécessitait l'existence d'assemblages dans le GAC. Je l'avais oublié depuis et je me demandais pourquoi ces DLL ne sortaient pas lors d'une construction.

Pour vérifier ce qui se trouve dans le GAC (à partir d'une invite de commande de Visual Studio Developer) :

gacutil -l

Ou la sortie vers un fichier pour en faciliter la lecture :

gacutil -l > output.txt
notepad.exe output.txt

Pour retirer un assemblage :

gacutil -u MyProjectAssemblyName

Je dois également noter qu'une fois que j'ai supprimé les fichiers du GAC, ils ont été correctement affichés dans la fenêtre de l'éditeur. \bin après une construction (même pour les assemblages qui n'étaient pas directement référencés dans le projet Root). Ceci s'est produit avec Visual Studio 2013 Update 5.

Answer 3

Si vous faites un clic droit sur l'assemblage référencé, vous verrez une propriété appelée Copie locale . Si l'option Copie locale est définie sur true, alors l'assemblage doit être inclus dans le bac. Cependant Il semble qu'il y ait un problème avec Visual Studio, qui parfois n'inclut pas la dll référencée dans le dossier bin... voici la solution de rechange qui a fonctionné pour moi :

Answer 4

Assurez-vous que la DLL dépendante que vous utilisez n'a pas une cible .NET Framework supérieure à la cible .NET Framework de l'application de votre projet.

Vous pouvez vérifier cela en sélectionnant votre projet, puis en appuyant sur ALT + ENTER Sélectionnez ensuite Application dans la partie gauche, puis sélectionnez Target Framework de votre projet.

Supposons, DLL dépendant Target Framework = 4.0 et Application DLL Target Framework = 3.5, alors changez-le en 4.0.

Merci !

Answer 5

Question :

J'ai rencontré un problème similaire pour une DLL de paquet NuGet (Newtonsoft.json.dll) où la sortie de compilation n'inclut pas la DLL référencée. Mais la compilation se déroule bien.

Fixe :

Parcourez vos projets dans un éditeur de texte et recherchez les références contenant des balises "Private". Comme Vrai ou Faux. "Private" est un synonyme de "Copy Local". Quelque part dans les actions que MSBuild prend pour localiser les dépendances, il trouve votre dépendance ailleurs et décide de ne pas la copier.

Il faut donc passer en revue chaque fichier .csproj/.vbproj et supprimer les balises manuellement. Reconstruisez, et tout fonctionne à la fois dans Visual Studio et dans MSBuild. Une fois que cela fonctionne, vous pouvez revenir en arrière et mettre à jour les balises là où vous pensez qu'elles doivent être.

Référence :

https://www.paraesthesia.com/archive/2008/02/13/what-to-do-if-copy-local-works-in-vs-but.aspx/