Не вдалося завантажити тип від помилки збірки


120

Я написав наступний простий тест, намагаючись вивчити вільний інтерфейс 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()

Коли я виконую тест через GUI 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, тому я не переймався повторною компіляцією з джерела і просто взяв файли в директорії бін. Я також повинен зазначити, що мій проект складається без проблем.

Відповіді:


111

Чи може збірка в кеш-пам'яті глобальної асамблеї (GAC) або в будь-якому іншому місці перекрити збірку, яку, на вашу думку, завантажують? Зазвичай це результат завантаження неправильної збірки, для мене це означає, що у GAC зазвичай є щось, що перекриває версію, яку я маю в bin / Debug.


1
Я додав збірки, переглянувши файли dll, тому GAC не повинен входити в рівняння. Також клацніть правою кнопкою миші на збірці-> відкрити в рефлектор від програми Explorer виводить його в рефлектор з усією інформацією, яку я очікував
— Джордж Мауер

7
Не має значення, як ви додали його, якщо в GAC існує збірка з тим самим назвою / версією, вона завантажить цю.
— Ерік Шкоуновер

1
VS.NET перелічить шлях до вибраної вами збірки, і рефлектор відкриє потрібну збірку, але коли програма виконає .NET час виконання, завантажить збірку GAC.
— Ерік Шкуновер

11
Це другий раз, коли ця відповідь врятувала мій недопалок. Я б проголосував ще раз, якби міг.
— whybird

17
(ГАК. Скажіть це вголос. Сам звук назви попереджає вас про те, що це таке.)
— whybird

131

Якщо у вас є один проект, що посилається на інший проект (наприклад, тип "Додаток Windows", що посилається на "Бібліотеку класів"), і обидва мають однакове ім'я збірки, ви отримаєте цю помилку. Ви можете або вповноважено назвати посилається проект, або (ще краще) перейменувати складання проекту референції (на вкладці "Застосування" властивостей проекту у VS).


Крім того: спробуйте очистити вихідну папку. Можливо, перейменування бібліотек може спричинити ту саму проблему, оскільки обидва (старі та нові) будуть розміщені в одній папці виводу.
— Манушин Ігор

Якщо вирізати + вставити проект і не редагувати правильно всі поля, це може призвести до цієї проблеми!
— Майкл Паркер

1
Це було для мене, я вже посилався на Асамблею в бібліотеці згаданих класів. Мені довелося зайти у файл web.config мого веб-проекту та видалити посилання <dependantAssembly> після видалення пакета в nuGet, щоб він працював.
— Іван

16

Вирішення цього для мене не згадувалося вище, тому я думав, що додам свою відповідь довгим хвостом ...

У мене з’явилася стара посилання на клас (an HttpHandler) в web.config, який більше не використовувався (і більше не був дійсним посиланням). Чомусь його було ігноровано під час роботи в Studio (чи, можливо, у мене цей клас все ще доступний у моїй програмі налаштування розробників?), Тому я отримав цю помилку лише після спробу розгортання в IIS. Я шукав ім'я збірки в web.config, видалив невикористану посилання обробника, потім ця помилка пішла і все чудово працює. Сподіваюсь, це допомагає комусь іншому.


1
Було щось дуже схоже, лише різниця полягала в тому, що посилання web.config на DLL все ще було розгорнуто у директорії бін. Цей двійковий файл, у свою чергу, посилався на стару версію спільної DLL, що спричинило виняток.
— santos

10

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

Але, як натякали на це кілька користувачів, це стосується старої збірки, на яку все ще йдеться.

Рекомендую видалити всі "бін" / бінарні папки всіх проектів та переробити ціле рішення. Це вимило будь-які потенційно застарілі збірки і після цього MEF експортував усі мої плагіни без проблем.


8

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

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


3

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


Цікаво, що я отримав останню версію тут: builds.castleproject.org/cruise/DownloadBuild.castle?number=956 Це те, що вони рекомендували на своєму форумі. Також якщо б це було так, я думаю, що проект взагалі не складеться. Але це не створює жодних проблем
— Джордж Мауер

Щодо наявності версії в GAC, я, мабуть, так і є, але я не додав посилання від GAC і використання рефлектора на посилання вказує на те, що це саме те, про що я думав
— Джордж Мауер

Спробуйте вилучити дублікат збірки з GAC, я готовий бути таким, що є вашою проблемою.
— Ерік Шкоуновер

3

Я отримую це час від часу, і це завжди було недоступним для проведення зборів у GAC


3

Якщо ця помилка викликана зміною простору імен, зробіть так, що папку цього проекту перейменовано на однойменне, і закрийте VS.NET Редагуйте проект, у якого є проблема із «Блокнотом», і замініть там вузли

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


3

Видалення мого .pdb файла для dll вирішило цю проблему для мене. Я здогадуюсь, це має щось спільне з тим, що DLL був створений за допомогою ILMerge.


Це було для мене! Я не знаю, що таке ILMerge, але Epicor не любив мати файл pdb поруч із моєю збіркою.
— MDave

