web-dev-qa-db-fra.com

Impossible de charger le fichier ou l'assembly 'Microsoft.Data.Edm'

Nous utilisons le package Windows Azure Storage NuGet version 4.1.0, qui dépend de Microsoft.Data.OData et a également ajouté ce package contenant la dll Microsoft.Data.Edm. Lorsque nous construisons et exécutons l'application, nous obtenons très occasionnellement l'erreur suivante:

Could not load file or Assembly 'Microsoft.Data.Edm' or one of its dependencies. The
located Assembly's manifest definition does not match the Assembly reference. (Exception
from HRESULT: 0x80131040)

Nous avons la redirection de liaison suivante dans le fichier web.config et avons également vérifié. Il s'agit de la seule version de Microsoft.Data.Edm référencée par tous les projets de la solution.

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.6.1.0" newVersion="5.6.1.0" />
  </dependentAssembly>

Parfois, lorsque je regarde dans le dossier bin, je trouve que la version DLL de Microsoft.Data.Edm est v 5.6.0. J'ai parcouru tous les projets et je ne trouve pas de référence à Microsoft.Data.Edm, à l'exception du client de stockage, qui est définitivement 5.6.1.

Quel est le meilleur moyen d’essayer de déterminer l’origine de la version 5.6.0? Lorsque nous obtenons cette erreur, nous supprimons les dossiers bin et obj, puis nous reconstruisons et tout fonctionne normalement. La version 5.6.1 est disponible et tout fonctionne, mais finalement, cela se reproduit.

MODIFIER:

Nous avons de nouveau mis à niveau toutes les dernières versions de NuGet et toujours pas de chance, j’ai exécuté un outil qui affiche les dépendances suivantes:

Possible conflicts for Microsoft.Data.Edm:

Microsoft.Data.OData      references Microsoft.Data.Edm, Version=5.6.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.Data.Services.Client references Microsoft.Data.Edm, Version=5.6.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.WindowsAzure.Storage references Microsoft.Data.Edm, Version=5.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

Possible conflicts for Microsoft.Data.OData:

Microsoft.Data.Services.Client references Microsoft.Data.OData, Version=5.6.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.WindowsAzure.Storage references Microsoft.Data.OData, Version=5.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

Ce que je ne comprends pas, c’est que nous avons défini les redirections de liaison d’application, mais la version 2.6.0 est parfois copiée et parfois la version 2.6.2. Est-ce que quelqu'un sait pourquoi cela se produirait, jamais eu ce problème auparavant.

c#.netazuredll
35
user351711

J'avais le même message d'erreur, mais mon problème n'était pas lié à un produit Azure. Dans mon cas, j'ai mis à jour OData de la version 3 à la version 4 et il me semble que Nuget a laissé des redirections de liaison pour les DLL obsolètes. Au total, il y en avait trois, Microsoft.Data.Edm, Microsoft.Data.OData et System.Spatial.

Ma solution était de supprimer les redirections de liaison obsolètes. Vous devriez également supprimer les anciennes DLL situées dans votre dossier bin si votre processus de construction ne le fait pas.

20
Bill

Voici quelques choses que vous pouvez essayer:

  1. Vérifiez votre événement post-construction pour vous assurer qu'aucun fichier Microsoft.Data.Edm.dll n'est copié manuellement dans le dossier bin.
  2. Assurez-vous que les autres packages ne dépendent pas de Microsoft.Data.Edm 5.6.1. Un moyen facile de le faire est de regarder vos fichiers package.config.
  3. Si votre code est en contrôle de source, assurez-vous que personne ne vérifie dans le dossier bin. Je suis surpris par le nombre de personnes qui ne connaissent pas cette règle de base.
  4. Désinstallez les packages WindowsAzure.Storage et Microsoft.Data.Edm. Ensuite, installez à nouveau et assurez-vous que vous installez uniquement la version stable.

HTH.

