Référence DLL fichier 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 en cours de copie dans le dossier bin. Depuis que nous avons mis à niveau vers .NET 4 et Visual Studio 2010, cela ne se produit plus, et des erreurs de serveurs se produisent, car les références sont introuvables.
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 code XML dans le fichier de solution ressemble à ceci:
<Reference Include="DevExpress.SpellChecker.v11.1.Core,
Version=11.1.5.0,
Culture=neutral,
PublicKeyToken=b88d1754d700e49a,
processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
</Reference>
Considérant que MSBuild attend cela ci-dessous, de sorte que le fichier DLL sera inclus dans le déploiement:
<Reference Include="DevExpress.SpellChecker.v11.1.Core,
Version=11.1.5.0,
Culture=neutral,
PublicKeyToken=b88d1754d700e49a,
processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
<Private>True</Private>
</Reference>
L'astuce consiste à définir Copy Local sur False, enregistrer le projet puis le réinitialiser sur True - enregistrer à nouveau . Cela inclut correctement le nœud privé, respecté par MSBuild.
Il semble que la valeur par défaut pour ___NODE privé inclus (Copy Local) dans Visual Studio 2010 soit True, alors que MSBuild lit ce nœud manquant sous la forme False.
J'avais le même problème et plutôt que d'ajouter une étape "BeforeBuild", j'ai créé un test qui l'a simplement fait.
[TestMethod]
public void ReferenceAssemblyThatDoesNotCopyToBuildFolder()
{
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler referenceThisButDoNotUseIt = null;
}
Et cela corrige l'erreur. Le type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler ...' ne peut être résolu
Quelque chose de bizarre était arrivé à mon projet de déploiement. Quand j'ai vu qu'il n'y avait aucune dépendance détectée, j'ai supprimé la sortie principale et l'ajoutée de nouveau.
Les dépendances apparaissent maintenant et sont placées dans le dossier bin une fois installées.
Je devenais exactement le même problème. Nous avons un projet Visual Studio 2008 qui référence la bibliothèque EnterpriseLibrary. Lorsque nous exécutons notre version intégrée à l'aide de TFS et de notre projet de déploiement Web, tous les fichiers DLL sont copiés. Lors de la mise à niveau vers Visual Studio 2010, TFS 2010 et WDP 2010, il manquait certains fichiers DLL. Bizarrement, cela ne concerne que certains fichiers DLL et pas d’autres.
Par exemple, nous obtenons Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll copié dans les deux cas, mais pas Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll.
En guise de solution de contournement, 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’Assemblée avait été installée dans le GAC lors de l’installation d’une application tierce.
Si le fichier DLL se trouve dans le GAC, le compilateur ne se chargera pas de le copier dans le dossier de destination, à moins que vous ne le marquiez spécifiquement pour "copier en local" à l'aide du nœud "Privé" du fichier de projet, comme indiqué par Junte.
Le fait est que si vous n’ajoutez pas ce nœud, que vous développez sur une machine et que vous en construisez une autre, et que le fichier DLL est uniquement dans le GAC de la machine de construction, le comportement par défaut sans la commande privée Le noeud provoquera la copie correcte du fichier sur la machine de développement, mais pas sur la machine de construction.
Le problème le plus important est que le fichier DLL ne soit pas référencé directement, mais que le projet fasse référence à un deuxième projet qui à son tour fait référence au fichier DLL. Dans ce cas, vous ne pouvez pas marquer le fichier DLL comme "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 les projets finaux
- Re-signez le fichier DLL avec un nouveau nom fort, ce qui le différenciera du fichier DLL du GAC.
J'ai eu un problème similaire avec VS 2012 Express. J'ai utilisé les bibliothèques Tesseract dans mon projet. Tout a bien fonctionné jusqu'à ce que j'utilise ce projet dans une solution comportant plusieurs projets. Le problème était que certaines DLL (liblept168.dll, libtesseract302.dll) normalement placées dans des dossiers bin/debug/x86 ou bin/debug/x64 ont été copiées uniquement lorsque j'ai reconstruit la solution entière . Modification d'une seule ligne et création de cette dernière encore une fois causé que les DLL ont été supprimés et non copiés en arrière.
J'ai résolu ce problème en ajoutant une référence du projet qui crée les DLL manquantes pour le projet de démarrage.
Si votre projet ne charge pas directement la bibliothèque, il ne sera pas toujours déployé, même s'il est référencé explicitement! J'ai été dérouté parce que je pouvais le voir dans un répertoire Bin local, mais pas lorsqu'il était déployé. La dll dans le répertoire Bin était un ancien fichier qui n'avait pas été supprimé lors du nettoyage, raison pour laquelle j'ai été dérouté.
Un nettoyage et une reconstruction complets et ce n’est pas non plus dans mon dossier Bin local 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 l'ai configuré pour copier en sortie afin de m'assurer qu'il est déployé.
rzen et les autres, merci - vos commentaires ont conduit à une solution pour nous.
Nous avons un projet qui cible la version 10 des assemblys Microsoft.ReportViewer.Common.dll et Microsoft.ReportViewer.WebForms.dll (dossier "libs" séparé créé au niveau de "src"). Mais lorsque nous avons créé une version, la sortie incluait la version 12, qui avait été récemment installée sur le serveur de compilation.
En utilisant les commentaires ici, nous nous sommes assurés que 'Copy Local' était défini sur True et que l'indicateur était défini dans le fichier de projet. Cependant, la version 12 était toujours en cours de déploiement. Nous avons donc constaté que le truc était de s'assurer que la propriété "Version spécifique" était également définie sur les deux références. Voilà, la version 10 de chaque fichier est en cours de déploiement!
Il y avait beaucoup de joie.
JH
Nous pouvons utiliser le <Private>False</Private> pour ne pas copier les fichiers DLL référencés dans le répertoire bin. Cela est utile lorsque nous construisons 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.
Je ne sais pas comment cela a été configuré dans Visual Studio 2008, mais je suis presque certain que vous utilisiez peut-être la ligne de commande de l'événement Post-Build. Vous pouvez y copier les fichiers DLL dont vous avez besoin pour le déploiement. Un exemple est donné ci-dessous:
mkdir $(SolutionDir)\Deployment
copy "$(SolutionDir)Your_Library_Name\Your_Dll_ForDeployement.dll"
$(SolutionDir)\Deployment\
J'ai aussi rencontré un problème similaire dans lequel les dll référencées n'étaient pas copiées dans le dossier bin du dossier publié. J'utilisais une copie extraite TFS qui n'incluait pas le dossier bin dans l'application. -> Donc, juste inclus le dossier bin. -> Construit les applications référencées -> Publié le projet de site web Maintenant, je vois toutes les dll référencées dans bin dans le dossier publié
Je n'ai pas rencontré le même problème mais similaire. J'avais WPF projet principal et projet référencé où le référencé n'a pas été copié. J'ai constaté que dans mon cas, le projet principal était défini pour le profil de client NET 4.0 et 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)
Vérifiez la structure du projet dans lequel le fichier DLL a été référencé. Le framework devrait être .NET 4.0. S'il vous plaît corrigez-le si la structure est le profil du client.