Impossible de charger le fichier ou l'assembly ou l'une de ses dépendances

238

Je rencontre un autre de ces problèmes «Impossible de charger le fichier ou l'assembly ou l'une de ses dépendances».

Informations supplémentaires: Impossible de charger le fichier ou l'assembly «Microsoft.Practices.Unity, Version = 1.2.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35» ou l'une de ses dépendances. La définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly. (Exception de HRESULT: 0x80131040)

Je n'ai aucune idée de ce qui cause cela ou comment je pourrais le déboguer pour trouver la cause.

J'ai effectué une recherche dans mes fichiers de catalogues de solutions .csproj, et partout où j'ai Unity, j'ai:

Référence Inclure = "Microsoft.Practices.Unity, Version = 2.0.414.0, Culture = neutre, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL"

Je ne trouve 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 de résoudre ce problème?

J'apprécierais également des conseils sur la façon de déboguer des problèmes comme celui-ci en général.

ronag
la source
1
L'un de vos assemblys référencés pourrait-il utiliser des éléments de l'ancienne Unitybibliothèque?
décyclone
3
Probablement ... mais comment puis-je trouver quels assemblages? J'ai beaucoup de projets dans ma solution et beaucoup de suspects potentiels ... les essais et les erreurs de bruteforce semblent un peu désespérés ...
ronag
3
Ce n'est pas la référence de l'assembly, vous faites référence à la version 2.0. Mais à l'exécution, le CLR trouve 1.2, une ancienne version. Si vous ne voyez pas cette ancienne DLL dans votre répertoire de génération, utilisez Fuslogvw.exe pour savoir comment le CLR a trouvé cette ancienne copie.
Hans Passant
2
Regardez le dossier bin de votre projet et voyez si la DLL de votre projet a un conflit dans son nom. Supprimez simplement celui-ci, puis reconstruisez votre solution. Cela a fonctionné pour moi.
coggicc
11
"ou l'une de ses dépendances" est la partie qui m'agace vraiment. S'il ne peut pas charger "l'une de ses dépendances", l'erreur doit indiquer quelle "une de ses dépendances" ne peut pas être chargée. La forme actuelle est inutile, cela pourrait tout aussi bien dire ne peut pas charger le truc
Paul McCarthy

Réponses:

116
  1. Vérifiez si vous faites référence à un assemblage qui, à son tour, fait référence à une ancienne version d'unité. Par exemple, supposons que vous ayez un assembly appelé ServiceLocator.dllqui nécessite une ancienne version de l'assembly Unity, maintenant lorsque vous référencez le, ServiceLocatorvous devez lui fournir l'ancienne version de Unity, et cela pose problème.

  2. Peut être le dossier de sortie où tous les projets construisent leurs assemblages, a une ancienne version d'unité.

Vous pouvez utiliser FusLogVw pour savoir qui charge les anciens assemblys, définir simplement un chemin pour le journal et exécuter votre solution, puis vérifier (dans FusLogvw) la première ligne où l'assemblage Unity est chargé, double-cliquer dessus et voir l'appel assemblage, et c'est parti.

Nour Sabouny
la source
6
Où est le fichier journal de FuseLogVw
Stiger
1
Pour éviter d'avoir à trouver le fichier journal, vous pouvez spécifier un chemin de journal personnalisé: Paramètres, cochez la case Activer le chemin de journal personnalisé, entrez un chemin de journal personnalisé, actualisez.
RedGreenCode
82

Ouvrez IIS Manager

Sélectionnez les pools d'applications

puis sélectionnez la piscine que vous utilisez

aller aux paramètres avancés (à droite)

Modifiez le drapeau de l'option Activer l'application 32 bits false sur true.

kranthi
la source
IIS -> sélectionnez chaque ApplicationPool -> Paramètres de base -> vérifiez si le dernier framework est sélectionné dans la liste déroulante ".NET Framework version"
Martin
Vous pouvez également cliquer avec le bouton droit sur votre projet dans VS. et supprimez la coche
préférée de
Merci. Ça a marché. Eh bien, c'était déjà vrai dans mon cas, juste pour essayer. Je l'ai fait faux et cela a fonctionné.
meekash55
Lorsque j'ai fusionné un projet d'un serveur à un autre, ce drapeau était en effet à nouveau faux, merci pour la solution!
Appsum Solutions
69

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 à rouvrir Visual Studio .

