Fichier DLL de référence ne copiant pas dans le bac avec le projet de déploiement provoquant une erreur

Nous avons plusieurs fichiers DLL externes référencés dans notre projet d’application Web. Nous avons un projet de déploiement à installer sur les serveurs d’hébergement. Lorsque nous utilisions .NET 3.5 et Visual Studio 2008, le fichier DLL était copié dans le dossier bin. Depuis que nous avons mis à niveau vers .NET 4 et Visual Studio 2010, cela ne se produit plus, et nous recevons des erreurs de serveurs car les références ne peuvent pas être trouvées.

CopyLocal est défini sur true et je ne trouve rien dans le fichier web.config qui suggère que cela est défini ailleurs.

Il y a un bogue dans Visual Studio 2010. Par défaut, le XML dans le fichier de solution ressemble à ceci:

 ..\References\DevExpress.SpellChecker.v11.1.Core.dll  

Considérant que MSBuild attend cela ci-dessous, de sorte que le fichier DLL sera inclus dans le déploiement:

  ..\References\DevExpress.SpellChecker.v11.1.Core.dll True  

L’astuce consiste à définir Copy Local sur False , enregistrer le projet et le réinitialiser sur Trueenregistrer à nouveau . Cela inclut le nœud privé correctement, que MSBuild respecte.

Il semble que la valeur par défaut pour aucun nœud privé inclus ( Copy Local ) dans Visual Studio 2010 est True , tandis que MSBuild lit ce nœud manquant comme False .

J’ai eu le même problème et plutôt que d’append une étape “BeforeBuild”, j’ai créé un test qui a simplement fait cela

  [TestMethod] public void ReferenceAssemblyThatDoesNotCopyToBuildFolder() { Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler referenceThisButDoNotUseIt = null; } 

Et cela a corrigé l’erreur Le type ‘Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler …’ ne peut pas être résolu

Quelque chose de bizarre était arrivé à mon projet de déploiement. Quand j’ai vu qu’il n’y avait pas de dépendances détectées, j’ai retiré le résultat principal et l’ai rajouté.

Les dépendances apparaissent maintenant et sont placées dans le dossier bin lorsqu’elles sont installées.

J’avais exactement le même problème. Nous avons un projet Visual Studio 2008 qui fait référence à EnterpriseLibrary. Lorsque nous exécutons notre version intégrée utilisant TFS et notre projet de déploiement Web, tous les fichiers DLL sont copiés. Lorsque nous avons effectué une mise à niveau vers Visual Studio 2010, TFS 2010 et WDP 2010, une partie du fichier DLL était manquante. Bizarrement, cela ne concerne que certains fichiers DLL et pas d’autres.

Par exemple, nous obtenons le Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll copié dans les deux cas, mais pas Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll.

Pour contourner ce problème, j’ai copié les fichiers en utilisant une étape “BeforeBuild”.

Il semble maintenant construire OK.

Je viens d’avoir le même problème et je voulais partager ce que j’ai trouvé car cela pourrait aider quelqu’un:

La raison dans mon cas était que l’assembly était installé dans le GAC lors d’une installation d’une application tierce.

Si le fichier DLL se trouve dans le GAC, le compilateur ne prendra pas la peine de le copier dans le dossier de destination, à moins que vous ne le marquiez spécifiquement comme “copie locale” en utilisant le noeud “Privé” du projet.

Le fait est que si vous n’ajoutez pas ce nœud, si vous développez sur un seul ordinateur et que vous le construisez sur un autre, et que le fichier DLL se trouve uniquement dans le GAC de la machine de génération, le comportement par défaut sans le nœud privé fichier à copier correctement sur la machine de développement, mais pas sur la machine de génération.

Le plus gros problème est si le fichier DLL n’est pas référencé directement, mais le projet référence un second projet qui à son tour fait référence au fichier DLL. Dans ce cas, vous ne pouvez pas marquer le fichier DLL comme étant “copie locale” dans le projet, car il n’est pas référencé par celui-ci. Donc, si le fichier DLL existe dans le GAC, il ne sera pas copié dans votre dossier de sortie.

