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

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

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. Я должен также указать, что мой проект компилируется без проблем.

Ответы

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

Fusion Log Viewer/fuslogvw/просмотрщик привязки в сборе. Подробнее/скачайте здесь: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx.

Ответ 11

Просто выполните это с другой целью:

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

Ответ 12

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

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

Ответ 13

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

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

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

Ответ 14

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

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

В зависимости от вашего проекта (версия 32/64bit,.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\
  • На моей машине dev это было (потому что его IIS Express может быть?)
    %temp%\Temporary ASP.NET Files

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

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

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

Ответ 19

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

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

Ответ 20

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

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

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

Ответ 21

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

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

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

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

Он также решит, что dll отсутствует или "Не удалось загрузить файл или сборку" в задаче SSIS Script

Ответ 22

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

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

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

Ответ 23

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

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

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

Ответ 24

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