wake-up-neo.com

Datei oder Assembly 'Microsoft.Data.Edm' konnte nicht geladen werden

Wir verwenden das Windows Azure Storage NuGet-Paket Version 4.1.0, dies hat eine Abhängigkeit von Microsoft.Data.OData und hat dieses Paket ebenfalls hinzugefügt, das die Microsoft.Data.Edm-DLL hat. Wenn wir die Anwendung erstellen und ausführen, wird gelegentlich folgender Fehler angezeigt:

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)

Wir haben die folgende verbindliche Weiterleitung in der Datei web.config und auch überprüft, und dies ist die einzige Version von Microsoft.Data.Edm, auf die von allen Projekten in der Lösung verwiesen wird.

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

Wenn ich in den Bin-Ordner schaue, finde ich manchmal, dass die DLL-Version von Microsoft.Data.Edm Version 5.6.0 ist. Ich habe alle Projekte durchlaufen und finde keinen Verweis auf Microsoft.Data.Edm außer mit dem Speicherclient. Dies ist definitiv 5.6.1.

Was ist der beste Weg, um herauszufinden, woher die 5.6.0-Version kommt? Wenn wir diese Fehlermeldung erhalten, löschen wir die Ordner bin und obj und bauen sie neu auf. Dann funktioniert alles einwandfrei. Die Version 5.6.1 ist da und alles funktioniert, aber irgendwann passiert es wieder.

BEARBEITEN:

Wir haben wieder ein Upgrade auf alle aktuellen Versionen von NuGet durchgeführt und haben immer noch kein Glück. Ich habe ein Tool ausgeführt, das die folgenden Abhängigkeiten zeigt:

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

Was ich nicht verstehe ist, dass wir die App-Bindungsumleitungen eingerichtet haben, aber manchmal wird die Version 2.6.0 und manchmal auch die Version 2.6.2 kopiert. Weiß jemand, warum dies passieren würde, hatte dieses Problem noch nie zuvor.

35
user351711

Ich hatte dieselbe Fehlermeldung, aber mein Problem hatte nichts mit einem Azure-Produkt zu tun. In meinem Fall habe ich OData von Version 3 auf Version 4 aktualisiert und mir scheint, dass Nuget verbindliche Weiterleitungen für veraltete DLLs hinterlassen hat. Insgesamt waren es drei, Microsoft.Data.Edm, Microsoft.Data.OData und System.Spatial.

Meine Lösung bestand darin, die veralteten verbindlichen Weiterleitungen zu entfernen. Sie sollten auch die alte DLL in Ihrem bin-Ordner entfernen, wenn der Build-Prozess dies nicht tut.

20
Bill

Hier sind einige Dinge, die Sie ausprobieren können:

  1. Überprüfen Sie Ihr Post Build-Ereignis, um sicherzustellen, dass keine Microsoft.Data.Edm.dll-Datei manuell in den Ordner bin kopiert wird.
  2. Stellen Sie sicher, dass andere Pakete nicht von Microsoft.Data.Edm 5.6.1 abhängig sind. Sie können dies einfach tun, indem Sie Ihre package.config-Dateien anzeigen.
  3. Wenn sich Ihr Code in der Quellcodeverwaltung befindet, stellen Sie sicher, dass sich niemand im Bin-Ordner eincheckt. Ich bin überrascht, wie viele Menschen diese Grundregel nicht kennen.
  4. Deinstallieren Sie die Pakete WindowsAzure.Storage und Microsoft.Data.Edm. Dann erneut installieren und sicherstellen, dass nur die stabile Version installiert wird.

HTH.

3
stack247

Eine Sache, die dieses Problem manchmal für Mitglieder meines Teams zu beheben scheint, ist, alle Instanzen von Visual Studio zu schließen, den Inhalt des Paketverzeichnisses zu löschen, Visual Studio erneut zu öffnen und anschließend Pakete wiederherzustellen und neu zu erstellen. Das funktioniert aber nicht immer. 

