GAC - Assembly ist in der GAC, aber "Konnte Datei oder Assembly nicht laden"

Question

Ich habe eine Interop-DLL, die von Visual Studio für ein COM-Objekt von Drittanbietern erstellt wurde, die ich in einer .NET-DLL verwende.

Ich habe sowohl meine verbrauchende DLL als auch die Interop DLL im GAC registriert. Ich muss den GAC verwenden, da diese DLLs von einem SharePoint 2010-Workflow verwendet werden.

Wenn die Ausführung zu dem Punkt kommt, an dem meine DLL die Interop dll aufruft, wurde der folgende Fehler ausgelöst "" Datei oder Assembly konnte nicht geladen werden "..." Die angegebene Datei konnte nicht zusammen mit der erwarteten Version und öffentlich gefunden werden Schlüssel.

Wenn ich die Fusion Assembly Binding Log Viewer untersuchen, wird der folgende Fehler in dem Protokolleintrag der Interop DLL aufgeführt wird:

LOG: GAC Lookup was unsuccessful. 

ich die Assembly im GAC sehen, und es hat die richtige Version und Token für öffentliche Schlüssel, wie in der FileNotFound-Ausnahme angegeben.

Was ist los?

Answer 1

Das Problem ist, dass, sowie Version und Public Key gültig sind, die Prozessorarchitektur des Interop muss das Ihre Berufung entspricht DLL. Und natürlich muss das Target Framework die gleiche Version haben.

Meine DLL wurde zum MSIL (Agnostic, AnyCPU) -Prozessor kompiliert, aber aus irgendeinem seltsamen Grund bestand Visual Studio darauf, das Interop zu x386 zu kompilieren.

(Vielleicht würde dies normalerweise kein Problem verursachen, aber mein SharePoint-Server ist 64 Bit, was die Symptome verursacht haben könnte).

Die Lösung ist die Interop selbst zu kompilieren:

1 - Hebt die Registrierung der DLL und die Interop aus dem GAC.

2 - Starten Sie die Visual Studio-Eingabeaufforderung der Visual Studio-Version, die sich auf das .NET-Framework bezieht, auf das Ihre DLL ausgerichtet ist (dh ich entwickelte meine DLL in Visual Studio 2010 und zielte auf .NET 3.5 ab Schritt I benötigt, um die Visual Studio 2008-Eingabeaufforderung)

3 starten - generieren des Interop mit Tlbmp

tlbimp <full path and filename of COM .tlb> /out:c:\.\Interop.CoolThirdParty.dll /keyfile: <full path and filename of snk> /machine:Agnostic /Namespace:CoolThirdParty 

die /Maschine: Agnostic die Interop bewirkt, dass die MSIL Prozessorarchitektur gebaut werden Targeting, die ist t er selbe wie meine dll.

4 - Entfernen Sie den alten Verweis auf die Interop in Ihrem DLL-Projekt

5 - Löschen Sie die alte Interop-Datei und ersetzen Sie es mit der, die Sie gerade erzeugt haben (zB c: \ Interop.CoolThirdParty.dll.)

6 - Fügen Sie dem neuen Interop eine Referenz in Ihrem Projekt hinzu.

7 - Rebuild

8 - Registrieren Sie Ihr neu dll und die neue Interop im GAC bauen arbeiten

Es sollte starten.

Answer 2

Hoffnung Drittanbieter-COM-Objekt ist auch auf der Maschine registriert

Answer 3

Schließen Sie Visual Studio .... löschen Sie alle Ordner aus C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files

Diese Ihr Problem lösen sollte ....

Answer 4

Ich erhielt dies für eine Zeile in meinem webconfig in compilation.assemblies Verweis auf eine Assembly, die in der GAC war. Das Problem war, dass jemand eine Assembly-Umleitung in die web.config-Umleitung von der Version, die in der GAC war, in eine andere nicht existierende Version umgeleitet hatte.