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, скопируйте две библиотеки в каталог проекта, добавьте ссылки на файлы и добавьте следующий код в метод Main:

    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 дал более полезную ошибку: «Система не может найти указанный файл».

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

Исключение было вызвано, когда я попытался установить один из их сопряженных классов во время выполнения. Мы убедились, что все остальные ссылки были актуальны, но все же не повезло. Нам потребовалось некоторое время, чтобы определить (с помощью обозревателя объектов), что возвращаемый тип метода в сообщении об ошибке был совершенно новым типом из новой сборки без ссылки.

Добавили ссылку на сборку и ошибка исчезла.

• Сообщение об ошибке вводило в заблуждение, но более или менее указывало на правильное направление (правильный метод, неправильное сообщение).
• Исключение произошло, хотя мы не использовали этот метод.
• Что приводит меня к вопросу: если это исключение выдается в любом случае, почему компилятор не подхватывает его?

Я получил эту ошибку в следующем сценарии.

• Обе сборки A и B ссылались на System.Web.Mvc версии 3.0.0.0.
• Assembly A ссылалась на Assembly B и имела классы, которые реализовывали интерфейсы из Assembly 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, чем в настоящее время

надеюсь, что это поможет кому-то - мне понадобились годы, чтобы понять это.

У меня тоже была эта ошибка, это было вызвано тем, что Any CPU exe ссылается на любые сборки CPU, которые в свою очередь ссылаются на сборку x86.

Исключение жаловалось на метод для класса в MyApp.Implementations (Any CPU), который получил MyApp.Interfaces (Any CPU), но в fuslogvw.exe я обнаружил скрытую исключение «попытка загрузить программу с неверным форматом» из MyApp .CommonTypes (x86), который используется обоими.

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

Решение этой проблемы состоит в том, чтобы вручную удалить файлы bin в каталоге ваших проектов. Это очистит все ссылки и заставит проект использовать последние DLL.

Я не предлагаю использовать функцию удаления инструментов публикации, потому что это приводит к удалению IIS.

У меня есть еще одно эзотерическое решение этого сообщения об ошибке. Я обновил свою целевую платформу с .Net 4.0 до 4.6, и мой проект модульного тестирования выдавал мне ошибку «System.TypeLoadException ... не имеет реализации» при попытке сборки. Он также дал второе сообщение об ошибке о том же якобы не реализованном методе, который гласил: «Задача« BuildShadowTask »неожиданно завершилась неудачей». Похоже, что ни один из советов здесь не помог, поэтому я искал «BuildShadowTask» и нашел сообщение в MSDN, в котором я использовал текстовый редактор для удаления этих строк из файла csproj проекта модульного тестирования.

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

После этого обе ошибки исчезли и проект был построен.

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

При выполнении операции разрешения Autofac среда выполнения не сможет загрузить одну из сборок. Сообщение об ошибке жаловалось на это Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Симптомы возникали при работе на виртуальной машине 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. На моей виртуальной System.Collections.Immutableмашине Windows Server 2012 R2 GAC содержал копию 1.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, но не проект B, что позволило проекту B «внедрить» старую версию Project Dll

Я столкнулся с этим, когда переименовал проект (и имя сборки), от которого зависел проект ASP.NET. Типы в веб-проекте реализованы интерфейсами в зависимой сборке. Несмотря на выполнение Clean Solution из меню 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 вы должны использовать Load. Следующий код сделает работу:

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что вызывает проблему , как заявил Ayende Rahien в списке рассылки Rhino издевается .

Я просто обновил решение с MVC3 до MVC5 и начал получать то же исключение из моего проекта модульного тестирования.

Проверил все ссылки, ища старые файлы, в конечном итоге обнаружил, что мне нужно было выполнить несколько bindingRedirects для 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.

Я получил исключение при открытии 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». Кроме того, я установил несколько пакетов nuget для .net 4.5.1 на все три сборки. По какой-то причине, даже несмотря на то, что ссылки на nuget не отображались в сборке «B», он создавался успешно.

