2013-07-03 3 views
5

У меня есть почти пустой проект ASP.NET MVC4, ссылающийся на 64-битную управляемую сборку, которая имеет набор неуправляемых зависимостей.64-разрядная управляемая сборка с неуправляемыми зависимостями, не загружаемыми в IIS/ASP.NET MVC 4

Управляемая сборка ссылается на обычный путь через ссылки.

Неуправляемые зависимости копируются в папку bin при событии пост-сборки и присутствуют при запуске веб-приложения (это было проверено).

Проблема заключается в том, что я получаю:

Не удалось загрузить файл или сборку «msvcm80.DLL» или один из его зависимостей. Не удалось выполнить процедуру инициализации динамической библиотеки ссылок (DLL). (Исключение из HRESULT: 0x8007045A)

Это одна из неуправляемых зависимостей. Полный список:

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

Управляемая dll построена против x64, и все зависимости также x64 (проверены с помощью Dependency Walker).

Теперь я также создал пустую консольную программу, приложение для форм Windows и самодельный веб-Api, который содержит один и тот же код (для запуска экземпляров с использованием управляемой сборки), и все они работают нормально (при форсировании цель сборки - x64).

Использование Fusion Log (очистка его, а затем загрузки веб-приложения и обновления просмотрщика), я могу видеть, что есть проблемы загрузки:

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

Все они имеют аналогичные файлы журнала:

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. 

Таким образом, на самом деле выясняется, что зависимости находятся в локальной папке bin, но по какой-то причине они не могут их использовать.

Что делает ошибка «Ошибка извлечения манифеста из файла (hr = 0x80131018)». имею в виду?

Зависимости не находятся в GAC, и они не зарегистрированы с использованием regsvr32 (а не COM).

Что меня озадачивает, так это то, что работает отлично за пределами IIS (я даже пытался настроить учетные данные в пуле приложений так же, как и учетные данные локальной сети, что, конечно же, не имело значения).

Любые хорошие идеи по отладке этой проблемы?

EDIT: Теперь я могу запустить сайт ASP.NET на моей локальной машине разработчика, но не, когда он развернут на другом сервере.

«Исправить» для моей локальной машины было удаление msvcm80.dll (C runtime) из каталога bin. Сборка (возможно) по-прежнему необходима, но просматривается где-то в другом месте (предположительно, потому что у меня есть «правильная» версия CRT (дистрибутив), установленная в WinSxS).

В этом я вижу, что управляемая сборка предположительно зависит от версии msvcm80.dll 8.00.50727.6195 (x64), но эта конкретная версия не установлена ​​в моей локальной системе (у меня ее есть только в папке зависимостей) - но у меня есть новый в WinSxs (8.00.50727.6910).

Итак, какой из них IIS собирает, когда он не добавляется непосредственно в папку bin?

второй EDIT: Так это выглядит, как lbm.dll имеет прямую зависимость к MSVCR80.DLL, но он также имеет зависимость к iconv.dll, который снова имеет зависимость к MSVCR80.DLL. Однако, согласно Dependency Walker (depend.exe), эти две зависимости не разрешены из одного и того же каталога (даже если они имеют одну и ту же версию!).

Если я уверен, что косвенная зависимость находится в переменной среды PATH, а 2-я зависимость - в WinSxS, она работает. Это явно недостаточно, но я не могу понять, как обеспечить, чтобы прямая и косвенная зависимость загружалась из одного места/файла.

ответ

3

Используя инструмент, как Dependency Walker вы обнаружите, что lbm.dll и его зависимости зависят только от msvcr80.dll и не msvcp80.dll и msvcm80.dll, даже если эти два файла включены в Microsoft.VC80.CRT.manifest используется lbm.dll, чтобы загрузить правильную версию ++ 2005 выполнения Visual C библиотека.

Удаление msvcp80.dll и msvcm80.dll из папки bin вы должны решить свою проблему.

+2

Спасибо, Мартин, это точно. Для завершения работы в IIS требуется последняя задача - отключение теневого копирования сборок. Если это разрешено, зависимости не копируются далее в каталог теневой копии. Это можно сделать, вставив это в web.config (под ): cwt237