Verwaltete 64-Bit-Assembly mit nicht verwalteten Abhängigkeiten, die nicht in IIS/ASP.NET geladen werden MVC 4

Question

Ich habe ein fast leeres ASP.NET MVC4-Projekt, das auf eine verwaltete 64-Bit-Assembly verweist, die über nicht verwaltete Abhängigkeiten verfügt.

Die verwaltete Baugruppe verweist auf den normalen Weg durch Referenzen.

Die nicht verwalteten Abhängigkeiten werden bei einem Postbuildereignis in den Ordner bin kopiert - und sind vorhanden, wenn die Webanwendung gestartet wird (dies wurde bestätigt).

Das Problem ist, dass ich bekommen:

kann nicht Datei oder Assembly ‚msvcm80.dll‘ oder eine ihrer Abhängigkeiten laden. Eine Dynamic Link Library (DLL) -Initialisierungsroutine ist fehlgeschlagen. (Ausnahme von HRESULT: 0x8007045A)

Dies ist eine der nicht verwalteten Abhängigkeiten. Die vollständige Liste ist:

• iconv.dll
• lbm.dll
• libeay32.dll
• msvcm80.dll
• msvcp80.dll
• msvcr80.dll

Die verwaltete DLL wird für x64 erstellt, und alle Abhängigkeiten sind ebenfalls x64 (überprüft mit Dependency Walker).

Jetzt habe ich auch eine leere Konsole App, eine Windows-Formular-App und eine selbst gehostete Web-API, die den gleichen Code enthält (zum Starten von Instanzen mit der verwalteten Assembly) und sie alle funktionieren gut (beim Erzwingen der Build-Ziel zu x64).

Mit Fusion Log (es zuerst löschen, dann die Web-App Laden und Aktualisieren des Protokoll-Viewer), kann ich sehen, dass es Probleme beim Laden:

• iconv.dll
• libeay32.dll
• lbm.dll

Alle von ihnen haben ähnliche Protokolldateien:

LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/3b2d5b3e/b1b5f1f5/iconv.DLL. 
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/3b2d5b3e/b1b5f1f5/iconv/iconv.DLL. 
LOG: Attempting download of new URL file:///C:/.../bin/iconv.DLL. 
LOG: Assembly download was successful. Attempting setup of file: C:\...\bin\iconv.dll 
LOG: Entering download cache setup phase. 
ERR: Error extracting manifest import from file (hr = 0x80131018). 
ERR: Setup failed with hr = 0x80131018. 
ERR: Failed to complete setup of assembly (hr = 0x80131018). Probing terminated. 

So kommt es tatsächlich heraus, dass die Abhängigkeiten im lokalen bin-Ordner sind, aber sie können sie aus irgendeinem Grund nicht verwenden.

Was ist der Fehler "Fehler beim Extrahieren des Manifest-Imports aus Datei (hr = 0x80131018)." bedeuten?

Die Abhängigkeiten sind nicht in GAC und sie werden nicht mit regsvr32 (nicht COM) registriert.

Was mich verwirrt ist, dass es außerhalb von IIS funktioniert (ich habe sogar versucht, die Anmeldeinformationen im App-Pool so einzurichten, dass sie mit den lokalen Netzwerkanmeldeinformationen übereinstimmen - was natürlich keinen Unterschied macht).

Haben Sie gute Ideen, wie Sie dieses Problem beheben können?

EDIT: Ich bin jetzt in der Lage, die ASP.NET-Website auf meiner lokalen Entwickler-Maschine, aber nicht, wenn es auf einem anderen Server bereitgestellt auszuführen.

Das "Fix" für meine lokale Maschine war, die msvcm80.dll (C-Laufzeit) aus dem bin-Verzeichnis zu entfernen. Die Assembly wird (wahrscheinlich) immer noch benötigt, wird aber woanders nachgeschlagen (vermutlich weil ich die "korrekte" Version von CRT (distributable) in WinSxS installiert habe).

Eintauchen in das, sehe ich, dass die verwaltete Assembly angeblich von msvcm80.dll Version 8.00.50727.6195 (x64) abhängig ist, aber diese bestimmte Version ist nicht auf meinem lokalen System installiert (ich habe es nur in einem Abhängigkeitsordner) - aber ich habe eine neuere in WinSxs (8.00.50727.6910).

Also welches IIS nimmt auf, wenn es nicht direkt in den bin-Ordner hinzugefügt wird?

2. EDIT: So sieht es aus wie lbm.dll eine direkte Abhängigkeit MSVCR80.dll hat, aber es hat auch eine Abhängigkeit iconv.dll was wiederum eine Abhängigkeit MSVCR80.dll hat. Laut Dependency Walker (depends.exe) werden diese beiden Abhängigkeiten jedoch nicht aus demselben Verzeichnis aufgelöst (selbst wenn sie die gleiche Version haben!).

Wenn ich sicherstellen, dass die indirekte Abhängigkeit in der PATH-Umgebungsvariablen und die zweite Abhängigkeit in WinSxS ist, funktioniert es. Dies ist offensichtlich nicht gut genug, aber ich kann nicht herausfinden, wie man die direkte und indirekte Abhängigkeit von einem einzigen Ort/Datei laden kann.

Answer 1

ein Tool wie Dependency Walker Verwendung finden Sie, dass lbm.dll und seine Abhängigkeiten hängen nur von msvcr80.dll und nicht msvcp80.dll und msvcm80.dll obwohl diese beiden Dateien in den von lbm.dll verwendet Microsoft.VC80.CRT.manifest enthalten sind, um die richtige Version der Visual C++ 2005 Laufzeit zu laden Bibliothek.

Entfernen msvcp80.dll und msvcm80.dll von Ihnen bin Ordner sollte Ihr Problem beheben.