Не удалось загрузить тип из-за ошибки сборки

Находится ли сборка в глобальном кэше сборок (GAC) или в другом месте, где она может переопределять сборку, которая, по вашему мнению, загружается? Обычно это результат загрузки неправильной сборки, для меня это означает, что у меня обычно есть что-то в GAC, заменяющее версию, которая у меня есть в bin / Debug.

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

Если у вас есть один проект, ссылающийся на другой проект (например, тип «Приложение Windows», ссылающийся на «Библиотеку классов»), и оба имеют одинаковое имя сборки, вы получите эту ошибку. Вы можете либо строго указать проект, на который имеется ссылка, либо (что еще лучше) переименовать сборку ссылающегося проекта (на вкладке «Приложение» свойств проекта в VS).

Я получаю это время от времени, и всегда было не так, чтобы сборка в GAC

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

В итоге у меня была старая ссылка на класс (HttpHandler) в web.config, который больше не использовался (и больше не был действительной ссылкой). По какой-то причине он был проигнорирован во время работы в Studio (или, может быть, этот класс все еще доступен в моей настройке разработчика?), Поэтому я получил эту ошибку только после того, как попытался развернуть в IIS. Я искал имя сборки в web.config, удалил неиспользуемую ссылку на обработчик, затем эта ошибка исчезла, и все отлично работает. Надеюсь, это поможет кому-то другому.

Возможно, вы сможете решить эту проблему с помощью перенаправления привязки в * .config. http://blogs.msdn.com/b/dougste/archive/2006/09/05/741329.aspx хорошо обсуждает использование старых компонентов .net в новых фреймворках. http://msdn.microsoft.com/en-us/library/eftw1fys(vs.71).aspx

Я получал эту ошибку, и ничего, что я нашел в StackOverflow или где-либо еще, не решило ее, но ответ бмоэскова на этот вопрос указал мне правильное направление для исправления, о котором еще не упоминалось в качестве ответа. Мой ответ не имеет прямого отношения к исходному вопросу, но я публикую его здесь, исходя из предположения, что кто-то, у кого есть эта проблема, найдет путь здесь через поиск в Google или что-то подобное (например, я через месяц, когда это снова укусит меня , аргу!).

Моя сборка находится в GAC, поэтому теоретически доступна только одна версия сборки. Кроме IIS помогает кэшировать старую версию и выдает мне эту ошибку. Я только что поменял, перестроил и переустановил сборку в GAC. Одно из возможных решений - использовать диспетчер задач, чтобы убить w3wp.exe. Это вынуждает IIS перечитать сборку из GAC: проблема решена.

Обычно это происходит, когда одна версия вашей сборки развернута в GAC, но не была обновлена ​​новыми классами, которые вы могли добавить в сборку в вашей среде IDE. Поэтому убедитесь, что сборка в GAC обновлена ​​с учетом изменений, которые вы могли внести в свой проект.

Например. если у вас есть библиотека классов Common и в этой библиотеке классов у вас есть тип Common.ClassA и разверните его в GAC со строгим именем. Вы приходите позже и добавляете еще один тип, называемый Common.ClassB, и запускаете свой код в своей среде IDE без предварительного развертывания изменений, которые вы внесли в GAC of Common с недавно добавленным типом Common.ClassB.

Просто столкнитесь с этим по другой причине:

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

У меня была такая же проблема, и для меня это не имело ничего общего с пространством имен или именованием проекта.

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

Я рекомендую удалить все "bin" / двоичные папки всех проектов и пересобрать все решение. Это смыло все потенциально устаревшие сборки, и после этого MEF экспортировал все мои плагины без проблем.

Просто столкнитесь с этим по другой причине:

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

Если эта ошибка вызвана изменением пространства имен, убедитесь, что папка этого проекта переименована с тем же именем, и закройте VS.NET Отредактируйте проект, в котором возникла проблема с Блокнотом, и замените там узлы.