Je suppose que cela oblige Visual Studio à recharger la solution et tous les projets, en revérifiant les dépendances dans le processus.

Robotnik
la source
33
Si vous ne croyez pas que cela fonctionnera, essayez au moins. Je ne pouvais pas y croire moi-même avant de l'avoir fait.
Ben Cull
3
😍😍😍😍😍😍😍😍😍😍😍 A travaillé pour moi
Devidas M Das
48

Essayez de nettoyer les dossiers Debug et Release dans votre solution. Ensuite, supprimez et ajoutez à nouveau l'unité.

Aleksei Anufriev
la source
3
Ce problème peut être dû à beaucoup de choses ... votre solution a résolu mes problèmes et pourrait également en résoudre d'autres.
Scott Rippey
1
@ScottRippey Cela a fonctionné pour moi. J'ai d'abord supprimé tous les fichiers .pdb, puis j'ai rechargé mon projet et je l'ai reconstruit.
botenvouwer
21

À 99%, le problème Impossible de charger le fichier ou l'assembly ou l'un de ses problèmes de dépendances est dû à des dépendances! Je vous suggère de suivre ces étapes:

  1. Téléchargez Dependency Walker sur http://www.dependencywalker.com/

  2. Lancez Dependency Walker et ouvrez la DLL (dans mon cas NativeInterfaces.dll)

  3. Vous pouvez voir une ou plusieurs DLL avec l'erreur en rouge Erreur d'ouverture du fichier ...

  4. Cela signifie que cette DLL est manquante dans votre système; dans mon cas, le nom de la DLL estMSVCR71.DLL

  5. Vous pouvez télécharger la dll manquante de google et la copier dans le bon chemin (dans mon cas c:\windows\system32)

  6. À 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.dll
  7. Redémarrez votre application!

Stefano Lonati
la source
22
L'outil de gestion des dépendances est excellent, mais la copie de DLL aléatoires d'Internet vers Windows est ... moins efficace. Il vaut mieux essayer de trouver le programme d'installation qui fournit ces DLL.
RJFalconer
J'ai obtenu quelques fichiers ( API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL) introuvables et m'a conduit à cette question de stackoverflow . Fondamentalement, gardez à l'esprit qu'il pourrait s'agir de faux positifs pour certains fichiers, le lien fournit plus de détails.
cheriejw
16

Microsoft Enterprise Library (référencé par .NetTiers) était notre problème, qui faisait à son tour référence à une ancienne version de Unity. Afin de résoudre le problème, nous avons utilisé la redirection de liaison suivante dans le 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>

Alternativement, vous pouvez simplement mettre à jour la bibliothèque d'entreprise vers la dernière version.

Rebecca
la source
16

La suite a fonctionné pour moi.

  • Supprimer les fichiers temporaires C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Fichiers ASP.NET temporaires
  • Fermer VSTS et rouvrir
  • Supprimer et ajouter les mêmes DLL (Remarque: vous ajoutez les mêmes versions correspondantes)
Riddhi M.
la source
15

Vérifiez le fichier Web.config / App.config dans votre projet. Vérifiez 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.

Jaseem Abbas
la source
2
Cela a fonctionné pour moi bien que ce soit web.config, pas app.config
samneric
15

Malgré la question initiale publiée il y a cinq ans, le problème persiste et est plutôt ennuyeux.

La solution générale est une analyse approfondie de tous les assemblys 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 assembly .NET (un .dllou un .exefichier) pour obtenir un graphique de tous les assemblys référencés tout en mettant en évidence les références conflictuelles ou manquantes.

L'outil est disponible dans la galerie Visual Studio: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

Exemple de sortie: entrez la description de l'image ici