Wir konnten das Problem auf einem unserer Computer nachverfolgen, indem wir das problematische Projekt durch Erhöhen der Ausführlichkeit der Visual Studio-Buildausgabe identifizierten:

 Increasing Visual Studio build output verbosity

Dann haben wir die Ausgabe durchsucht und das problematische Zielprojekt identifiziert, indem wir nach "Microsoft.Data.Edm" gesucht haben. Wir haben festgestellt, dass es eine indirekte Abhängigkeit von Microsoft.Data.Edm zu geben schien. Wir haben jedoch festgestellt, dass die Assembly nicht explizit als Paket für dieses Projekt enthalten war. Mit der Nuget-Paketkonsole haben wir das Projekt als Ziel ausgewählt und den folgenden Code ausgeführt: Install-Package Microsoft.Data.Edm Dadurch wurde das Problem behoben.

 Install Package with Nuget

3
devinbost

Ich traf heute einen ähnlichen Fall. In meiner Situation kopierte der Build immer eine alte DLL-Version in den Debug-Ordner. Der Grund ist, dass mein Projekt diese DLL nicht direkt referenziert, sondern ein anderes Projekt, das auf diese DLL verweist.
... Beim Erstellen findet mein Projekt also eine alte Version von GAC oder einem anderen Ort.
Ich löste es durch expliziten Verweis auf diese DLL im Projekt von der richtigen Stelle.
so was:

<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

Ich hatte gerade dasselbe Problem auf meinem Build-Server. Beim Überprüfen der Build-Ausgabe fiel mir Folgendes auf:

Kopieren der Datei von "C:\Programme (x86)\Microsoft WCF Data Services\5.6\bin.NETFramework\Microsoft.Data.Edm.dll" nach "bin\Microsoft.Data.Edm.dll".

Anscheinend ist auf dem Build-Server etwas installiert, das sich nicht auf meinem Computer befindet. Ich muss das also aufspüren.

2
Carl

Möglicherweise handelt es sich dabei um ein Problem des virtuellen Pfads auf IIS (Ich denke, diese Assembly wurde beim Start der Anwendung zuerst geladen).

Ich habe das gleiche Problem, wenn ich zwei Projekte von unterschiedlichen Speicherorten auf der Festplatte mit den gleichen virtuellen Pfaden starte.

Lösung: Löschen Sie diesen Pfad aus IIS, setzen Sie den Vorgang zurück IIS und erstellen Sie erneut einen virtuellen Pfad aus VS.

1
holder

fand es !!
Ändern Sie in Ihrer app.config-Datei die Version bindingredirect
Lassen Sie das bindende redirect -Element auf die Version verweisen, über die sich die Ausnahme beschwert, und die Ausnahme wird verschwinden.
Erklärung:
Möglicherweise waren die Datei app.config und die Projektreferenz Assembly nicht mehr synchron und verursachten den Fehler. 

<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

Dies wurde für mich erfolgreich gelöst, indem Visual Studio geschlossen und wieder geöffnet wurde.

0
BCarpe

1) Setzen Sie Build Verbosity auf Detailliert. 2) Suchen Sie nach Microsoft.Data.Edm und vergleichen Sie die Versionen anderer im Projekt verwendeter Assemblys. 3) Aktualisieren Sie sie mit der Version, die in anderen Assemblys verwendet wird

Mein Problem gelöst

0
Michael Staples

Für mich musste ich das WindowsAzure.MobileServices.Backend.Entity NuGet-Paket deinstallieren, das viele Baugruppen entfernt, einschließlich Microsoft.Data.Edm. Und dann habe ich es einfach wieder installiert und auf wundersame Weise funktionierte es!

Dies war in meinem Azure Mobile Services-WebApi-Projekt, also musste es funktionieren, und zum Glück tut es das jetzt.

Ich hoffe das hilft.

0
King Wilder

Ich habe diese Fehlermeldung erhalten, nachdem ich meinen "packages" -Ordner gelöscht und die Pakete neu installiert hatte. Ich konnte den Fehler beheben, indem ich "Clean Solution" und "Rebuild Solution" ausführte.

0
Brent Keller