"RootNamespace> New_Name_Of_Folder_Of_Your_Project_Namespace" RootNamespace> «AssemblyName> New_Name_Of_Folder_Of_Your_Project_Namespace» AssemblyName>

Еще одно решение: старые библиотеки DLL, указывающие друг на друга и кэшированные Visual Studio в

C:\Users\[yourname]\AppData\Local\Microsoft\VisualStudio.0\ProjectAssemblies

Выйдите из VS, удалите все в этой папке и ваш дядя Боб.

У меня возникла эта проблема после факторизации имени класса:
Could not load type 'Namspace.OldClassName' from assembly 'Assembly name...'.

Остановка IIS и удаление содержимого Temporary ASP.NET Files устранили это для меня.

В зависимости от вашего проекта (32/64-битная версия .net и т. д.) Правильный Temporary ASP.NET Files отличается:

• 64 бит
  %systemroot%\Microsoft.NET\Framework64\{.netversion}\Temporary ASP.NET Files\
• 32 бит
  %systemroot%\Microsoft.NET\Framework\{.netversion}\Temporary ASP.NET Files\
• На моей машине разработчика это было (возможно, потому, что это IIS Express?)
  %temp%\Temporary ASP.NET Files

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

В любом случае я обновил dll A и получил ошибку от другой библиотеки, на которую указывает ссылка, назовем ее здесь B, где dll A имеет ссылку на dll B.

Обновление dll B устранило проблему.

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

Добавление вашей DLL в GAC (глобальный кеш сборок)

Командная строка Visual Studio => Запуск от имени администратора

gacutil / i "путь к файлу dll"

Вы можете увидеть добавленную сборку C: \ Windows \ system32 \

Это также решит проблему отсутствия DLL или «Не удалось загрузить файл или сборку» в задаче сценария SSIS.

Я была такая же проблема. Я просто решил это, обновив сборку через GAC.

Чтобы использовать gacutil на машине разработки, перейдите по ссылке: Start -> programs -> Microsoft Visual studio 2010 -> Visual Studio Tools -> Visual Studio Command Prompt (2010).

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

gacutil /u myDLL

gacutil /i "C:\Program Files\Custom\mydllname.dll"

Примечание: я не удалял свою dll, в моем случае я только что обновил dll с текущим путем.

Удаление моего файла .pdb для dll решило эту проблему для меня. Я предполагаю, что это как-то связано с тем, что dll была создана с использованием ILMerge.

Когда я сталкиваюсь с такой проблемой, мне очень помогает инструмент FUSLOGVW. Он проверяет информацию о привязке сборки и записывает ее для вас. Иногда библиотеки отсутствуют, иногда у GAC загружаются разные версии. Иногда проблемы возникают из-за платформы ссылочных библиотек. Этот инструмент проясняет, как решаются привязки зависимостей, и это действительно может помочь вам исследовать / отладить вашу проблему.

Fusion Log Viewer / fuslogvw / Assembly Binding Log Viewer. Узнать больше / скачать здесь: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx.

Возможно, это не так вероятно, но для меня это было вызвано тем, что мое приложение пыталось загрузить библиотеку с тем же именем сборки (xxx.exe загружает xxx.dll).

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

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

using System.Reflection
static Program()
{
    AppDomain.CurrentDomain.AssemblyResolve += (sender, e) => {
        AssemblyName requestedName = new AssemblyName(e.Name);

        if (requestedName.Name == "<AssemblyName>")
        {
            // Load assembly from startup path
            return Assembly.LoadFile($"{Application.StartupPath}\<AssemblyName>.dll");
        }
        else
        {
            return null;
        }
    };
}

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

У меня возникла аналогичная проблема в Visual Studio 2017 с использованием MSTest в качестве среды тестирования. Я получал исключения System.TypeLoadException при запуске некоторых (не всех) модульных тестов, но эти модульные тесты проходили при отладке. В конечном итоге я сделал следующее, что решило проблему:

