Метод не имеет реализации при загрузке сборок в новый домен приложения в режиме ReflectionOnly.

В нашем приложении (решение с 65 проектами) все ссылочные сборки анализируются во время выполнения на наличие модулей Ninject (также применяется некоторая фильтрация). Модули загружаются позже в ядро ​​Ninject, и каждый модуль объявляет привязки для ядра.

Мы приняли загрузчик, который загружает ссылочные сборки в отдельную сборку в режиме только отражения. Отличие от способа, которым Ninject может загружать сборки из каталога, состоит в том, что каталог может содержать сборки с модулями, которые не должны загружаться. А также в самом начале загружаются не все ссылочные сборки.

Проблема в том, что загрузчик (кредит Sacha Barber) не может загрузить некоторые сборки с

System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information

и LoaderExceptions с одной записью:

Method 'BeforeLoad' in type 'Lekis.AppBase.Core.BLLBaseCore' from assembly 'AppBaseCore, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.

Вот некоторые "забавные" факты:

  • метод BeforeLoad является виртуальным и реализация метода интерфейса
  • на прошлой неделе исключение загрузчика говорило, что другой метод не имеет реализации (этот метод не был виртуальным), а позже, когда я явно реализовал его, в сообщении говорилось, что метод не найден.
  • На прошлой неделе целевые рамки для сборки AppBaseCore Не удалось загрузить сборки.NET 3.5 и 3
  • теперь целевые рамки для сборки AppBaseCore не удается загрузить сборки.NET 4 и 5
  • с приложением все нормально иначе

Нет ничего плохого (очевидно) в сборках, когда я проверял их с помощью ILSpy и ILDAsm.

На данный момент я действительно потерян и не знаю, как подойти к этому вопросу.

Любая помощь приветствуется.

Спасибо

3 ответа

Решение

Отвечая на мой собственный вопрос:

Когда было сгенерировано исключение, я пошел по трассировке стека и перечислил сборки, загруженные в созданный дочерний домен приложения:

AppDomain.CurrentDomain.ReflectionOnlyGetAssemblies()
{System.Reflection.RuntimeAssembly[15]}
...
[13]: {System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089}
[14]: {System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089}

и заметил две версии System.Data сборка. У рассматриваемого метода есть параметр типа System.Data.IDbTransaction,

Первый упоминался в проекте, нацеленном на.NET Framework 3.5. После замены на 4.0 все работает нормально.

Что за глупая проблема...

Во время отладки я добавил исключение, а когда возникло исключение, я открыл окно Модули (Меню отладки -> Windows -> Модули или [Ctrl + D, M]), а затем понял, что мой код использует DLL из другого места, которое я ожидал, я заменил эту старую DLL на новую, и тогда она заработала.

Я только что столкнулся с подобной проблемой, я сделал интерфейс класса UserManager в Microsoft.AspNet.Identity.Core (для внедрения зависимостей через Unity). В модульном тесте я проверил регистрации Unity и столкнулся с этим исключением, даже если мое приложение скомпилировано правильно.

Оказывается, проект, который я тестировал, и в проекте Unit Test была установлена ​​другая версия Microsoft.AspNet.Identity.Core (отображается через диспетчер пакетов NuGet)

Другие вопросы по тегам