Ні ILMerge, але видалення всіх файлів PDB усунуло проблему.
— hogarth45

3

Коли я стикаюся з такою проблемою, я вважаю, що інструмент FUSLOGVW дуже корисний. Він перевіряє обов'язкову інформацію про складання і записує її до вас. Іноді бібліотеки відсутні, іноді GAC має різні версії, які завантажуються. Іноді проблеми з платформою посилаються на бібліотеки. Цей інструмент дає зрозуміти, як вирішуються прив'язки залежностей, і це дійсно може допомогти вам дослідити / налагодити свою проблему.

Переглядач журналів Fusion / Fuslogvw / Переглядач прив'язки журналу збірки. Перевірте більше / завантажте тут: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx .


Чи є спосіб змусити FUSLOGVW працювати з дизайнером Visual Studio? Дизайнер Visual Studio видає виняток, коли я намагаюся редагувати один із моїх діалогів ("Метод не знайдений") для методу, який я знаю, існує (додаток працює нормально). Наскільки я бачу, нічого не відображається у FUSLOGVW, коли щось редагується в Visual Studio Designer.
— Джиммі

3

У мене виникло це питання після факторизації назви класу:
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\
  • На моїй машині розробки це було (Тому що, можливо, його IIS Express?)
    %temp%\Temporary ASP.NET Files

3

Можливо, це не так імовірно, але для мене це було викликано моєю програмою, яка намагалася завантажити бібліотеку з тим же найменуванням збірки (xxx.exe loading xxx.dll).


2

Просто натрапите на це з іншою причиною:

Запуск тестів одиниць у режимі випуску, але завантажена бібліотека була версією режиму налагодження, яка не була оновлена


2

Ще одне рішення: старі DLL вказують один на одного та кешуються Visual Studio в Windows Vista

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

Вийдіть з VS, видаліть усе з цієї папки, а Боб - ваш дядько.


2

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


2

Я зіткнувся з цим сценарієм, намагаючись завантажити тип (через відображення) у збірці, яка була побудована проти іншої версії посилання, спільної для програми, де ця помилка вискакувала.

Оскільки я впевнений, що тип не змінився в обох версіях збірки, я в кінцевому підсумку створив власну розв'язувальну систему, яка відображає відсутню збірку на ту, яку вже завантажила моя програма. Найпростіший спосіб - додати статичний конструктор до класу програми так:

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

Звичайно, це передбачає, що збірка розташована в пусковому режимі програми і може бути легко адаптована.


Слід зазначити, що це рішення стосується випадків, коли ви збираєтеся зібрання стороннім особам і не можете переконатися, що кожен оновлюєсь саме в той час, коли ви це робите. В іншому випадку краща рекомпіляція з виправленими посиланнями.
— JBartlau

2

Просто натрапите на це з іншою причиною:

Я використовував об'єднану збірку, створену з ILRepack. Збірка, з якої ви запитуєте типи, повинна бути першою, переданою до ILRepack, або її типи будуть недоступні.



1

Зазвичай це відбувається, коли в GAC розміщено одну версію вашої збірки, але вона не була оновлена ​​новими класами, які ви могли б додати при складанні у вашому IDE. Тому переконайтеся, що збірка в GAC оновлюється змінами, які ви могли внести в проект.

Наприклад, якщо у вас є Бібліотека класів загальних і в цій бібліотеці класів у вас є тип Common.ClassA і розгорніть це в сильно названому GAC. Ви приходите пізніше і додаєте інший тип під назвою Common.ClassB і запускаєте свій код у своїй IDE, не попередньо розгортаючи внесені вами зміни в GAC загального за допомогою нещодавно доданого типу Common.ClassB.


1

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

У будь-якому випадку я оновив dll A і отримав помилку від іншого посилається на DLL, давайте назвемо його B тут, де dll A має посилання на dll B.

Оновлення dll B вирішило проблему.


1

Додавання DLL до GAC (глобальний кеш-зібрання)

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

gacutil / i "шлях до файлу dll"

Ви можете побачити додану збірку C: \ Windows \ system32 \

Він також вирішить відсутність DLL або "Не вдалося завантажити файл або збірку" в задачі сценарію SSIS


1
Зауважу, що додавання речей до GAC, як правило, є поганою ідеєю, ускладнює розгортання, і це взагалі те, від чого навіть відступає навіть Microsoft.
— Джордж Мауер

1

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

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

Після виконання цих кроків усі одиничні тести почали проходити під час запуску.


1

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

Я виявив, що один з проектів посилався на пакунок StrongNamer NuGet, який модифікує процес збирання та намагається підписати пакети Nuget, що не підписуються.

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


-2

Я щойно вирішив це, запустивши команду iisreset, використовуючи командний рядок ... Завжди перше, що я роблю, коли отримую такі помилки.


4
Вибачте, але це не має нічого спільного з питанням, робить припущення щодо використання iis і не пояснює, що відбувається, щоб викликати проблему.
— Джордж Мауер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.