TypeLoadException говорить "немає реалізації", але він реалізований

На нашому тестовому апараті у мене дуже дивна помилка. Помилка:

System.TypeLoadException: Method 'SetShort' in type 'DummyItem' from assembly 'ActiveViewers (...)' does not have an implementation.

Я просто не можу зрозуміти, чому. SetShortє в DummyItemкласі, і я навіть перекомпілював версію з записом до журналу подій, щоб переконатися, що це не проблема розгортання / версії. Дивна річ у тому, що викликовий код навіть не викликає SetShortметод.

ПРИМІТКА. Якщо ця відповідь вам не допомагає, знайдіть час, щоб прокрутити вниз інші відповіді, які люди додали з тих пір.

Коротка відповідь

Це може статися, якщо ви додасте метод до інтерфейсу в одній збірці, а потім до класу реалізації в іншій збірці, але ви відновлюєте монтажну збірку без посилання на нову версію збірки інтерфейсу.

У цьому випадку DummyItem реалізує інтерфейс з іншої збірки. Нещодавно доданий метод SetShort до інтерфейсу та DummyItem - але збірка, що містить DummyItem, була відновлена ​​з посиланням на попередню версію складання інтерфейсу. Таким чином, метод SetShort ефективно існує, але без чарівного соусу, який пов'язує його з еквівалентним методом в інтерфейсі.

Довга відповідь

Якщо ви хочете спробувати відтворити це, спробуйте наступне:

1. Створіть проект бібліотеки класів: InterfaceDef, додайте лише один клас та складіть:

   public interface IInterface
   {
       string GetString(string key);
       //short GetShort(string key);
   }

2. Створіть проект бібліотеки другого класу: реалізація (з окремим рішенням), скопіюйте InterfaceDef.dll у каталог проектів та додайте як посилання на файл, додайте лише один клас та складіть:

   public class ImplementingClass : IInterface
   {
       #region IInterface Members
       public string GetString(string key)
       {
           return "hello world";
       }
   
       //public short GetShort(string key)
       //{
       //    return 1;
       //}
       #endregion
   }

3. Створіть третій консольний проект: ClientCode, скопіюйте два dll у каталог проектів, додайте посилання на файли та додайте наступний код у Основний метод:

    IInterface test = new ImplementingClass();
    string s = test.GetString("dummykey");
    Console.WriteLine(s);
    Console.ReadKey();

4. Запустіть код один раз, на консолі написано "привіт, світ"

5. Відкоментуйте код у двох проектах dll та відновіть - скопіюйте два dll назад у проект ClientCode, відновіть і спробуйте запустити ще раз. TypeLoadException виникає при спробі інстанціювати клас ImplementingClass.

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

public interface IFoo
{
    void DoFoo();
}

public class Foo : IFoo
{
    public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
    void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}

Foo foo = new Foo();
foo.DoFoo();               // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo();              // This calls the interface method

Я зрозумів це, коли в моїй програмі не було посилання на іншу збірку, що визначала клас, який використовувався метод у повідомленні про помилку. Запуск PEVerify дав кориснішу помилку: "Система не може знайти вказаний файл."

Я наткнувся на те саме повідомлення, і ось що ми знайшли: Ми використовуємо сторонні длз у нашому проекті. Після того, як вийшов новий реліз, ми змінили наш проект, щоб вказати на новий набір dlls і склали успішно.

Виняток було кинуто, коли я намагався встановити один із їх взаємозалежних класів під час виконання. Ми переконалися, що всі інші посилання були актуальними, але все-таки не пощастило. Нам знадобився деякий час, щоб помітити (за допомогою браузера об’єктів), що тип повернення методу у повідомленні про помилку був абсолютно новим типом з нової невідредагованої збірки.

Ми додали посилання на збірку і помилка зникла.

• Повідомлення про помилку було досить оманливим, але вказувало більш-менш на правильний напрямок (правильний метод, неправильне повідомлення).
• Виняток стався, навіть якщо ми не використовували відповідний метод.
• Що призводить мене до питання: Якщо цей виняток кинутий у будь-якому випадку, чому компілятор не підбирає його?

Я отримав цю помилку за наступним сценарієм.

• Обидві збірки A і B посилаються на System.Web.Mvc версії 3.0.0.0
• Асамблея Посилальна збірка B і мала класи, які реалізовували інтерфейси від Асамблеї B методами, які повертали класи з System.Web.Mvc.
• Асамблея Оновлено до System.Web.Mvc версії 4.0.0.0
• Асамблея C запустила код нижче (FertPin.Classes.Contact містився в Асамблеї A):

