Что говорит этот журнал Fusion? - PullRequest
6 голосов
/ 16 марта 2012

Я отлаживаю проблему загрузки сборки, поэтому просматриваю логи fusion. Иногда они вводят меня в заблуждение, потому что они начинают с указания отказа, а затем в конце говорят, что сборка загружается с того места, где я ожидаю ее загрузки.

Что в действительности означает «операция завершилась неудачно», за которой следует «сборка IL, загруженная из ...»? Не удалось загрузить сборку или все получилось?

*** Assembly Binder Log Entry  (2012-03-16 @ 10:25:14) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  C:\Program\MyCorp\MyApplication1.2.0.0\MyApplication.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = VIRTUALXP-63912\XPMUser
LOG: DisplayName = MyCorp.MyApplication.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = file:///C:/Program/MyCorp/MyApplication1.2.0.0/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MyApplication.exe
Calling assembly : MyApplication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: Start binding of native image MyCorp.MyApplication.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
WRN: No matching native image found.
LOG: IL assembly loaded from C:\Program\MyCorp\MyApplication1.2.0.0\MyCorp.MyApplication.Core.dll.

Я также вижу этот вид журнала для сборки, даже когда программа завершает работу с сообщением can't load file or assembly SomeAssembly or one of its dependencies. Данная сборка загружается в соответствии с записью в журнале, аналогичной описанной выше.

Указывает ли это на то, что родная зависимость сборки не найдена? Нужно ли менять настройки журнала, чтобы увидеть, какая из собственных зависимостей вышла из строя, или есть что-то еще, что я могу сделать?

1 Ответ

0 голосов
/ 19 ноября 2013

Я думаю, это потому, что CLR предпринимает некоторые попытки поиска в dll, поэтому сначала он не работает, а затем завершается успешно.Вы можете привязаться к событию assemblyresolve и посмотреть, как оно работает.Если я помню, сначала выполняется поиск в GAC, затем в локальной папке, а затем во вложенных папках ...

См. Документацию здесь.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...