Что могло вызвать исключение System.TypeLoadException?

Это могло быть что угодно. Вероятные причины:

• Сборка не может быть найдена
• Сборка, от которой зависит ваша сборка, не может быть найдена
• Сборка найдена, но типа в ней нет
• Статический конструктор типа выдает исключение

Лучше всего использовать программу просмотра журналов Fusion, чтобы помочь в диагностике. Документация здесь:

http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx

(К вашему сведению «Fusion» было кодовым названием команды, которая разработала систему загрузки сборок; несколько прискорбно, что кодовое имя оказалось в имени файла поставляемого продукта. Это должно было называться «AssemblyBindingLogViewer.exe» или что-то такое.)

Ответ Эрика Липперта прекрасно описывает ситуацию.

Я просто хочу добавить быстрый ответ о случае, который обычно не описывается на страницах справки по этому исключению.

Я создал быстрый и грязный тестовый проект для некоторых вещей с открытым исходным кодом (Akka.Net, чтобы назвать его), и я назвал сам проект «Akka».

Он отлично строится, но при запуске выдает исключение типа load для класса в Akka.dll.

Это просто потому, что мой исполняемый файл (akka.exe) и ссылка (akka.dll) имеют одинаковое имя. Мне потребовалось несколько минут, чтобы понять это (я начал с таких вещей, как локальное копирование, целевая платформа, точная версия и т. Д.).

Это что-то очень глупое, но не обязательно первое, о чем вы подумаете (тем более, что я использовал nuget для зависимостей), поэтому я подумал, что было бы интересно поделиться им: вы столкнетесь с TypeLoadException, если ваш EXE и зависимость имеют одно и то же имя.

Это почти свело меня с ума ...

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

Удачи!

Это может быть вызвано множеством причин, как сказано в MSDN:

TypeLoadException возникает, когда среда CLR не может найти сборку, тип в сборке или не может загрузить тип.

Итак, ясно, что тип не может быть найден, либо отсутствует сборка, либо отсутствует тип, либо существует конфликт между конфигурациями среды выполнения.

Иногда проблема может возникнуть из-за того, что сборка, на которую вы ссылаетесь, является платформой другого типа (32-битная / 64-битная и т. Д.), Чем та, с которой вы используете.

Я бы порекомендовал перехватить исключение и изучить его более подробно, чтобы определить, с чем у него проблемы.

В соответствии с моей предыдущей информацией

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

Я обычно вижу это, когда речь идет о границах доменов приложений.

Один из способов, который, как я обнаружил, иногда решает проблему (но только если сборка уже находится в домене приложений), - это следующий фрагмент кода:

AppDomain.CurrentDomain.AssemblyResolve += (s, e) =>
{
   return AppDomain.CurrentDomain.GetAssemblies()
      .SingleOrDefault(asm => asm.FullName == e.Name);
}

Как я уже сказал, я вижу эту проблему, когда задействованы домены приложений, и, похоже, это решает ее, когда сборка действительно уже загружена и указана. Я понятия не имею, почему фреймворк не может разрешить саму ссылку.

Вы можете получить файлы журнала загрузчика из .NET Compact Framework, включив некоторые параметры в реестре. Power Toys для .NET Compact Framework включает инструмент называется NETCFLogging, который устанавливает для вас значения реестра.

Значения реестра задокументированы здесь:

http://msdn.microsoft.com/en-us/library/ms229650(v=VS.90).aspx

В моем случае проблема заключалась в том, что у меня было два проекта, которые использовали одни и те же библиотеки в одном решении. Я обновил библиотеки DLL только в первом проекте. Поэтому, когда я построил решение, второй проект переопределил его DLL из первого проекта (порядок сборки проекта).

Пример:

Решение:

--MainProject

------ MyDll v5.3.2.0

--Прототип

------ MyDll v5.0.0.0

Проблема исчезла после обновления DLL во втором проекте.

Убедитесь, что имена (пространства имен, имена классов и т. Д.) Такие, какими они должны быть. Я получил эту ошибку, когда мне пришлось начать работу над своим проектом, я скопировал содержимое моего класса из шаблона и не смог изменить имя класса с «Template Class» на правильное имя (оно должно было соответствовать имени проекта) .

строковый параметр typeName должен быть полностью определенным именем типа

Например: Activator.CreateInstance ("assemblyFullName", "namespace.typename")