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

Question

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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