La définition du manifeste de l'Assemblée localisée ne correspond pas à la référence de l'Assemblée
J'essaie d'exécuter des tests unitaires dans une application Windows Forms C # (Visual Studio 2005) et j'obtiens le message d'erreur suivant:
System.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'Utilitaire, Version = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7' 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) **
à x.Foo.FooGO ()
at x.Foo.Foo2 (String groupName_) dans Foo.cs: line 123
at x.Foo.UnitTests.FooTests.TestFoo () dans FooTests.cs: ligne 98 **
System.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'Utilitaire, Version = 1.2.0.203, Culture = neutre, PublicKeyToken = 764d581291d764f7' 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 regarde dans mes références et je n'ai qu'une référence à Utility version 1.2.0.203 (l'autre est vieux).
Des suggestions sur la façon dont je découvre ce qui essaye de faire référence à cette ancienne version de ce fichier DLL?
En outre, je ne pense même pas avoir cet ancien assemblage sur mon disque dur . Y a-t-il un outil pour rechercher cet ancien assemblage versionné?
Le chargeur .NET Assembly ne parvient pas à trouver 1.2.0.203, mais a trouvé un 1.2.0.200. Cet assemblage ne correspond pas à ce qui a été demandé et vous obtenez donc cette erreur. En termes simples, il ne trouve pas l’assemblée référencée. Assurez-vous qu'il peut trouver le bon assemblage en le plaçant dans le GAC ou dans le chemin de l'application. Voir aussi http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx .
Vous pouvez faire plusieurs choses pour résoudre ce problème. Commencez par utiliser la recherche de fichiers Windows pour rechercher votre Assembly (.dll) sur votre disque dur. Une fois que vous avez une liste de résultats, faites View-> Choose Details ... puis cochez "Version du fichier". Cela affichera le numéro de version dans la liste des résultats afin que vous puissiez voir d'où vient l'ancienne version.
En outre, comme l'a dit Lars, vérifiez dans votre GAC quelle version est répertoriée ici. Cet article de Microsoft indique que les assemblys trouvés dans le GAC ne sont pas copiés localement lors de la génération. Vous devrez donc peut-être supprimer l'ancienne version avant de tout reconstruire. (Voir ma réponse à cette question pour des notes sur la création d'un fichier de commandes pour le faire pour vous)
Si vous ne parvenez toujours pas à comprendre d'où vient l'ancienne version, vous pouvez utiliser l'application fuslogvw.exe fournie avec Visual Studio pour obtenir plus d'informations sur les échecs de liaison. Microsoft possède des informations sur cet outil ici . Notez que vous devrez activer la journalisation en définissant la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog sur 1.
Je viens de rencontrer ce problème moi-même et j’ai trouvé que le problème était différent de ce que les autres ont rencontré.
Mon projet principal faisait référence à deux DLL: CompanyClasses.dll et CompanyControls.dll. Je recevais une erreur d'exécution en disant:
Impossible de charger le fichier ou l'assembly 'CompanyClasses, Version = 1.4.1.0, Culture = neutre, PublicKeyToken = 045746ba8544160c 'ou une de ses dépendances. Le localisé La définition du manifeste de l'Assemblée est ne correspond pas à la référence de l'Assemblée
Le problème était que je n'avais aucun fichier CompanyClasses.dll sur mon système avec un numéro de version de 1.4.1. Aucune dans le GAC, aucune dans les dossiers d'applications ... aucune nulle part. J'ai cherché tout mon disque dur. Tous les fichiers CompanyClasses.dll que j’avais étaient 1.4.2.
J'ai constaté que le vrai problème était que CompanyControls.dll faisait référence à la version 1.4.1 de CompanyClasses.dll. Je viens de recompiler CompanyControls.dll (après l'avoir référencé CompanyClasses.dll 1.4.2) et cette erreur a disparu pour moi.
Les éléments suivants redirigent toute version d’Assembly vers la version 3.1.0.0. Nous avons un script qui mettra toujours à jour cette référence dans App.config afin que nous n'ayons plus jamais à traiter ce problème.
Après réflexion, vous pouvez obtenir l’assembly publicKeyToken et générer ce bloc à partir du fichier .dll lui-même.
<assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
</dependentAssembly>
</assemblyBinding>
Notez que sans attribut d'espace de nom XML (xmlns), cela ne fonctionnera pas.
Si vous utilisez Visual Studio, essayez "Solution propre", puis reconstruisez votre projet.
Les autres réponses ne fonctionneraient pas pour moi. Si vous ne vous souciez pas de la version et que vous voulez simplement que votre application soit exécutée, cliquez avec le bouton droit de la souris sur la référence et définissez 'version spécifique' sur false.
Je viens de rencontrer ce problème et le problème était que j'avais une ancienne copie du fichier .dll dans le répertoire de débogage de l'application. Vous voudrez peut-être aussi vérifier ici (au lieu du GAC) pour voir si vous le voyez.
J'ai ajouté un paquet NuGet, mais je me suis rendu compte qu'une partie de mon application contenant une boîte noire faisait référence à une version plus ancienne de la bibliothèque.
J'ai supprimé le paquet et référencé le fichier statique DLL de l'ancienne version, mais le fichier web.config n'a jamais été mis à jour:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
à quoi il aurait dû revenir lorsque j'ai désinstallé le paquet:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>
Dans mon cas, il s’agissait d’une ancienne version de DLL dans le répertoire C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP\NET Files \. Vous pouvez supprimer ou remplacer l'ancienne version ou supprimer et rajouter la référence à la DLL dans votre projet. Dans les deux cas, vous créerez un nouveau pointeur sur les fichiers ASP.NET temporaires.
Dans mon cas, cette erreur s'est produite lors de l'exécution d'une application ASP.NET. La solution consistait à:
- Supprimer les dossiers
objetbindans le dossier du projet
Nettoyer ne fonctionnait pas, la reconstruction ne fonctionnait pas, toutes les références allaient bien, mais ce n'était pas l'écriture d'une des bibliothèques. Après avoir supprimé ces répertoires, tout a fonctionné parfaitement.
Pour nous, le problème était causé par autre chose. Le fichier de licence pour les composants DevExpress comprenait deux lignes, une pour une ancienne version des composants qui n'était pas installée sur cet ordinateur particulier. La suppression de l'ancienne version du fichier de licence a résolu le problème.
Le problème, c’est que le message d’erreur ne donnait aucune indication sur la référence à l’origine des problèmes.
La mienne était une situation très similaire à celle de Nathan Bedford, mais avec une légère tournure. Mon projet a également référencé la DLL modifiée de deux manières. 1) directement et 2) indirectement en référençant un composant (bibliothèque de classes) qui avait lui-même une référence à la DLL modifiée. Maintenant, mon projet Visual studio pour le composant (2) a référencé la version correcte de la DLL modifiée. Cependant, le numéro de version du composant lui-même n'a PAS été changé. En conséquence, l'installation de la nouvelle version du projet n'a pas réussi à remplacer ce composant sur la machine cliente.
Résultat final: Les références directe (1) et indirecte (2) pointaient vers différentes versions de la dll modifiée sur la machine cliente. Sur ma machine de développement cela a bien fonctionné.
Résolution: supprimer l'application. Supprimer toutes les DLL du dossier de l'application; Réinstallez. Simple comme ça dans mon cas.
Cette erreur est exactement la même si vous essayez de lier tardivement à l’aide de la réflexion, si l’assemblée à laquelle vous vous associez obtient un nom fort ou si son jeton de clé publique est modifié. L'erreur est la même, même s'il n'y a pas d'assembly trouvé avec le jeton de clé publique spécifié.
Vous devez ajouter le jeton de clé publique correct (vous pouvez l'obtenir à l'aide de sn -T sur la dll) pour résoudre l'erreur. J'espère que cela t'aides.
J'aimerais simplement ajouter que je créais un projet ASP.NET MVC 4 de base et que j'avais ajouté DotNetOpenAuth.AspNet via NuGet. Cela a entraîné la même erreur après que j'ai référencé un fichier DLL ne concordant pas pour Microsoft.Web.WebPages.OAuth.
Pour résoudre ce problème, j’ai fait un Update-Package et nettoyé la solution pour une reconstruction complète.
Cela a fonctionné pour moi et est un peu paresseux, mais le temps, c'est de l'argent :-P
Mon problème était de copier le code source sur une nouvelle machine sans intercepter aucun des assemblys référencés.
Rien de ce que j'ai fait ne corrige l'erreur, alors, dans la précipitation, j'ai supprimé le répertoire BIN. Reconstruit mon code source, et cela a fonctionné à partir de là.
Je laisserai quelqu'un bénéficier de ma stupidité au cisaillement. J'ai quelques dépendances à une application complètement séparée (appelons cette App1). Les dll de cette App1 sont tirées dans ma nouvelle application (App2). Chaque fois que je fais des mises à jour dans APP1, je dois créer de nouvelles DLL et les copier dans App2. Bien. . . J'en avais marre de copier-coller entre 2 versions différentes d'App1, j'ai donc simplement ajouté un préfixe 'NEW_' à la dll.
Bien. . . J'imagine que le processus de génération analyse le dossier/bin et que, s'il ne correspond pas correctement, il affiche le même message d'erreur que celui indiqué ci-dessus. J'ai supprimé mes "new_" versions et il a construit juste dandy.
J'ai eu cette erreur en développant le service de génération de Team Foundation Server. Il est apparu que ma solution comportait plusieurs projets utilisant différentes versions de la même bibliothèque ajoutées avec NuGet. J'ai supprimé toutes les anciennes versions avec NuGet et ajouté la nouvelle comme référence pour tous.
Team Foundation Server place tous les fichiers DLL dans un seul répertoire et il ne peut exister qu'un seul fichier DLL portant un certain nom à la fois.
Mon app.config contient un
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>
pour npgsql. D'une manière ou d'une autre sur la machine de l'utilisateur, mon app.exe.config a disparu. Je ne suis pas sûr que ce soit un utilisateur idiot, un problème d'installation ou un anti-virus complètement excité. Le remplacement du fichier a résolu le problème.
Je viens de trouver une autre raison pour laquelle obtenir cette erreur. J'ai nettoyé mon GAC de toutes les versions d'une bibliothèque spécifique et construit mon projet en référence à une version spécifique déployée avec l'exécutable. Lorsque j'ai lancé le projet, j'ai eu cette exception à la recherche d'une version plus récente de la bibliothèque.
La raison était politique de l'éditeur . Lorsque j'ai désinstallé les versions de la bibliothèque à partir de GAC, j'ai oublié de désinstaller également les assemblys de stratégies d'éditeur. Ainsi, au lieu d'utiliser mon Assembly déployé localement, le chargeur Assembly a trouvé une stratégie d'éditeur dans GAC qui lui indiquait de rechercher une version plus récente.
Pour moi, la configuration de la couverture de code dans le fichier "Local.testtesttings" "a causé" le problème. J'ai oublié de mettre à jour les fichiers qui y ont été référencés.
La suppression du contenu du dossier bin de votre projet et la reconstruction de la solution ont résolu mon problème.
nettoyer et reconstruire la solution peut ne pas remplacer toutes les dll du répertoire de sortie.
ce que je vais suggérer est d'essayer de renommer le dossier de "bin" à "oldbin" ou "obj" à "oldobj"
et essayez ensuite de reconstruire votre silution.
si vous utilisez des dll tierces, vous devrez les copier dans le dossier "bin" ou "obj" nouvellement créé après une construction réussie.
espérons que cela fonctionnera pour vous.
La suppression manuelle de l'ancien assemblage à partir de l'emplacement du dossier, puis l'ajout de la référence à de nouveaux assemblys peuvent aider.
Dans mon cas, le problème était entre la chaise et le clavier :-)
Could not load file or Assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located Assembly's manifest definition does not match the Assembly reference.
(Exception from HRESULT: 0x80131040)
Deux ou plusieurs assemblys différents souhaitaient utiliser une version différente de la bibliothèque DotNetOpenAuth, ce qui ne poserait pas de problème. De plus, sur mon ordinateur local, un web.config a été automatiquement mis à jour par NuGet:
<dependentAssembly>
<assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>
Ensuite, j'ai réalisé que j'avais oublié de copier/déployer le nouveau web.config sur le serveur de production. Donc, si vous avez un moyen manuel de déployer web.config, vérifiez qu'il est mis à jour. Si vous avez complètement web.config pour le serveur de production, vous devez fusionner cette section dependAssembly en synchronisation après l'utilisation de NuGet.
J'ai eu la même erreur ...... Dans mon cas, cela a été résolu comme suit:
- Au début, lorsque l'application a été installée, les personnes ici avaient utilisé Microsoft Enterprise Library 4.1 dans l'application.
- La semaine précédente, ma machine avait été formatée et aujourd'hui, lorsque j'ai construit cette application, une erreur s'est produite: Enterprise Library Assembly est manquant.
- Ensuite, j'ai installé Microsoft Enterprise Library 5.0 que j'ai sur Google comme première entrée de recherche.
- Ensuite, lorsque j’ai construit l’application, l’erreur ci-dessus s’est produite, à savoir que la définition du manifeste de l’Assemblée localisée ne correspond pas à la référence de l’Assemblée.
- Après beaucoup de travail de recherche et d'analyse, j'ai constaté que l'application faisait référence à 4.1.0.0 et que la DLL dans le dossier bin était de la version 5.0.0.0.
- Ce que j’ai fait c’est alors que j’ai installé Microsoft Enterprise Library 4.1.
- Suppression de la référence précédente (5.0) et ajout de la référence 4.0.
- Construit l'application et le tour est joué ... cela a fonctionné.
Voici ma méthode pour résoudre ce problème.
- Dans le message d'exception, obtenez le nom de la bibliothèque "problème" et le numéro de version "attendu".
- Recherchez toutes les copies de ce fichier .dll dans votre solution, cliquez dessus avec le bouton droit de la souris et vérifiez quelle version du fichier .dll il s'agit.
Bon, dans cet exemple, mon fichier .dll est bien 2.0.5022.0 (le numéro de version d’Exception est donc faux).
- Recherchez le numéro de version indiqué dans le message d'exception dans tous les fichiers .csproj de votre solution. Remplacez ce numéro de version par le numéro actuel de la dll.
Donc, dans cet exemple, je remplacerais ceci ...
<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
... avec ça...
<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
Travail accompli !
J'ai rencontré le même problème lors de l'exécution des tests de mon unité.
L'erreur indique clairement que le problème est le suivant: lorsque nous essayons de charger Assembly, le chargeur d'assemblys .NET tente de charger ses assemblys référencés en fonction de ses données de manifeste (nom d'assembly référencé, jeton de clé publique, version).
Pour vérifier les données du manifeste:
- Ouvrez l'invite de commande Visual Studio,
- Tapez 'ildasm' et faites glisser l'assemblage requis vers la fenêtre ILDASM et ouvrez la vue MANIFEST. Parfois MANIFEST contient un assemblage avec deux versions, ancienne version, ainsi que la nouvelle version (comme
Utility, Version=1.2.0.200etUtility, Version=1.2.0.203). En réalité, l'assembly référencé estUtility, Version=1.2.0.203(new version), mais comme le manifeste contient mêmeUtility, Version=1.2.0.200(old version), le chargeur d'assemblages .NET essaie de trouver ce fichier DLL versionné, échoue, et génère une exception.
Pour résoudre ce problème, faites simplement glisser chaque assemblage dépendant du projet dans la fenêtre ILDASM séparément et vérifiez quel assemblage dépendant contient les données de manifeste avec l'ancienne version d'Assembly. Reconstruisez simplement cet assemblage dépendant et renvoyez-le à votre projet.
J'ai eu le même problème aujourd'hui qui m'a empêché d'effectuer Add-Migration après avoir apporté des modifications à Entity Framework.
J'avais deux projets dans ma solution, appelons-les "Client" et "Données" - un projet de bibliothèque de classes contenant mes modèles EF et mon contexte. Le client a référencé le projet Data.
J'avais signé les deux projets, puis apporté des modifications à un modèle EF. Après avoir supprimé la signature, j'ai pu ajouter les migrations et signer à nouveau le projet.
J'espère que cela pourra être utile à quelqu'un, en lui évitant une frustration prolongée.
Le problème avec moi était qu'il y avait d'anciennes dll déployées qui ont été supprimées dans une nouvelle version . Pour résoudre ce problème, je viens de cocher la case pour supprimer les fichiers supplémentaires à la destination lors de la publication . Supprimer les fichiers supplémentaires à la destination
J'ai reçu ce message d'erreur en raison de la référence à une assemblée portant le même nom que celle que je construisais.
Ceci compilé mais il a écrasé l’assemblée référencée avec les projets en cours Assembly, ce qui a provoqué l’erreur.
Pour résoudre ce problème, j'ai changé le nom du projet et les propriétés de l'assemblage disponibles en cliquant avec le bouton droit de la souris sur le projet et en choisissant "Propriétés".
J'ai eu ce problème après avoir commencé à utiliser InstallShield. Même si l'ordre de construction indiquait que le projet d'installation était le dernier, sa construction était en panne.
J'ai corrigé cela en rendant tous les autres projets dépendants de celui-ci - cela a forcé l'installation à construire en dernier et a ainsi supprimé mon déséquilibre d'assemblage. J'espère que ça aide.
Je vais épater tout le monde en ce moment. . .
Supprimez toutes les références <assemblyBinding> de votre fichier .config, puis exécutez cette commande à partir de la console NuGet Package Manager:
Get-Project -All | Add-BindingRedirect
Cette même erreur s'est produite pour moi dans mon projet de tests unitaires et a entraîné l'échec de certains tests. J'ai vérifié deux fois la version de l'assembly que j'utilisais dans Assembly Explorer, ainsi que le contenu des balises runtime/dependassembly et me suis rendu compte qu'une version différente de l'assembly que j'utilisais y était toujours référencée. Comme c'était la seule directive de mon projet de tests app.config, je venais d'essayer de supprimer tout le fichier app.config, de reconstruire la solution, ce qui a fait l'affaire! Plus d'erreurs de référence pour moi :)
Aucune solution n'a fonctionné pour moi. J'ai essayé la solution de projet propre, supprimer bin, le package de mise à jour, le package de mise à niveau inférieur, etc. ... Après deux heures, j'ai chargé App.config par défaut à partir d'un projet avec des assemblys et j'ai modifié la version de référence erronée à partir de:
<dependentAssembly>
<assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
à:
<dependentAssembly>
<assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
Après cela, j'ai nettoyé le projet, je l'ai reconstruit et cela a fonctionné. Pas d'avertissement, pas de problème.
OK, encore une réponse. J'ai précédemment créé mon application en 64 bits et modifié le chemin de sortie (Projet/Propriétés/Construire/Sortie/Chemin de sortie) en conséquence. Récemment, j'ai changé l'application en 32 bits (x86), créant un nouveau chemin de sortie. J'ai créé un raccourci vers l'endroit où je pensais le fichier .exe compilé. Peu importe ce que j'ai changé à propos de la source, le manifeste ne correspond pas à l'erreur. Après environ une heure de frustration, il m'est arrivé de vérifier la date/heure du fichier .exe, vu qu'il était vieux, faisant évidemment référence à l'ancien .dll. Je compilais l'application dans l'ancien répertoire et mon raccourci faisait référence au plus récent. Changement du chemin de sortie vers l'emplacement où le .exe devrait aller, le raccourci et l'erreur disparaissent ((claque le front))
Je devenais:
Impossible de charger le fichier ou l'assembly 'XXX-new' 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)
C'est parce que j'ai changé le nom de l'Assemblée de XXX.dll à XXX-new.dll. Rétablir le nom à l'original a corrigé l'erreur.
vérifiez les licences.licx dans les propriétés du projet, vous y trouverez la mauvaise version .... cela a fonctionné pour moi dans les rapports actifs
Dans votre fichier AssemblyVersion in AssemblyInfo.cs, utilisez un numéro de version fixe au lieu de spécifier *. Le * changera le numéro de version sur chaque compilation. C'était le problème de cette exception dans mon cas.
La question a déjà une réponse, mais si le problème a été rencontré par le package NuGet dans différentes versions de la même solution, vous pouvez essayer ce qui suit.
Ouvrez NuGet Package Manager, car vous voyez que la version de mon projet de service est différente de celle des autres.
Mettez ensuite à jour les projets contenant une ancienne version de votre package.
Veuillez lire les "détails complets" dans Visual Studio. Dans Full details, il m'a été indiqué qu'un de mes projets (qui faisait référence à mon projet principal utilise une version différente de Microsoft.IdentityModel.Clients.ActiveDirectory). Dans mon cas, mon projet de test unitaire appelait mon projet. Mon projet de test unitaire et mon projet ont une version différente de Microsoft.IdentityModel.Clients.ActiveDirectory. Je reçois une erreur d'exécution lors de l'exécution de mon test unitaire.
Je viens de mettre à jour la version de mon projet de test unitaire avec la même version du projet principal. Cela a fonctionné pour moi.
Si vous obtenez une erreur du type "La définition du manifeste de l'Assemblée située ne correspond pas à la référence de l'Assemblée}" et si vous avez mis à jour via Projet> Gérer les packages NuGet et l'onglet Mise à jour dans VS, Pour ce faire, essayez d’installer une autre version du paquet après avoir vérifié les versions depuis la page NuGet Gallery et d’exécuter la commande suivante depuis la console de Package Manager:
PM> Install-Package YourPackageName -Version YourVersionNumber
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0
Bien que la réponse ne soit pas directement liée au paquet en question et que l’on l’a demandé il ya longtemps, il s’agit d’un genre de générique, toujours pertinent et j’espère que cela aidera quelqu'un.
J'ai eu un problème similaire lors de la tentative de mise à jour d'un fichier DLL de mon site Web.
Cette erreur se produisait lorsque j'ai simplement copié ce fichier DLL dans un dossier bin via FTP.
J'ai résolu ce problème par:
- arrêter le site Web;
- copier les fichiers DLL nécessaires/les fichiers DLL;
- démarrer le site web
Un problème similaire avait-il été mentionné dans cet article "Des suggestions sur la façon dont je vois ce qui tente de faire référence à cette ancienne version de ce fichier DLL?"
Nécessaire pour quel assemblage se réfère toujours à l'ancien client ODATA 6.15.0, ildasm m'a permis de mieux cerner (sans accès au code de base, uniquement via pkg déployé sur le serveur).
Capture d'écran ci-dessous pour un résumé rapide.
DeveloperPackge si ne possède pas ildasm.exe https://www.Microsoft.com/net/download/visual-studio-sdks
Cela peut également se produire si vous utilisez AssemblyInfo.cs avec les balises AssemblyVersion et que votre fichier .csproj a une valeur différente. En faisant correspondre AssemblyInfo ou en supprimant la section dans son ensemble, le problème disparaît.
M'est arrivé pour System.ValueTuple
Erreur inattendue Impossible de charger le fichier ou l'assembly 'System.ValueTuple, Version = 4.0.1.0, Culture = neutre, PublicKeyToken = cc7b13ffcd2ddd51' ou l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.
Résolu en installant .NET Framework 4.7.2 Runtime sur la machine sur laquelle l'erreur s'est produite. Simple et inutile d'ajouter bindingRedirect, de modifier GAC ou de rétrograder les packages NuGet, etc.
https://dotnet.Microsoft.com/download/dotnet-framework/net472
J'ai rencontré ce problème lors de l'utilisation d'un référentiel de packages interne. J'avais ajouté le paquet principal au référentiel interne, mais pas les dépendances du paquet. Assurez-vous également d’ajouter toutes les dépendances, dépendances de dépendances, etc. récursives à votre référentiel interne.