Comment Visual Studio détermine-t-il les éléments à copier dans le répertoire de sortie avec des solutions multi-projets?

Question

Disons que nous avons une solution avec la structure suivante:

• Project.DAL - couche d'accès aux données, dépend d'une bibliothèque de niveau inférieur, par exemple Oracle.DataAccess w/copie locale = true
• Project.BLL - couche logique métier, les références Project.DAL comme projet
• Project.UI - couche d'interface utilisateur, compile à l'exécutable, les références Project.BLL, par défaut projet

Lorsque Project.UI est compilé, VS est assez intelligent pour copier Project.DAL.dll dans le répertoire de sortie, mais il est pas assez intelligent pour comprendre que je voulais Oracle.DataAccess à copier à la sortie répertoire aussi bien pour la distribution aux clients.

Quelqu'un peut-il expliquer pourquoi c'est ainsi? Est-ce parce qu'il voit Oracle.DataAccess dans le GAC et suppose que les clients l'auront aussi dans le GAC? Ce n'est pas un gros problème, mais c'est un peu ennuyeux que chaque fois que j'ajoute une nouvelle référence d'assemblage, je dois me rappeler de la copier localement et ajouter un élément pour la copier dans mon script de construction.

Answer 1

Oui, Visual Studio copie d'une DLL dans le chemin de sortie dans l'une des deux conditions suivantes:

1. La DLL est explicitement référence avec CopyLocal = true
2. La DLL est référencée sans CopyLocal ou implicitement par une autre DLL et n'est pas dans le GAC

la raison pour laquelle il ne sera pas lorsque le fichier copie local référencé est dans GAC, est que lors de la résolution des noms d'assemblage du GAC a le plus avant ité, c'est-à-dire même si vous avez une copie locale (différente), la version du GAC sera utilisée.

Je vous suggère de configurer un répertoire de bibliothèque dans lequel vous placez tous les assemblys externes référencés. Ensuite, vous configurez un script MSBuild automatique sur un ordinateur (ou machine virtuelle) qui n'a pas le fichier Oracle gac'ed (ni Visual Studio installé dans ce but). De cette façon, le fichier sera copié dans la construction, et vous aurez plus de contrôle sur ce qui est fait que lorsque vous utilisez VS.

Answer 2

Encore une chose.

Lorsque vous ne pas utiliser la DLL référencé dans votre code du tout, il ignore les CopyLocal et ne copiera pas à votre répertoire de sortie.

Answer 3

J'ai eu une situation étrange où même si l'assembly était une référence de projet et était référencé avec "Copy Local" apparaissant comme "True" dans la fenêtre de propriétés de référence, la DLL n'était pas copiée dans le répertoire de sortie. J'avais une version antérieure de la DLL dans le GAC mais je ne voyais pas pourquoi cela devrait empêcher la DLL d'être copiée.

Je trouve que par le déchargement du projet et modifiant manuellement le XML de référence du projet comme suit:

<ProjectReference Include="..\SomeProject.csproj"> 
    <Project>{11111111-1111-1111-1111-111111111111}</Project> 
    <Name>Some Project Name</Name> 
    <Private>True</Private> 
</ProjectReference> 

La DLL a été copié dans le répertoire ouput comme prévu. J'ai trouvé que le simple paramétrage de Copy Local à True dans la fenêtre des propriétés signifiait que l'élément <Private> était complètement absent, mais dans le cas où il était défini sur false, il était présent avec la valeur "False".

Answer 4

@RenniePet Voici un lien vers un blog qui décrit la méthode RenniePet décrit dans un commentaire ci-dessus (si vous ne voulez pas modifier votre fichier de projet manuellement @Shaun suggéré):

http://blogs.msdn.com/b/jjameson/archive/2009/11/18/the-copy-local-bug-in-visual-studio.aspx