marss19
la source
Ne fonctionne pas avec les éditions communautaires de Visual Studio
Draex_
Je pense qu'il devrait y avoir un autre problème, non lié à l'édition de Visual Studio. J'ai testé l'extension sur les éditions communautaires VS 2017 et VS 2015. En fait, il a été développé au moyen de l'édition communautaire VS 2017.
marss19
Aha. Avez-vous installé d'autres extensions? Cette page indique que DGML n'est pas pris en charge dans la communauté VS: msdn.microsoft.com/en-us/library/hh871439.aspx#VersionSupport
Draex_
1
Il n'y a pas d'outils d'architecture dans l'édition communautaire, mais l'éditeur DGML lui-même est disponible. Vous pouvez l'installer en sélectionnant "Installer l'éditeur DGML" sous "Composants individuels" -> "Outils de code" via Visual Studio Installer -> Modifier
marss19
11

capture d'écranDans l'explorateur de solutions, faites un clic droit sur le projet (pas la solution), dans l'onglet de construction, choisissez la cible de la plate-forme: "N'importe quel CPU".

Engin Aydogdu
la source
Après avoir vérifié le pool d'applications, «Activer les applications 32 bits» a été défini sur Faux, mais ma cible de plate-forme était x86. Le changer en Any CPU OR x64 a résolu mon problème.
Keith Ketterer
11

La réponse de Juntos est correcte mais vous devez également considérer:

Pour l'unité v2.1.505.2, différents attributs AssemblyVersion et AssemblyFileVersion sont spécifiés:

entrez la description de l'image ici

AssemblyFileVersion est utilisé par NuGet mais CLR s'en fiche! CLR va utiliser uniquement AssemblyVersion !

Vos redirections doivent donc être appliquées à une version spécifiée dans l' attribut AssemblyVersion . Donc 2.1.505.0 devrait être utilisé

<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?

Ievgen Naida
la source
6

J'ai également eu cette terrible erreur et j'ai trouvé une solution à cela ...

  1. Clic droit sur le nom de la solution
  2. Cliquez sur Clean Solution
  3. Redémarrez Visual Studio
  4. Aller au projet Propriétés >> Construire
  5. Modifier la configuration pour libérer
  6. Démarrer le débogage (F5)

1), 2)

Clic droit sur le nom de la solution

4), 5)

Modifier la configuration pour libérer

J'espère que cela vous aidera également.

Roshana Pitigala
la source
5
  • Goto: Solution -> Package
  • Cliquez sur l' onglet Avancé (trouver sous la page)
  • Ajoutez votre DLL à des assemblys supplémentaires (de cette façon, nous pouvons ajouter des DLL externes dans sharepoint).
Vijay Singh
la source
7
Je n'ai pas de "Solution -> Package" dans mon projet
VS2010
5

Je ne sais pas si cela pourrait aider.

Vérifiez que le nom de l'assembly et l'espace de noms par défaut dans les propriétés de vos assemblys correspondent. Cela a résolu mon problème qui a donné la même erreur.

Sjaan
la source
Excellent! Mon nom de fichier dll et l'espace de noms étaient différents, j'ai copié l'espace de noms et renommé ma dll.
Anynomous Khan
5

Dans mon cas, dans le dossier bin, il y avait une DLL non référence appelée Unity.MVC3, j'ai essayé de rechercher n'importe quelle référence à ceci dans Visual Studio sans succès, donc ma solution était si facile que de supprimer cette DLL du dossier bin.

Totodile
la source
4

Merci Riddhi M. La suite a fonctionné pour moi.

Supprimer les fichiers temporaires C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Fichiers ASP.NET temporaires Fermer VSTS et rouvrir Supprimer et ajouter les mêmes DLL (Remarque: vous ajoutez les mêmes versions correspondantes)

Sridhar Kommana
la source
J'ai passé tellement de temps là-dessus et je ne peux pas croire que c'était la réponse. C'est généralement une bonne solution lorsque vous voyez un comportement étrange dans VS. Je vous remercie.
Bonez024
3