var target = Assembly.GetAssembly(typeof(FertPin.Classes.Contact));

Виправленням для мене було оновлення посилання System.Web.Mvc в Асамблеї B до 4.0.0.0. Зараз здається очевидним!

Дякуємо оригінальному афіші!

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

• Проект asp.net містить збірку A і збірку B, B чітко названі

• збірка A використовує Activator.CreateInstance для завантаження збірки C (тобто немає посилання на C, який будується окремо)

• C був побудований з посиланням на більш стару версію збірки B, ніж зараз

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

У мене була і ця помилка, вона була викликана будь-яким exe exe, що посилається на будь-які збори процесора, які, в свою чергу, посилаються на збірку x86

Виняток скаржився на метод класу в MyApp.Implementations (будь-який процесор), який виводив MyApp.Interfaces (будь-який процесор), але в fuslogvw.exe я виявив приховану "спробу завантаження програми з неправильним форматом" виключення з MyApp .CommonTypes (x86), який використовується обома.

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

Рішення цього полягає в ручному видаленні файлів бін у вашому опублікованому каталозі проектів. Це очистить усі посилання та змусить проект використовувати найновіші DLL-файли.

Я не пропоную використовувати функцію видалення інструментів видалення, оскільки це, як правило, скидає IIS.

У мене є ще одне езотеричне рішення цього повідомлення про помилку. Я модернізував цільовий фреймворк з .Net 4.0 до 4.6, і мій тестовий проект модуля дав мені помилку "System.TypeLoadException ... не має реалізації", коли я намагався створити. Він також дав друге повідомлення про помилку про той самий нібито не реалізований метод, у якому сказано, що "Задача" BuildShadowTask "несподівано не вдалася". Жодна порада тут, здавалося, не допомогла, тому я шукав "BuildShadowTask" і знайшов допис на MSDN, який привів мене до використання текстового редактора для видалення цих рядків із файлу csproj проекту тестового проекту.

<ItemGroup>
  <Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>

Після цього обидві помилки відійшли і проект побудований.

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

Під час виконання операції з роздільною здатністю автофактора час виконання не вдасться завантажити одну з вузлів. Повідомлення про помилку скаржилося на це Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Симптоми виникали під час роботи на VM для Windows Server 2012 R2, але не виникали у вітринах Windows 10 або Windows Server 2016.

ImplementationAssemblyз посиланням на System.Collections.Immutable1.1.37 і містив реалізацію IMyInterface<T1,T2>інтерфейсу, який був визначений окремо DefinitionAssembly. DefinitionAssemblyпосилання System.Collections.Immutable1.1.36.

Методи, з IMyInterface<T1,T2>яких «не було реалізовано», мали параметри типу IImmutableDictionary<TKey, TRow>, що визначено в System.Collections.Immutable.

Фактична копія System.Collections.Immutableзнайденого в каталозі програм була версією 1.1.37. У моєму Windows Server 2012 R2 VM GAC містив копію System.Collections.Immutable1.1.36. В ОС Windows 10 та Windows Server 2016 GAC містив копію System.Collections.Immutable1.1.37. Помилка завантаження сталася лише тоді, коли GAC містив старішу версію DLL.

Отже, першопричиною збою завантаження збірки було невідповідність посилань на System.Collections.Immutable. Визначення та реалізація інтерфейсу мали однакові на вигляд підписи методу, але насправді залежали від різних версій System.Collections.Immutable, що означало, що час виконання не вважає клас реалізації відповідним визначенню інтерфейсу.

Додавання наступного переадресації прив'язки до мого файлу конфігурації програми виправило проблему:

<dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.1.37.0" newVersion="1.1.37.0" />
</dependentAssembly>

Я отримав це залежно від проекту "алмазна" форма:

• Проект A використовує проект B та проект D
• Проект B використовує проект D

Я перекомпілював проект A, але не Project B, який дозволив Project B "вводити" стару версію dll Project Project

Я зіткнувся з цим, коли перейменував проект (і назву збірки), від якого залежав проект ASP.NET. Типи веб-проекту реалізують інтерфейси залежної збірки. Незважаючи на виконання чистого рішення з меню Build, збірка з попередньою назвою залишилася в binпапці, і коли мій веб-проект виконаний

var types = AppDomain.CurrentDomain.
   GetAssemblies().
   ToList().
   SelectMany( s => s.GetTypes() /* exception thrown in this call */ )