1. Откройте файл Local.testsettings в решении.
2. Зайдите в настройки "Unit Test"
3. Снимите флажок «Использовать контекст загрузки для сборок в тестовом каталоге». флажок

После выполнения этих шагов все модульные тесты начали проходить при запуске.

Я испытал то же самое, что и выше, после удаления подписи сборок в решении. Проекты строить не будут.

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

После удаления пакета StrongNamer я смог снова собрать проект без подписи / строгого именования сборок.

Если это приложение для Windows, попробуйте проверить наличие дубликата в глобальном кэше сборок (GAC). Что-то отменяет вашу версию bin / debug.

Если это веб-приложение, вам может потребоваться удалить его на сервере и повторно загрузить. Если вы публикуете, вы можете установить флажок Удалить все существующие файлы перед публикацией. В зависимости от версии Visual Studio он должен находиться в Publish> Settings> File Publish Options.

Хочу отметить еще несколько моментов и сделать вывод.

Обычно, как объяснили другие, это исключение возникает, когда возникает проблема с загрузкой ожидаемого типа (в существующей сборке) во время выполнения. Более конкретно: всякий раз, когда загруженная сборка устарела (и не содержит требуемый тип). Или когда уже загружена сборка с другой версией или сборкой, которая не содержит ожидаемого типа.

Кроме того, я должен упомянуть, что это кажется редким, но возможно ограничение времени выполнения или ошибка компилятора (предположим, что компилятор не отрицает что-то и просто скомпилировал проблемный код), но среда выполнения выдает исключение System.TypeLoadException. Да; это действительно произошло со мной!

Пример (ведьма пришла мне в голову)

Рассмотрим struct, который определяет внутри себя поле, допускающее значение NULL, собственного типа. Определение такого поля, не допускающего значения NULL, приведет к ошибке времени компиляции и предотвратит сборку (очевидно, такое поведение имеет логическую причину). Но как насчет заполненной структуры, допускающей значение NULL? Фактически, типы значений, допускающие значение NULL, находятся позади Nullable<T>. Поскольку компилятор C# не помешал мне определить это таким образом, я попробовал его, и проект был построен. Но я получаю исключение времени выполнения System.TypeLoadException: 'Could not load type 'SomeInfo' from assembly ... ', и, похоже, проблема с загрузкой части моего кода (в противном случае мы можем сказать: по крайней мере, компилятор не полностью выполнил процесс компиляции) для меня в моей среде:

public struct SomeInfo
{
   public SomeInfo? Parent { get; } 
   
   public string info { get; }
}

Характеристики моей среды:

• Visual Studio 2019 16.4.4
• Версия языка: C# 7.3
• Тип проекта: библиотека netstandard 2.0.3
• Время выполнения: классический DotNetFramework 4.6.1

(Я проверил и убедился, что скомпилированная сборка обновлена ​​и действительно скомпилирована заново. Я даже выбросил весь каталог bin и обновил весь проект. Даже я создал новый проект в новом решении и протестировал, Но такая структура генерирует исключение.)

Кажется, это ограничение времени выполнения (логически или технически) или ошибка или такая же проблема, потому что Visual Studio не мешает мне компилировать И также другие новые части моих кодов (за исключением этой структуры) работают нормально. При изменении struct на class скомпилированная сборка также содержит и выполняет тип.

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

Заключение

Проверьте ситуации:

• Когда такая же (возможно, более старая) сборка уже существует в GAC, которая переопределяет указанную сборку.

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

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

• Когда несоответствующая конфигурация вызвала требование к несуществующему типу с помощью настраиваемого инструмента или промежуточного программного обеспечения или стороннего исполняемого файла, который загружает сборку, и возникает необходимость обновить конфигурацию или очистить что-то (например, удаление обработчика http в файле web.config в IIS развертывание, как сказал @ Brian-Moeskau)

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