Impossible de charger le fichier ou l'assembly ou l'une de ses dépendances
J'ai un autre de ces problèmes "Impossible de charger le fichier, l'assembly ou l'une de ses dépendances".
Informations complémentaires: Impossible de charger le fichier ou l'assembly 'Microsoft.Practices.Unity, version = 1.2.0.0, Culture = neutre, PublicKeyToken = 31bf3856ad364e35' ou l'une de ses dépendances. La définition du manifeste de l'Assemblée localisée ne correspond pas à la référence de l'Assemblée. (Exception de HRESULT: 0x80131040)
Je n'ai aucune idée de ce qui cause ceci ou de la façon dont je pourrais le déboguer pour trouver la cause.
J'ai effectué une recherche dans les fichiers .csproj de mes catalogues de solutions et partout où j'ai l'Unity:
Référence Include = "Microsoft.Practices.Unity, Version = 2.0.414.0, Culture = neutre, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL"
Vous ne pouvez trouver aucune référence nulle part qui va à l'encontre de 1.2.0.0 dans aucun de mes projets.
Des idées sur la façon dont je devrais résoudre ce problème?
J'apprécierais également des astuces sur la façon de déboguer des problèmes comme celui-ci en général.
Vérifiez si vous faites référence à une assemblée qui fait référence à une ancienne version de l’unité. Par exemple, supposons que vous ayez un assemblage appelé
ServiceLocator.dllqui nécessite une ancienne version de Unity Assembly. Maintenant, lorsque vous faites référence à laServiceLocator, vous devez lui fournir l'ancienne version de Unity, ce qui rend le problème problématique.Peut-être le dossier de sortie où tous les projets construisent leurs assemblages, a une ancienne version de l’unité.
Vous pouvez utiliser FusLogVw pour savoir qui charge les anciens assemblys, il suffit de définir un chemin pour le journal et d'exécuter votre solution, puis de vérifier (dans FusLogvw) la première ligne où l'unité Unity est chargée, double-cliquez dessus et voyez l’appel d’appel, et vous voilà.
Ouvrez IIS Manager
Sélectionner des pools d'applications
puis sélectionnez la piscine que vous utilisez
aller aux paramètres avancés (à droite)
Définissez l'indicateur d'activation de l'application 32 bits false sur true.
Pour moi, aucune des autres solutions n'a fonctionné (y compris la stratégie de nettoyage/reconstruction). J'ai trouvé une autre solution de contournement qui consiste à fermer et ré-ouvrir Visual Studio.
J'imagine que cela oblige Visual Studio à recharger la solution et tous les projets, en revérifiant les dépendances du processus.
Essayez de nettoyer les dossiers Debug et Release dans votre solution. Ensuite, supprimez et ajoutez à nouveau l'unité.
À 99%, le impossible de charger le fichier, l'assembly ou l'une de ses dépendances est dû à des dépendances! Je vous suggère de suivre ces étapes:
Télécharger Dependency Walker à partir de http://www.dependencywalker.com/
Lancez Dependency Walker et ouvrez la dll (dans mon cas,
NativeInterfaces.dll)Vous pouvez voir une ou plusieurs dll avec l'erreur en rouge Erreur d'ouverture du fichier ...
![]()
Cela signifie que cette dll est manquante dans votre système; dans mon cas, le nom de dll est
MSVCR71.DLLVous pouvez télécharger les dll manquantes depuis google et les copier dans le chemin de droite (dans mon cas,
c:\windows\system32)A ce stade, vous devez enregistrer la nouvelle dll dans le GAC (Global Assembly Cache): ouvrez un terminal DOS et écrivez:
cd \Windows\System32 regsvr32 /i msvcr71.dllRedémarrez votre application!
La suite a fonctionné pour moi.
- Supprimer les fichiers temporaires C:\Windows\Microsoft.NET\Framework\v4.0.30319\Fichiers ASP.NET temporaires
- Fermez VSTS et ouvrez à nouveau
- Supprimer et ajouter les mêmes DLL (Remarque: vous ajoutez les mêmes versions correspondantes)
Vérifiez le fichier Web.config/App.config dans votre projet. Voir si les numéros de version sont corrects.
<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />
Cela a fonctionné pour moi.
Microsoft Enterprise Library (référencée par .NetTiers) était notre problème, qui faisait à son tour référence à une version plus ancienne de Unity. Afin de résoudre le problème, nous avons utilisé la redirection de liaison suivante dans le fichier web.config:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Sinon, vous pouvez simplement mettre à jour l'Enterprise Library vers la dernière version.
Malgré la question initiale posée il y a 5 ans, le problème persiste et est plutôt agaçant.
La solution générale est une analyse approfondie de tous les assemblages référencés pour comprendre ce qui ne va pas. Pour faciliter cette tâche, j'ai créé un outil (une extension Visual Studio) qui permet de sélectionner un assemblage .Net (fichier .ddl ou .exe) et d'obtenir un graphique de tous les assemblys référencés avec des références en conflit ou manquantes en surbrillance.
Cet outil est disponible dans Visual Studio Gallery: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734
Exemple de sortie: 
Dans l'explorateur de solutions, cliquez avec le bouton droit de la souris sur le projet (et non sur la solution). Dans l'onglet Construction, choisissez Cible de la plate-forme: "Tout processeur".
J'ai eu le même problème. ** La réponse de Juntos est correcte ** mais vous devriez noter un conseil important!
Pour l'unité 2.1.505.2 différent AssemblyVersion et AssemblyFileVersion sont spécifiés:
AssemblyFileVersion est utilisé par nuget mais CLR ne s'en soucie pas! CLR utilisera uniquement AssemblyVersion !
Les redirections doivent donc être appliquées à une version spécifiée dans AssemblyVersion: 2.1.505.0
<assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
<assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>
Voir aussi: Quelles sont les différences entre AssemblyVersion, AssemblyFileVersion et AssemblyInformationalVersion?
J'ai aussi eu cette terrible erreur et trouvé une solution pour ça ...
- Clic droit sur le nom de la solution
- Cliquez sur Nettoyer la solution
- Redémarrer Visual Studio
- Aller au projet Propriétés >> Construire
- Modifiez la configuration en relâchez
- Démarrer le débogage (F5)
1), 2)
4), 5)
J'espère que cela vous aidera aussi.
- Goto: Solution -> Package
- Cliquez sur Avancé Onglet (Trouvez ci-dessous la page)
- Ajoutez votre dll à des assemblys supplémentaires (de cette façon, nous pouvons ajouter des dll externes dans sharepoint).
Dans mon cas, dans le dossier bin, il y avait une dll non référencée appelée Unity.MVC3. J'ai essayé de chercher n'importe quelle référence à ceci dans Visual Studio sans succès. Ma solution était si simple que de supprimer cette dll du dossier bin.
Merci Riddhi M. La suite a travaillé pour moi.
Supprimer les fichiers temporaires C:\Windows\Microsoft.NET\Framework\v4.0.30319\Fichiers ASP.NET temporaires Fermez VSTS et ouvrez à nouveau Supprimez et ajoutez les mêmes DLL (Remarque: vous ajoutez les mêmes versions correspondantes)
Je ne sais pas si cela pourrait aider.
Vérifiez que le nom de l'assembly et l'espace de nommage par défaut dans les propositions de vos assemblys correspondent. Cela a résolu mon problème qui a généré la même erreur.
Vous dites que votre solution contient beaucoup de projets ... commencez par un projet situé en haut de l'ordre de génération. Faites-le construire et une fois que vous l'aurez compris, vous pourrez appliquer le même correctif au reste d'entre eux.
Honnêtement, vous avez probablement juste besoin d’actualiser votre référence. Il semble que vous ayez mis à jour votre version sans mettre à jour les références ou que le problème de chemin relatif vous empêche de conserver votre solution dans le contrôle de source. Il suffit de vérifier vos hypothèses et d'ajouter de nouveau la référence.
Ce problème m'est arrivé lorsqu'une de mes bibliothèques dépendantes compilait un DLL avec "Any CPU" (Tout processeur) alors que la bibliothèque parente attendait une compilation de "x64".
Dans mon cas, aucune des réponses proposées n'a fonctionné.
Voici ce qui a fonctionné pour moi:
- Supprimer la référence
- Renommez la DLL
- Importer à nouveau la référence
La deuxième étape était importante apparemment car elle ne fonctionnait pas sans elle.
I "Définir comme projet de démarrage" la bibliothèque/le projet non chargé/non trouvé.
Puis déployé.
Ça a marché!
Je pense qu'il n'a pas pu trouver le fichier .dll car il ne figurait pas à l'Assemblée au début.
La suite a fonctionné pour moi.
- Supprimer les fichiers temporaires C:\Windows\Microsoft.NET\Framework\v4.0.30319\Fichiers ASP.NET temporaires
- puis cliquez avec le bouton droit sur Fichiers Asp.net temporaires> Propriétés> Sécurité et accordez un contrôle total à IIS et à tous les utilisateurs exécutant mon projet.
Vous devez supprimer votre fichier appname.dll de votre dossier de sortie. Nettoyer les dossiers de débogage et de libération. Reconstruisez et copiez dans le dossier de sortie le fichier dll régénéré.
Ma solution pour .NET 4.0, à l'aide d'Enterprise Library 5, consistait à ajouter une référence à:
Microsoft.Practices.Unity.Interception.dll
Pour moi, reconstruire le jeu de l'unité sans les projets Unity C # Checkmark a fonctionné.
J'avais ceci aujourd'hui, et dans mon cas, le problème était très étrange:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
</dependentAssembly>0.
Notez les caractères parasites à la fin du XML - ceux-ci ont en quelque sorte été déplacés du numéro de version à la fin de ce bloc XML!
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
</dependentAssembly>
Changé à ce qui précède et le tour est joué! Tout a encore fonctionné.
Une autre cause possible: assurez-vous que vous n'avez pas accidentellement attribué le même nom d'assembly aux deux projets dans les propriétés du projet.
Essayez de vérifier si la propriété "Copier en local" pour la référence est définie sur true et que la version spécifique est définie sur true. Ceci est pertinent pour les applications dans Visual Studio.
Attention aux références contradictoires. Même après un nettoyage et une reconstruction, les références en conflit poseront toujours un problème. Mon problème était entre AForge et Accord. J'ai supprimé les deux références et rajouté les références en choisissant à nouveau la référence particulière (propre à mon cas, juste Accord).
J'ai continué à avoir cette erreur sur mon projet de formulaires Web dans Visual Studio 2015. J'ai arrêté Visual Studio et j'ai tué le ScriptedSandbox64.exe, Microsoft.VsHub.Server.HttpHostx64.exe, Microsoft.VsHub.Server.HttpHostx.exe * 32, Microsoft. .VisualStudio.Web.Host.exe * 32 processus et il semblait aider à résoudre le problème.
si vous recevez ce message d'erreur en ouvrant une application sur votre Windows XP, cela signifie d'abord que vous avez installé cette application car elle ne fonctionne pas sans Net Framework 4 et le Service Pack 3. vous avez installé à la fois et à nouveau vous obtenez cette erreur afin que vous deviez réinstaller cette application mais désinstallez d'abord de ajouter et supprimer
si cela ne fonctionne pas s'il vous plaît ne pas abuser de moi. je suis aussi un junior
OK, cela peut paraître très stupide, mais voici comment j'ai résolu le problème après avoir essayé toutes les autres solutions et passé une nuit sur cette chose stupide.
La même erreur se produisait avec un fichier DLL manquant dans le dossier Bin. J'ai essayé de supprimer, de tout récupérer de Team Foundation Server, mais je n'ai pas fonctionné. Vous avez une copie du dossier Bin de ma machine de bureau et je l’ai remplacée. Cela n'a pas fonctionné non plus. Enfin, j'ai manuellement envoyé un serveur FTP à un serveur, obtenu la copie de DLL qui apparaissait comme manquante, puis il a commencé à afficher que le fichier suivant de la séquence de la liste de fichiers était manquant.
Donc, j'ai ftped server Got tous les dossiers Bin, manuellement remplacer chaque fichier un par un. (Pas Ctrl + Tous et remplacer .. j'ai essayé: cela n'a pas fonctionné.) Et de toute façon cela a fonctionné ...
Ma solution était:
J'ai un application à trois niveaux et j'ai oublié de copier le DLL également sur le chemin de droite sous IIS. Juste après l'avoir copiée au bon endroit, cela a fonctionné pour moi.
Pour moi, il semble que Nuget ne jouait pas à Nice avec mon projet/solution. J'ai utilisé Nuget pour installer NewtonSoft.Json. Le fichier projet semblait le référencer correctement. Lorsque j'ai cliqué sur le nom de la DLL dans l'explorateur de solutions/Dépendances/Nuget, puis cliqué sur Propriétés, j'ai découvert que la DLL existait à l'endroit où les propriétés l'indiquaient. .
J'ai supprimé le paquet Nuget, puis j'ai cliqué sur Projet> Ajouter> Référence et consulté la dll dans un répertoire de paquets lorsqu'un processus Nuget ancien l'avait installé, puis la solution a fonctionné correctement.
REMARQUES: cette solution est un véritable rituel, commençant par une solution Xamarin.iOS et ajoutant un projet .netstandard (c’est là que j’ai eu de la difficulté à utiliser Nuget). Il existe également un projet "portable" dans la solution. J'ai hérité de tout cela d'un développeur qui est parti depuis 3 ans. Ha ha.
J'ai eu ce problème, l'erreur était en réalité très stupide. J'avais spécifié le mauvais emplacement pour le fichier .dll, après avoir modifié l'emplacement pour corriger l'emplacement, le chargement s'est déroulé correctement (réponse afin que quelqu'un d'autre ne commette pas cette erreur).
J'ai eu le même problème je l'ai résolu via les instructions ci-dessous:
- ouvrez le menu Outils et sélectionnez l'option
- dans les options, la fenêtre va à Projets et solutions/Projets Web
- vérifier
use the 64bit version of IIS ...