;

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

Я також отримав цю помилку, коли я раніше ввімкнув покриття коду під час тестування одиниць для однієї з вузлів. Чомусь Visual Studio "забудував" стару версію цього конкретного DLL, навіть якщо я оновив її, щоб реалізувати нову версію інтерфейсу. Відключення Покриття коду позбулося помилки.

Ця помилка також може бути викликана, якщо збірка завантажується за допомогою Assembly.LoadFrom (String) і посилається на збірку, яка вже була завантажена за допомогою Assembly.Load (Byte []).

Наприклад, ви вбудували посилання на основну програму як ресурси, але додаток завантажує плагіни з певної папки.

Замість використання LoadFrom слід використовувати LoadFrom. Наступний код зробить роботу:

private static Assembly LoadAssemblyFromFile( String filePath )
{
    using( Stream stream = File.OpenRead( filePath ) )
    {
        if( !ReferenceEquals( stream, null ) )
        {
            Byte[] assemblyData = new Byte[stream.Length];
            stream.Read( assemblyData, 0, assemblyData.Length );
            return Assembly.Load( assemblyData );
        }
    }
    return null;
}

Ще одне пояснення цього типу проблем, пов’язаних із керованим C ++.

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

Це справедливо для Rhino Mocks і, ймовірно, будь-якої знущальної рамки, яка використовує System.Reflection.Emit.

public interface class IFoo {
  void F(long bar);
};

public ref class Foo : public IFoo {
public:
  virtual void F(long bar) { ... }
};

Визначення інтерфейсу отримує такий підпис:

void F(System.Int32 modopt(IsLong) bar)

Зауважте, що тип C ++ longвідображає System.Int32(або просто intв C #). Саме дещо незрозуміло modoptвикликає проблему , про яку заявила Айенде Рахієн у списку розсилки Rhino Mocks .

Я щойно оновив рішення з MVC3 до MVC5 і почав отримувати той самий виняток з мого тестового проекту Unit.

Перевірив усі посилання на пошуки старих файлів, в остаточному підсумку виявив, що мені потрібно виконати кілька зв’язувальних редиректорів для Mvc у своєму проектному тестовому проекті.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

У моєму випадку це допомогло скинути WinForms Toolbox.

Я отримав виняток під час відкриття Formдизайнера; однак компілювання та запуск коду було можливим, і код поводився так, як очікувалося. Виняток стався в локальній UserControlреалізації інтерфейсу однієї з моїх посилань на бібліотеки. Помилка з’явилася після оновлення цієї бібліотеки.

Це UserControlбуло зазначено у панелі інструментів WinForms. Ймовірно, Visual Studio зберігав посилання на застарілу версію бібліотеки або десь кешував застарілу версію.

Ось як я оговтався від цієї ситуації:

1. Клацніть правою кнопкою миші на панелі інструментів WinForms і натисніть на Reset Toolboxв контекстному меню. (Це видаляє власні елементи з Панелі інструментів).
   У моєму випадку елементи панелі інструментів були відновлені до стану за замовчуванням; проте стрілка вказівника відсутня в панелі інструментів.
2. Закрити Visual Studio.
   У моєму випадку Visual Studio припиняється за винятком порушення та скасовується.
3. Перезапустіть Visual Studio.
   Зараз все працює без проблем.

FWIW, я отримав це, коли з’явився файл конфігурації, який був перенаправлений на неіснуючу версію посилальної збірки. Fusion журнали на виграш!

Я отримав цю помилку, тому що у мене був клас у складі "C", який знаходився у версії 4.5 фреймворку, реалізуючи інтерфейс у зборі "A", який був у версії 4.5.1 фреймворку і слугував базовим класом для складання 'B', який також був у версії 4.5.1 фреймворку. Система кинула виняток, намагаючись завантажити збірку "B". Крім того, я встановив декілька натурних пакетів, орієнтованих на .net 4.5.1, на всі три збірки. Чомусь незважаючи на те, що чіткі посилання не відображалися в збірці "B", він будувався успішно.

Виявилося, що справжньою проблемою було те, що збірки посилалися на різні версії нукетного пакету, що містили інтерфейс, а підпис інтерфейсу змінювався між версіями.

У моєму випадку я раніше посилався на mylibпроект у папці братів за межами репо - називаємо це v1.0.

|-- myrepo
|    |-- consoleApp
|    |-- submodules
|         |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)

