TypeLoadException говорит «нет реализации», но оно реализовано

270

У меня очень странная ошибка на нашей тестовой машине. Ошибка:

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

Я просто не могу понять почему. SetShortесть в DummyItemклассе, и я даже перекомпилировал версию с записью в журнал событий, просто чтобы убедиться, что это не проблема развертывания / управления версиями. Странно то, что вызывающий код даже не вызывает SetShortметод.

Benjol
источник
15
Мне нравится, как вы поделились своим опытом с сообществом, чтобы помочь всем нам, и даже побудили нас прочитать и другие ответы, спасибо. К сожалению, ни одно из предложений не сработало для меня. Хотите знать, что в итоге сработало для меня? Перезапуск Visual Studio. Почему я не попробовал это сначала?
Пол Маклин
Спасибо, Пол, прочитав твой комментарий, я попробовал его первым. Работал как шарм :-)
Jan_V
спасибо Пол, спаси меня несколько часов, непрерывно царапая мою голову, как обезьяна ...
Кьен Чу
Кроме того, после обновления VS 2017 до 15.7 VS сообщает вам перезагрузиться. Вы, возможно, не сделали этого (как я, из-за встреч, которые я забыл). Я получил дерьмо из ошибок, подобных этим ...
Построен
Просто чтобы добавить мой 2p - я получил эту проблему при запуске модульных тестов в MsTest. Тестируемые классы были в подписанной сборке. Другая версия этой сборки оказалась в GAC. MsTest собирал сборку GAC вместо того, чтобы использовать сборку из папки bin, и пытался запустить тесты для нее, которая, очевидно, не работала. Решением было удалить сборку GAC
Том Редферн

Ответы:

244

ПРИМЕЧАНИЕ. - Если этот ответ вам не поможет, найдите время, чтобы прокрутить список других ответов, добавленных с тех пор.

Короткий ответ

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

В этом случае 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.

Benjol
источник
1
Возможно, вам придется добавить, что консольное приложение должно быть перестроено с использованием новых библиотек DLL в качестве ссылки. Простое копирование DLL не будет работать, и это может быть связано с несовпадением версий (т. Е. После компиляции исходной DLL версия изменится). Это честное понимание?
Шахкалпеш
@shahkalpesh хорошая мысль - для меня «снова бегать» подразумевается F5. Я обновил ответ. Конечно, всего этого не случилось бы с приличным инструментом контроля версий, но не заставляйте меня начинать эту тему ...
Бенджол
4
Хм, похоже, что в сообщении об ошибке Microsoft есть ошибка - в нем говорится, что метод класса "DummyItem" не имеет реализации, которая явно ложна .... на самом деле проблема в том, что метод интерфейса не Реализовано DummyItem.
Qwertie
3
какое-нибудь хорошее окончательное решение об этом? Какое решение было рекомендовано Microsoft?
Kiquenet
12
Решение состоит в том, чтобы удалить файлы bin вручную. Публикация не рассматривает их как измененные, поэтому вам нужно заставить их иметь самую последнюю версию. Это действительно должно быть отмечено в ответе с самым высоким рейтингом!
DJ.
33

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

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
Timwi
источник
Это решило это для меня, с добавленным уровнем запутывания, которого метод, который, как он утверждал, отсутствовал, был объявлен в интерфейсе, реализованном родительским классом, и объявлен снова в подклассе. Удаление дубликата из подкласса убрало ошибку.
ilikeprogramming
22

Я получил это, когда мое приложение не имело ссылки на другую сборку, определяющую класс, который использовал метод в сообщении об ошибке. Запуск PEVerify дал более полезную ошибку: «Система не может найти указанный файл».

тихий тон
источник
19

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

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

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

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

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

  • Обе сборки 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. Кажется очевидным сейчас!

Благодаря оригинальному постеру!

Дэмиен Сойер
источник
У меня было что-то похожее, но наоборот с версиями. Один метод, нацеленный на .NET 2, возвратил тип из v2 System.Windows.Forms. Его переопределенная реализация в сборке .NET 4-target вернула тот же тип, но из v4 System.Windows.Forms. Он хорошо скомпилирован, но ReflectionOnlyLoadFrom не понравился.
Стивен Хьюлетт
У меня была похожая проблема, вызванная загрузкой типов, ориентированных на .NET2, в контекст ReflectionOnly приложения .NET4. Я решил эту проблему, перенаправив все запросы на сборку основных сборок .NET2 к их аналогам .NET4 в событии AppDomain.ReflectionOnlyAssemblyResolve.
Chaquotay
Это была моя проблема :) Спасибо!
Антоан Еленков
13

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

  • проект asp.net содержит сборку A и сборку B, B строго назван

  • сборка A использует Activator.CreateInstance для загрузки сборки C (т.е. нет ссылки на C, который создается отдельно)

  • C был создан со ссылкой на более старую версию сборки B, чем в настоящее время

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

Тим
источник
9

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

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

Ричард Дингуолл
источник
6

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

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

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

DJ.
источник
Я обнаружил, что это относится и к не веб-проектам - я отражал одну сборку в другой (используя LoadFile), очистка и перестройка не работали - удаление всех файлов из папки bin обоих проектов работало. Приветствия за предложение!
d219
Мне также пришлось выполнить сброс IIS, поскольку этот конкретный проект использует IIS локально (к сожалению).
Тим Уилсон
6

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

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

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

Тони Пулокас
источник
Это был ответ для меня. Я столкнулся с этой ошибкой после обновления .NET 4.5 до 4.6.
twblamer
6

