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

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.

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.

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.

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.

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

À 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!

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.

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)

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.

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:

Dans 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".

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:

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?

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)

4), 5)

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

• 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).

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.

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.

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)

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.

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

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".

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

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.

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.

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.

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

Microsoft.Practices.Unity.Interception.dll

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).

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

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.

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.

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é.

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