Vous dites que vous avez beaucoup de projets dans votre solution ... eh bien, commencez par un près du haut de l'ordre de construction. Obtenez celui-ci à construire et une fois que vous l'avez compris, vous pouvez appliquer le même correctif au reste d'entre eux.

Honnêtement, il vous suffit probablement de rafraîchir votre référence. Il semble que vous ayez mis à jour votre version et que vous n'ayez pas mis à jour les références, ou qu'il s'agisse d'un problème de chemin d'accès relatif si vous gardez votre solution sous contrôle de code source. Vérifiez simplement vos hypothèses et ajoutez de nouveau la référence.

Joel Martinez
la source
3

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 donnez un contrôle total à IIS et à tous les utilisateurs exécutant mon projet
seulement moi
la source
3

Ce problème m'est arrivé où une de mes bibliothèques dépendantes compilait une DLL avec "Any CPU" lorsque la bibliothèque parente attendait une compilation de "x64".

Creamstout10
la source
3

J'ai eu le même problème, je l'ai résolu via les instructions ci-dessous:

  1. ouvrir le menu d'outils et sélectionner l'option
  2. dans les options, fenêtre allez à Projets et Solutions / Projets Web
  3. vérifier use the 64bit version of IIS ...

entrez la description de l'image ici

mohammad almasi
la source
2

Vous devez supprimer votre fichier appname.dll de votre dossier de sortie. Nettoyer les dossiers de débogage et de publication. Reconstruisez et copiez dans le fichier dll régénéré du dossier de sortie.

gucci
la source
2

J'ai "Définir comme projet de démarrage" la bibliothèque / le projet déchargé / non trouvé.

Ensuite, il l'a déployé.

Ça a marché!

Je pense qu'il n'a pas pu trouver le .dll car il n'était pas dans l'assemblage au début.

nirav
la source
2

Autre cause possible: assurez-vous que vous n'avez pas accidentellement donné aux deux projets le même nom d'assembly dans les propriétés du projet.

nathanchere
la source
Cela m'a pris des heures à comprendre .... J'ai accidentellement nommé mon projet de test unitaire du même nom que le projet principal, donc la DLL du projet de test unitaire doit avoir écrasé la DLL du projet
Iannazzi
2

Ma solution pour .NET 4.0, en utilisant Enterprise Library 5, était d'ajouter une référence à:

Microsoft.Practices.Unity.Interception.dll

MacGyver
la source
2

Recherchez les références contradictoires. Même après un nettoyage et une reconstruction, les références en conflit provoqueront toujours un problème. Mon problème était entre AForge et Accord. J'ai supprimé les deux références et j'ai rajouté les références en re-choisissant la référence particulière (particulière à mon cas, juste Accord).

user3791372
la source
2

Pour moi, la reconstruction du jeu de l'unité sans Unity C # Proects Checkmark a fonctionné.

Praful Rudra
la source
2

Dans mon cas, aucune des réponses proposées n'a fonctionné.

Voici ce qui a fonctionné pour moi:

  1. Supprimer la référence
  2. Renommez la DLL
  3. Importez à nouveau la référence

La deuxième étape était apparemment importante car elle ne fonctionnait pas sans elle.

Nicolas Raoul
la source
2

Essayez de vérifier si la propriété «Copier vers local» pour la référence est définie sur true et la version spécifique est définie sur true. Ceci est pertinent pour les applications dans Visual Studio.

Srinivas Somasundaram
la source
2

Je l'ai eu 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 - d'une manière ou d'une autre, ceux-ci avaient été déplacés du numéro de version à la fin de ce bloc de 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>

Modifié à ce qui précède et le tour est joué! Tout a encore fonctionné.

garryp
la source
1

Si vous obtenez ce message d'erreur en ouvrant une application sur Windows XP, cela signifie d'abord que vous avez installé cette application car elle ne fonctionne pas sans Net Framework 4 et Service Pack 3. vous avez installé à la fois et vous obtenez cette erreur, vous devez donc réinstaller cette application, mais d'abord désinstaller à partir de l'ajout et de la suppression

si cela ne fonctionne pas, veuillez ne pas abuser de moi. je suis aussi junior

basit durrani
la source