Copier les dépendances d’une DLL dans Visual Studio

Comment configurer un projet dans Visual Studio pour copier les DLL tierces dont l’une des références du projet dépend?

J’ai un projet d’application principal et une DLL de bibliothèque de classes. L’application principale fait référence à la DLL de bibliothèque de classes et la DLL elle-même fait référence à des DLL tierces. Lorsque je comstack l’application principale, elle copie automatiquement la DLL de la bibliothèque de classes dans son répertoire de sortie, mais ne copie pas les DLL tierces.

Je ne souhaite pas append de références aux DLL tierces du projet d’application principal car l’application principale ne les utilise pas, elles sont uniquement utilisées par la bibliothèque de classes.

Vous pouvez y parvenir avec la fenêtre de propriétés du projet. Visual Studio vous permet de définir des événements à effectuer avant ou après la création. Pour accéder à la fenêtre des propriétés du projet, cliquez avec le bouton droit sur votre projet dans la fenêtre de l’explorateur de solutions et cliquez sur «propriétés». Du côté gauche, accédez à l’onglet “créer des événements”.

Dans la zone de post-construction, tapez quelques commandes de copie. Par exemple:

copy "$(SolutionDir)mydll.dll" "$(TargetDir)" 

$(SolutionDir) et $(TargetDir) sont tous deux des variables prédéfinies. La syntaxe standard est la suivante:

 copy "source directory and file name" "destination directory" 

Si vous cliquez sur le bouton ‘edit post build …’, une boîte $(TargetDir) une liste de ces variables prédéfinies que vous pouvez insérer (comme $(SolutionDir) et $(TargetDir) ) $(TargetDir) .

En outre, il s’agit d’un processus utile pour copier d’autres fichiers, tels que des fichiers de configuration personnalisés, des images ou toute autre dépendance de votre projet.

Le fragment suivant fonctionne pour moi:

  ...   Always   ...  

Cela fonctionne pour C #. Pour C ++ natif, il copie toujours la DLL dans le dossier de sortie, mais cette dépendance n’est pas visible dans Visual Studio, elle doit être modifiée directement dans le fichier de projet.

Pour tester un exemple non sortingvial, j’ai essayé de lancer le projet C # Un projet qui dépend du projet C ++ natif B. Les projets B dépendent de dll C natif tiers – cette dépendance est implémentée via fragment ci-dessus dans le fichier projet. Lorsque je construis A, C est copié dans un dossier binary.

Je l’ai essayé dans Visual Studio 2010.

Jetez un oeil à cette solution fournie par Alex Yakunin http://blog.alexyakunin.com/2009/09/making-msbuild-visual-studio-to.html Cela a très bien fonctionné pour moi – le scénario étant que les bibliothèques DevExpress étaient utilisées expressément d’autres dépendances qui ont causé des problèmes lors de leur déploiement)

  • Note 1: Visual Studio 2010 semble append des dll référencés automatiquement, cependant msbuild ne l’a pas fait. La solution d’Alex a donc fonctionné puisque les scripts de version utilisaient msbuild.
  • Note 2: Il fallait également s’assurer que pour les bibliothèques référencées (celles qui étaient référencées dans le code), copy-local était réellement défini sur True dans le csproj, même si l’explorateur de solutions le disait. Le meilleur moyen est de définir copy-local = False, Save, set copy-local = True, Save.

Ces deux étapes – copy-local = true pour les bibliothèques référencées et l’ajout de cibles msbuild pour les références indirectes ont automatisé la configuration de la construction pour moi.

Je ne recommanderais pas cela. Vous vous retrouvez avec une explosion N ^ 2 du nombre d’assemblages copiés (et potentiellement en cours de reconstruction). Si possible, vous devriez faire en sorte que tous vos projets placent leurs assemblages dans le même $ (OutDir). Si vous utilisez TFS, Team Build le fait pour vous.

Accédez à l’application principale, aux références, à votre référence de bibliothèque de classes.

Définissez “Copier local” sur True.

Il va maintenant copier le répertoire bin de votre bibliothèque de classes dans le répertoire bin de l’application principale. Y compris les DLL tierces de sous-dépendance.

Je n’aime pas avoir mes fichiers de dépendance situés dans le dossier racine du projet mais dans un sous-dossier. Mais les fichiers doivent être placés dans le dossier racine du dossier de compilation.

Mes événements de construction ressemblent à ceci:

entrer la description de l'image ici

entrer la description de l'image ici

entrer la description de l'image ici

  Command: call xcopy /S /Y "$(SolutionDir)Dependencies\*.*" "$(TargetDir)" 

Dans le cas où “Dependencies” contient également des sous-dossiers, comme le mien.

100% sûr que cela fonctionnera. Remplacez simplement dll par votre référence personnelle. fichier

  ..\..\..\3rdParty\Extended WPF Toolkit-2.2.1\Xceed.Wpf.Toolkit.dll Always False   Xceed.Wpf.Toolkit.dll Always False  

Je ne suis pas vraiment au courant d’aucune façon de faire cela en plus d’append une référence à ladite .dll dans le projet lui-même. Nous avons vu cela dans certains de nos propres projets ici, et la seule solution que nous avons trouvée est d’append la référence. Je veux dire que l’un de nos développeurs a fait des recherches et a trouvé que c’était la seule solution, mais ne me citez pas à ce sujet.