Я столкнулся с этой ошибкой в ​​контексте, где я использовал 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>
Ртуть
источник
Могу я спросить, как ты это нашел? Вы использовали какую-то нестандартную технику отладки? Я получаю ту же ошибку, но я думаю, что это вызвано другой DLL, поскольку у меня уже есть перенаправление привязки для неизменяемых.
t3chb0t
1
Хм. Это было некоторое время назад. Я думаю , что главный ключ в том , что метод в «необслуживаемый» параметры используются типы из System.Collections.Immutable. В моем случае не было много других параметров-кандидатов или возвращаемых типов в затронутом методе. Я также помню, как использовал ILSpy для проверки метаданных зависимостей в скомпилированных DLL-библиотеках «DefinitionAssembly» и «PracticeAssembly», особенно обращая внимание на версии ссылок.
Hydrargyrum
1
Спасибо! ;-) Я установил расширение ILSpy для Visual Studio и посмотрел ветку References, там было одно для System.Net.Httpпакета, я добавил dependentAssemblyэлемент для него и скопировал информацию из ILSpy, и теперь она работает, ошибка исчезла!
t3chb0t
Я выяснил, какая сборка GAC была плохой, поместив это в код и поставив точку останова сразу после него, чтобы посмотреть на значения и увидеть, как были загружены две версии System.Net.Http: varloadedAssemblies = from a в AppDomain.CurrentDomain. GetAssemblies () orderby a.FullName select (a.FullName, a);
paulie4
5

Я получил это с «ромбической» формой зависимости проекта:

  • Проект A использует Проект B и Проект D
  • Проект B использует Проект D

Я перекомпилировал проект A, но не проект B, что позволило проекту B «внедрить» старую версию Project Dll

Серж Десмедт
источник
16
Да, мне нравится думать об этом как о проблеме Renault
Бенджол
Я думаю, что у меня была похожая версия этой проблемы, но только между двумя проектами. Я скомпилировал новый вручную. После этого все прошло гладко.
Departamento B
5

Я столкнулся с этим, когда переименовал проект (и имя сборки), от которого зависел проект ASP.NET. Типы в веб-проекте реализованы интерфейсами в зависимой сборке. Несмотря на выполнение Clean Solution из меню Build, сборка с предыдущим именем осталась в binпапке, и когда мой веб-проект был выполнен

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

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

G-Wiz
источник
4

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

Kyberias
источник
4

Эта ошибка также может быть вызвана, если сборка загружается с использованием 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;
}
FrankCoder
источник
3

Другое объяснение проблемы такого типа, связанной с управляемым 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 издевается .

Мартин Ливерсэйдж
источник
У меня была эта ошибка, когда я использовал тип данных System::Byte. Я изменил подпись, чтобы принять, unsigned shortи небо снова стало голубым.
Криштер
3

Я просто обновил решение с 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>
shenku
источник
3

В моем случае это помогло сбросить набор инструментов WinForms.

Я получил исключение при открытии Formв дизайнере; однако компиляция и запуск кода были возможны, и код вел себя как ожидалось. Исключение произошло в локальной UserControlреализации интерфейса из одной из моих библиотек, на которые есть ссылки. Ошибка возникла после обновления этой библиотеки.

Это UserControlбыло указано в наборе инструментов WinForms. Возможно, Visual Studio хранила ссылку на устаревшую версию библиотеки или где-то кэшировала устаревшую версию.

Вот как я выздоровел из этой ситуации:

  1. Щелкните правой кнопкой мыши на панели инструментов WinForms и выберите Reset Toolboxв контекстном меню. (Это удаляет пользовательские элементы из панели инструментов).
    В моем случае элементы панели инструментов были восстановлены в состояние по умолчанию; однако стрелка-указатель отсутствовала в панели инструментов.
  2. Закройте Visual Studio.
    В моем случае Visual Studio прервана с исключением из-за нарушения и прервана.
  3. Перезапустите Visual Studio.
    Сейчас все идет гладко.
Оливье Жако-Дескомб
источник
3

FWIW, я получил это, когда был файл конфигурации, который перенаправил на несуществующую версию ссылочной сборки. Логи Fusion для победы!

Тильман
источник
3

Я получил эту ошибку, потому что у меня был класс в сборке «C», который был в версии 4.5 платформы, реализовав интерфейс в сборке «A», который был в версии 4.5.1 платформы, и служил в качестве базового класса для сборки 'B', который также был на версии 4.5.1 платформы. Система вызвала исключение при попытке загрузить сборку «B». Кроме того, я установил несколько пакетов nuget для .net 4.5.1 на все три сборки. По какой-то причине, даже несмотря на то, что ссылки на nuget не отображались в сборке «B», он создавался успешно.

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

Tolu
источник
3

В моем случае я ранее ссылался на 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папке. Любые старые датированные сборки - ваша проблема.

указ
источник
3

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

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

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

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

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

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

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

Kgn-веб
источник
2

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

Wesley
источник
2

Я видел это в Visual Studio Pro 2008, когда два проекта создавали сборки с одинаковыми именами, один из них - класс lib SDF.dll, а другой - ссылался на библиотеку с именем сборки sdf.exe. Когда я изменил название ссылочной сборки, исключение исчезло

N romaai
источник
2

Это просто означает, что проект внедрения в моих случаях устарел. DLL, содержащая интерфейс, была перестроена, но dll реализации устарела.

TrustyCoder
источник
2

Вот мое мнение об этой ошибке.

Добавлен externметод, но моя паста была неисправна. DllImportAttributeПолучил надел закомментированной линии.

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

Обеспечение фактического включения атрибута в исходный код решило проблему.


источник
2

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

Рубен Бартелинк
источник
1

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

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

Almis
источник
1

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

Джеймс
источник
1

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

Крис Петерсон
источник
1

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

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

Mike_G
источник