Comment Copy-local fonctionne-t-il? log4net.dll n'est pas copié dans le répertoire de sortie MyProject

Question

Je me demande ce que copy-local = true pour les références fait exactement. Copie-t-il l'assembly référencé avec toutes ses dépendances dans le répertoire de sortie? Mon scénario est le suivant: J'ai un wrapper de journal personnalisé qui utilise log4net. Je compile un ensemble de versions de MyLogWrapper.dll avec la référence log4net.dll définie sur copy-local true. Référencer MyLogWrapper.dll à partir de MyProject avec copie locale définie sur true devrait entraîner la copie de log4net.dll aussi bien? Je référence seulement MyLogWrapper.dll et aucune de ses dépendances dans MyProject. log4net.dll n'est pas copié dans le répertoire de sortie MyProject, mais toutes les autres dépendances de MyLogWrapper le sont. Quel pourrait être le problème?

J'ai fait plus d'expériences et il semble que si je supprime l'assembly (log4net.dll) de GAC, il commence à être copié localement. Quelqu'un peut-il confirmer que c'est le problème?

Answer 1

Lorsque la copie locale est définie sur true, elle copiera tous les attributs dont l'attribut local copy = tue dans le répertoire bin de l'application.

Dans votre cas, la DLL pourrait utiliser l'autre dll, donc elle l'exige également.

Answer 2

Vous devez être un peu méfiant de la copie locale car elle m'a attrapé dans le passé!

Parfois, pour un .dll particulier, il ne parviendra pas à le copier dans le dossier de construction. Habituellement, cela n'apparaît pas sur une machine de développement puisque les dll sont aussi souvent dans le GAC (si vous avez installé un outil de développement/bibliothèque que vous utilisez pour le développement) et que vous ne le remarquez pas avant d'être distribué/groupé dans un programme d'installation et les fichiers requis sont manquants sur un ordinateur client.

Il n'y a pas beaucoup d'informations sur ce bogue, mais ce fil le démontre pour une bibliothèque particulière: here. Ayant été pris par cela, je pense que c'est une bonne idée (généralement dans tous les cas) de savoir exactement quels assemblages sont requis par votre projet et d'avoir un script ou une action automatisée similaire qui assure que tous les composants requis sont présents, soit Après avoir construit, ou plus probable lorsque vous faites un programme d'installation, ou de recueillir des fichiers pour la distribution,

Answer 3

Après avoir posé cette question sur MSDN here - il semble que ce comportement est voulu par la conception. "Si vous déployez/copiez une application qui contient une référence à un composant personnalisé enregistré dans le GAC, le composant ne sera pas déployé/copié avec l'application, quel que soit le paramètre Copy Local."

Answer 4

Malheureusement, il semble que selon la déclaration suivante tirée du MSDN documentation la fonctionnalité CopyLocal ne fonctionne pas comme prévu pour les assemblages déjà dans le GAC.

Si vous déployez une application qui contient une référence à un composant personnalisé enregistré dans le GAC, le composant ne sera pas déployé avec l'application, quel que soit le paramètre CopyLocal. Dans les versions précédentes de Visual Studio, vous pouviez définir la propriété CopyLocal sur une référence pour vous assurer que l'assembly était déployé. Maintenant, vous devez ajouter manuellement l'assembly dans le dossier \ Bin. Cela met tout le code personnalisé sous surveillance, ce qui réduit le risque de publier du code personnalisé avec lequel vous n'êtes pas familier.

Plus d'informations peuvent être trouvées à la page suivante qui explique les détails sur le fonctionnement des références de projet.

MSDN: Project References

Answer 5

Il y a une astuce: définissez la copie de référence locale à false, puis de nouveau à vrai, et Visual Studio ajoute les métadonnées privé automatiquement cette référence. Au moins VS 2010 fait. J'ai récemment fait ceci pour résoudre un problème avec notre serveur TFS Build qui, pour une raison étrange, avait de nombreux composants Enterprise Library installés dans le GAC, donc nous avons eu des problèmes majeurs lors du déploiement de notre projet à partir du dossier TFS Drop. Ce truc faux/vrai nous a sauvés.

Answer 6

J'ai constaté que cela n'est plus respecté dans Visual Studio 2015 avec des références de projet si le projet référencé a une dépendance à un assembly GAC. L'assembly GAC est toujours copié dans la sortie du projet racine et la copie locale = false n'est respectée que pour la sortie du projet contenant la référence à la DLL GAC.

Connect feedback