3
stack247

Une chose qui semble parfois résoudre ce problème pour les membres de mon équipe est de fermer toutes les instances de Visual Studio, de supprimer le contenu du répertoire de packages, de rouvrir Visual Studio, puis de restaurer des packages et de les reconstruire. Cela ne fonctionne pas toujours bien. 

Nous avons pu identifier le problème sur l'une de nos machines en identifiant le projet problématique en augmentant la verbosité de sortie de la génération de Visual Studio:

 Increasing Visual Studio build output verbosity

Ensuite, nous avons recherché la sortie et identifié le projet cible posant problème en recherchant "Microsoft.Data.Edm". Nous avons remarqué qu'il semblait y avoir une dépendance indirecte à Microsoft.Data.Edm, mais nous avons également constaté que Assembly n'était pas explicitement inclus en tant que package pour ce projet. Ainsi, en utilisant la console du package Nuget, nous avons ciblé le projet et exécuté: Install-Package Microsoft.Data.Edm Qui a résolu le problème.

 Install Package with Nuget

3
devinbost

J'ai rencontré un cas similaire aujourd'hui, dans ma situation, la construction copie toujours une ancienne version dll dans le dossier de débogage, la raison en est que mon projet ne fait pas directement référence à cette dll, mais à un autre projet faisant référence à cette dll.
Ainsi, lors de la construction, mon projet trouve une ancienne version de GAC ou d’un autre endroit.
Je l'ai résolu par référence explicite à cette dll dans le projet à partir du bon emplacement.
comme ça:

<Reference Include="Microsoft.Data.Services.Client, Version=5.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\packages\Microsoft.Data.Services.Client.5.6.1\lib\net40\Microsoft.Data.Services.Client.dll</HintPath>
</Reference>
2
dasons

Je viens d'avoir ce même problème sur mon serveur de build et en vérifiant la sortie de build, j'ai remarqué ce qui suit:

Copie du fichier de "C:\Programmes de fichiers (x86)\Services de données WCF Microsoft\5.6\bin.NETFramework\Microsoft.Data.Edm.dll" vers "bin\Microsoft.Data.Edm.dll".

On dirait qu'il y a quelque chose installé sur le serveur de build qui ne se trouve pas sur ma machine, donc je dois le localiser.

2
Carl

C'est probablement un problème de chemin virtuel sur IIS (je pense que cet assembly a été chargé en premier au démarrage de l'application).

J'ai le même problème lorsque je lance deux projets à partir de différents emplacements sur le disque, mais avec les mêmes chemins virtuels.

La résolution est de supprimer ce chemin d’IIS, de réinitialiser le processus IIS et de créer à nouveau un chemin virtuel à partir de VS.

1
holder

je l'ai trouvé !!
dans votre fichier app.config changez la version bindingredirect .
Faites que l’élément bindingredirect fasse référence à la version dont l’exception se plaint et que l’exception disparaîtra.
explication:
Le fichier app.config et l’assemblage de référence du projet sont probablement désynchronisés, ce qui a provoqué l’erreur.

<runtime>
                <assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
                        <dependentAssembly>
                                <assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                                <bindingRedirect oldVersion="0.0.0.0-5.6.4.0" newVersion="5.6.4.0" />
                        </dependentAssembly>
                </assemblyBinding>
        </runtime>
1
hannes neukermans

Ce problème a été résolu avec succès en fermant et en réouvrant Visual Studio.

0
BCarpe

Pour moi, je devais désinstaller le package WindowsAzure.MobileServices.Backend.Entity NuGet qui supprime de nombreux assemblys, y compris Microsoft.Data.Edm. Et puis je viens de le réinstaller et miraculeusement, cela a fonctionné!

Cela faisait partie de mon projet WebApi Azure Mobile Services. Il devait donc fonctionner et, heureusement, il fonctionne maintenant.

J'espère que ça aide.

0
King Wilder