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

Я написал следующий простой тест, пытаясь изучить свободный интерфейс Castle Windsor:

using NUnit.Framework;
using Castle.Windsor;
using System.Collections;
using Castle.MicroKernel.Registration;

namespace WindsorSample {
    public class MyComponent : IMyComponent {
        public MyComponent(int start_at) {
            this.Value = start_at;
        }
        public int Value { get; private set; }
    } 
    public interface IMyComponent {
        int Value { get; }
    }

    [TestFixture]
    public class ConcreteImplFixture {
        [Test]
        public void ResolvingConcreteImplShouldInitialiseValue() {
            IWindsorContainer container = new WindsorContainer();
            container.Register(Component.For<IMyComponent>().ImplementedBy<MyComponent>().Parameters(Parameter.ForKey("start_at").Eq("1")));
            IMyComponent resolvedComp = container.Resolve<IMyComponent>();
            Assert.AreEqual(resolvedComp.Value, 1); 
        }
    }
}

Когда я выполняю тест через TestDriven.NET, я получаю следующую ошибку:

System.TypeLoadException : Could not load type 'Castle.MicroKernel.Registration.IRegistration' from assembly 'Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'.
at WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue()

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

WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue:
System.IO.FileNotFoundException : Could not load file or assembly 'Castle.Windsor, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The system cannot find the file specified.

Если я открываю сборку, на которую я ссылаюсь в Reflector, я вижу, что ее информация:

Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc

и что он определенно содержит Castle.MicroKernel.Registration.IRegistration

Что могло происходить?

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

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

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

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

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

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

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

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

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

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

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

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

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

"RootNamespace> New_Name_Of_Folder_Of_Your_Project_Namespace" RootNamespace> "AssemblyName> New_Name_Of_Folder_Of_Your_Project_Namespace" AssemblyName>

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

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

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

У меня возникла эта проблема после факторизации имени класса:
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

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

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

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

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

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

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

Я была такая же проблема. Я просто решил это, обновив сборку через 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 с текущим путем.

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

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

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;
        }
    };
}

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

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

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

Возможно, вы сможете решить эту проблему с помощью перенаправления привязки в * .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

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

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

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

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

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

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

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

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

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

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

У меня возникла аналогичная проблема в 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.

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