Что может быть причиной исключения System.TypeLoadException?

Я разрабатываю для VS2008 с использованием С# приложение для Honeywell Dolphin 6100, мобильного компьютера со сканером штрих-кода, который использует Windows CE 5.0, например, ОС.

Я хочу добавить функциональность, которая может отправлять файлы с локального устройства на удаленный сервер. Я нашел библиотеку " Tamir.SharpSSH ", которая может это гарантировать. Я проверил код на консольном приложении и на обычном приложении Windows Forms, и он работает отлично. Но когда я пытался использовать тот же код на устройстве winCE, я получаю исключение TypeLoadException и у меня появляется сообщение об ошибке:

Could not load type 'Tamir.SharpSsh.SshTransferProtocolBase' from assembly 'Tamir.SharpSSH,   
Version=1.1.1.13, Culture=neutral, PublicKeyToken=null'.

код, который я использую, как показано ниже:

SshTransferProtocolBase sshCp = new Scp(Tools.GlobalVarMeth.hostName, Tools.GlobalVarMeth.serverUserName);
sshCp.Password = Tools.GlobalVarMeth.serverUserpassword;
sshCp.Connect();

string localFile = Tools.GlobalVarMeth.applicationPath + "/" + fileName + ".csv";
string remoteFile = Tools.GlobalVarMeth.serverRemoteFilePath + "/" + fileName + ".csv";

sshCp.Put(localFile, remoteFile);

sshCp.Close();

У кого-нибудь есть идеи по этому поводу? Я буду очень благодарен !!!

Ответ 1

Это может быть любое количество вещей. Возможные причины:

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

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

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

(FYI "Fusion" было кодовым именем команды, которая спроектировала систему загрузки сборок, несколько неудачно, что кодовое имя оказалось в имени файла отправленного продукта. Вещь должна была называться "AssemblyBindingLogViewer". exe "или некоторые такие вещи.)

Ответ 2

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

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

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

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

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

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

Ответ 3

Это может быть вызвано любым количеством вещей, в MSDN сказано:

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

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

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

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

В дополнение к моей предыдущей информации

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

Обычно я вижу это, когда задействованы границы AppDomain.

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

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

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

Ответ 4

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

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

Удачи!

Ответ 5

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

Значения реестра описаны здесь:

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

Ответ 6

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

Пример:

Решение:

- MainProject

------ MyDll v5.3.2.0

- Прототип

------ MyDll v5.0.0.0

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

Ответ 7

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