Les solutions possibles à ce cas sont:

  • Désinstallez le fichier DLL du GAC
  • Ajouter une référence directe au fichier DLL dans le ou les projets finaux
  • Re-signer le fichier DLL avec un nouveau nom fort, ce qui le différenciera du fichier DLL dans le GAC.

Je n’ai pas rencontré le même problème mais similaire. J’ai eu projet principal WPF et projet référencé où le référencé n’a pas copié. J’ai trouvé que dans mon cas, le projet principal était défini pour le profil client NET 4.0 et le référencé pour NET 3.5. Lorsque j’ai défini le projet principal sur 3.5, la DLL compilée du projet référencé a commencé à copier. (Je ne sais pas pourquoi parce que je l’ai résolu par la pratique)

J’ai également rencontré un problème similaire où les DLL référencées n’étaient pas copiées dans le répertoire des dossiers publiés. J’utilisais une copie extraite de TFS qui n’incluait pas le dossier bin dans l’application. -> Il suffit donc d’inclure le dossier bin. -> Construit les applications référencées -> Publié le projet de site Web Maintenant, je vois tous les dll référencés dans bin dans le dossier publié

J’ai eu un problème similaire avec VS 2012 Express. J’ai utilisé des bibliothèques Tesseract dans mon projet. Tout a bien fonctionné jusqu’à ce que j’utilise ce projet dans une solution où il y avait plus d’un projet. Le problème était que certaines DLL (liblept168.dll, libtesseract302.dll) normalement placées dans les dossiers bin / debug / x86 ou bin / debug / x64 n’étaient copiées que lorsque je reconstruisais la solution entière. En changeant une seule ligne et en la recréant, les DLL ont été supprimées et non recopiées.

J’ai résolu ce problème en ajoutant une référence du projet qui crée des DLL manquantes au projet de démarrage.

rzen et autres, merci – vos commentaires nous ont permis de trouver une solution.

Nous avons un projet qui cible la version 10 des assemblys Microsoft.ReportViewer.Common.dll et Microsoft.ReportViewer.WebForms.dll (dossier séparé “libs” que nous avons créé au niveau “src”). Mais quand nous avons fait une compilation, la sortie incluait la version 12, qui a été récemment installée sur le serveur de compilation.

En utilisant les commentaires ici, nous nous sums assurés que «Copy Local» était défini sur True et que l’indicateur était défini dans le fichier de projet. Cependant, il était toujours en train de déployer la version 12. Ce que nous avons constaté, c’est que la propriété “Version spécifique” était également définie sur les deux références. Voila, la version 10 de chaque fichier est en cours de déploiement!

Il y avait beaucoup de joie.

JH

Si votre projet ne charge pas directement la bibliothèque, elle ne sera pas toujours déployée, même si elle est explicitement référencée! Je me suis trompé parce que je pouvais le voir dans un répertoire Bin local mais pas lors du déploiement. La DLL dans le répertoire Bin était un ancien fichier qui n’a pas été supprimé lors du nettoyage, ce qui explique pourquoi j’étais confus.

Un nettoyage complet et la reconstruction et ce n’était pas dans mon dossier Bin local non plus qui m’a montré le problème (je ne l’utilise que dans web.config). J’ai ensuite référencé le fichier dll lui-même dans le projet et mis en copie pour sortir pour être sûr qu’il soit déployé.

Je ne sais pas comment il a été configuré dans Visual Studio 2008, mais je suis presque certain que vous avez peut-être utilisé la ligne de commande de l’événement Post-Build. Vous pouvez y copier les fichiers DLL nécessaires au déploiement. Un exemple est donné ci-dessous:

 mkdir $(SolutionDir)\Deployment copy "$(SolutionDir)Your_Library_Name\Your_Dll_ForDeployement.dll" $(SolutionDir)\Deployment\ 

Nous pouvons utiliser le False pour ne pas copier les fichiers DLL référencés dans le répertoire bin . Ceci est utile lorsque nous créons des applications dans un serveur de génération TFS distinct où nous devons créer l’application et ne pas copier les fichiers DLL dans le répertoire bin .

Vérifiez le cadre du projet dans lequel le fichier DLL a été référencé. Le framework devrait être .NET 4.0. Veuillez le corriger si le cadre est le profil du client.