Comment fonctionne Copy-local ?

Question

Je me demande ce que fait exactement copy-local=true pour les références. Copie-t-il l'assemblage 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 construis un assemblage de version de MyLogWrapper.dll avec la référence log4net.dll définie sur copy-local true. En référençant MyLogWrapper.dll à partir de MyProject avec copy local true, log4net.dll devrait être copié également, n'est-ce pas ? Je fais uniquement référence à MyLogWrapper.dll et à aucune de ses dépendances dans MyProject. log4net.dll n'est pas copié dans le répertoire de sortie de MyProject, mais toutes les autres dépendances de MyLogWrapper le sont. Quel pourrait être le problème ?

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

Answer 1

Malheureusement, il semble que, selon la déclaration suivante, tirée du site web de l Documentation MSDN la fonctionnalité CopyLocal ne fonctionne pas comme prévu pour les assemblages déjà présents 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 garantir le déploiement de l'assemblage. Désormais, vous devez ajouter manuellement l'assemblage à la section \Bin dossier. Tout le code personnalisé est ainsi passé au crible, ce qui réduit le risque de publier un code personnalisé avec lequel vous n'êtes pas familier.

Vous trouverez de plus amples informations à la page suivante, qui explique en détail le fonctionnement des références de projet.

MSDN : Références du projet

Answer 2

Après avoir posé cette question sur MSDN ici - il semble que ce comportement soit délibéré. "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 Copie locale."

Answer 3

Il existe une astuce : définissez la référence Copy Local sur false puis sur true, et Visual Studio ajoute automatiquement les métadonnées Private pour cette référence. Du moins, VS 2010 le fait. J'ai récemment fait cela 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, de sorte que nous avions des problèmes majeurs lors du déploiement de notre projet à partir du dossier TFS Drop. Cette astuce faux/vrai nous a sauvés.

Answer 4

Il faut se méfier de la copie locale, car elle m'a déjà piégé dans le passé !

Occasionnellement, pour un .dll particulier, il échoue silencieusement à le copier dans le dossier de construction. En général, cela n'apparaît pas sur une machine de développement car les dll sont souvent dans le GAC également (si vous avez installé un outil de développement / une bibliothèque que vous utilisez pour le développement) et vous ne le remarquez pas jusqu'à ce qu'il soit distribué / regroupé dans un installateur et que les fichiers requis manquent sur une machine cliente.

Il n'y a pas beaucoup d'informations sur ce bogue, mais ce fil de discussion le démontre pour une bibliothèque particulière : ici .

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 lorsque vous construisez, ou plus probablement lorsque vous faites un installateur, ou collectez des fichiers pour la distribution,

Answer 5

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

Dans votre cas, il se peut que la dll utilise l'autre dll et qu'elle en ait besoin également.