Оказалось, что реальная проблема заключалась в том, что сборки ссылались на разные версии пакета nuget, который содержал интерфейс, и сигнатура интерфейса менялась между версиями.

В моем случае я ранее ссылался на mylibпроект в папке одного уровня за пределами репозитория - давайте назовем это v1.0.

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

Позже я сделал это правильно и использовал его через подмодуль git - давайте назовем это v2.0. Однако один проект consoleAppне был обновлен должным образом. Он все еще ссылался на старый v1.0проект за пределами моего git-проекта.

Заблуждение , хотя это *.csprojбыло явно неправильно и указывало на v1.0, IDE Visual Studio показывал путь как v2.0проект! F12 для проверки интерфейса и класса пошел на v2.0версию тоже.

Сборка, помещенная компилятором в папку bin, была v1.0версией, отсюда и головная боль.

Тот факт, что IDE лгал мне, очень усложнил понимание ошибки.

Решение : ConsoleAppудалили ссылки на проекты и прочитали их.

Общий совет: Перекомпилируйте все сборки с нуля (где это возможно, конечно, нельзя для пакетов nuget) и проверьте метки даты и времени в bin\debugпапке. Любые старые датированные сборки - ваша проблема.

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

На Google, я получил эту ссылку среди других. Основываясь на комментарии @Paul McLink, эти два шага решили проблему.

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

и ошибка ушла .

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

Спасибо Пол :)

Надеюсь, это поможет кому-то, кто сталкивался с этой ошибкой :)

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

Я видел это в Visual Studio Pro 2008, когда два проекта создавали сборки с одинаковыми именами, один из них - класс lib SDF.dll, а другой - ссылался на библиотеку с именем сборки 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 оказались в правильных местах (я не буду вдаваться в подробности того, как это произошло в первую очередь).

У меня такая же проблема. Я выяснил, что моя сборка, которая загружается основной программой, имеет некоторые ссылки с «Копировать локальный», установленный в true. Эти локальные копии ссылок искали другие ссылки в той же папке, которых не было, поскольку для параметра «Копировать локально» других ссылок было установлено значение false. После удаления «случайно» скопированных ссылок ошибка исчезла, поскольку основная программа была настроена на поиск правильных местоположений ссылок. Очевидно, локальные копии ссылок испортили последовательность вызовов, потому что эти локальные копии использовались вместо оригинальных, присутствующих в основной программе.

Сообщение возврата домой состоит в том, что эта ошибка появляется из-за отсутствия ссылки для загрузки требуемой сборки.

В моем случае я пытался использовать TypeBuilderдля создания типа. TypeBuilder.CreateTypeбросил это исключение. В конце концов я понял, что мне нужно добавить MethodAttributes.Virtualк атрибутам при вызове TypeBuilder.DefineMethodметода, который помогает реализовать интерфейс. Это связано с тем, что без этого флага метод не реализует интерфейс, а представляет собой новый метод с той же сигнатурой (даже без указания MethodAttributes.NewSlot).

В качестве дополнения: это также может произойти, если вы обновите пакет nuget, который использовался для создания поддельной сборки. Допустим, вы устанавливаете V1.0 пакета nuget и создаете сборку подделок "fakeLibrary.1.0.0.0.Fakes". Затем вы обновляете до последней версии пакета nuget, скажем, v1.1, который добавил новый интерфейс в интерфейс. Библиотека Fakes все еще ищет v1.0 библиотеки. Просто удалите поддельную сборку и восстановите ее. Если это была проблема, это, вероятно, исправит это.

Я получил эту ошибку после недавнего обновления Windows. У меня был установлен класс обслуживания для наследования от интерфейса. Интерфейс содержал подпись, которая возвращала ValueTuple, довольно новую функцию в C #.

Все, что я могу догадаться, это то, что обновление Windows установило новое, но даже явно ссылается на него, обновляет перенаправления привязки и т. Д. Конечным результатом было просто изменение сигнатуры метода на нечто «стандартное», я думаю, вы могли бы сказать.