Пізніше я це зробив належним чином і використовував його через підмодуль git - дозволяє так зателефонувати v2.0. consoleAppОднак один проект не був оновлений належним чином. Він все ще посилався на старий v1.0проект поза моїм git-проектом.

Конфузно , незважаючи на те, що *.csprojявно помилявся і вказував v1.0, Visual Studio IDE показав шлях як v2.0проект! F12 для перевірки інтерфейсу та класу також пішов у v2.0версію.

Збірка, поміщена компілятором у папку бін, була v1.0версією, отже, головний біль.

Цей факт, що ІДЕ брехав мені, ускладнив усвідомлення помилки.

Рішення : Видалено посилання на проект з ConsoleAppта перечитано їх.

Загальна порада: Перекомпілюйте всі збори з нуля (де це можливо, не можна для нудних пакетів, звичайно) та перевірте позначення дат часу в bin\debugпапці. Будь-яка стара датова збірка - ваша проблема.

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

На Googling я отримав це посилання серед інших. На основі коментаря @Paul McLink, ці два кроки вирішили проблему.

1. Перезапустіть Visual Studio
2. Очистити, побудувати (відновити)

і помилка зникла .

Перезапустіть плагін VS

Дякую Пол :)

Сподіваюся, це допоможе тому, хто натрапив на цю помилку :)

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

Я бачив це в Visual Studio Pro 2008, коли два проекти будували збірки з однаковою назвою, один клас lib SDF.dll і той, що посилався на lib з назвою асемблери sdf.exe. Коли я змінив назву референтної збірки, виняток пішов

Це просто означає, що проект реалізації в моїх випадках застарів. DLL, що містить інтерфейс, був відновлений, але DLL реалізації був застарілим.

Ось мій погляд на цю помилку.

Додано externметод, але моя паста була несправною. DllImportAttributeОтримав надів закоментувавши лінії.

/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")] 
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);

Переконання, що атрибут був фактично включений у джерело, виправлене проблемою.

Я отримав це в службі WCF через те, що вибрано тип збірки x86, внаслідок чого бункери живуть під bin \ x86 замість bin. Вибір будь-якого процесора змусив перекомпільовані DLL переходити до правильних місць (я не буду детально описуватись, як це сталося в першу чергу).

У мене була така ж проблема. Я зрозумів, що моя збірка, яку завантажує основна програма, мала деякі посилання з "Copy Local", встановленими на true. Ці локальні копії посилань шукали інші посилання в тій самій папці, які не існували, оскільки "Копіювати локальні" інших посилань було встановлено на помилку. Після видалення "випадково" скопійованих посилань помилка зникла, оскільки основна програма була налаштована на пошук правильних розташувань посилань. Мабуть, локальні копії посилань накрутили послідовність виклику, оскільки ці локальні копії використовувались замість оригіналів, присутніх у головній програмі.

Повідомлення «взяти додому» полягає в тому, що ця помилка з’являється через відсутність посилання для завантаження необхідної збірки.

У моєму випадку я намагався використовувати TypeBuilderдля створення типу. TypeBuilder.CreateTypeкинув цей виняток. Зрештою я зрозумів, що мені потрібно додати MethodAttributes.Virtualдо атрибутів при виклику TypeBuilder.DefineMethodметоду, який допомагає реалізувати інтерфейс. Це тому, що без цього прапора метод не реалізує інтерфейс, а навпаки новий метод з тією ж підписом (навіть без вказівки MethodAttributes.NewSlot).

Як додаток: це також може статися, якщо ви оновите нут-пакет, який використовувався для створення підробленої збірки. Скажімо, ви встановлюєте V1.0 нульового пакету та створюєте підроблювальну збірку "fakeLibrary.1.0.0.0.Fakes". Далі ви оновлюєте до новітньої версії пакету nuget, скажімо, v1.1, яка додала новий метод в інтерфейс. Бібліотека Fakes досі шукає v1.0 бібліотеки. Просто вийміть підроблений вузол і відновіть його. Якщо це було проблемою, це, ймовірно, виправить.

Я отримав цю помилку після недавнього оновлення Windows. У мене був встановлений клас обслуговування для успадкування від інтерфейсу. Інтерфейс містив підпис, який повернув ValueTuple, досить нову функцію в C #.

Я можу здогадатися лише про те, що оновлення Windows встановило нове, але навіть явно посилалося на нього, оновило переадресації прив’язки тощо. Кінцевим результатом було лише зміна підпису методу на щось "стандартне". Я думаю, ви могли б сказати.