У меня очень странная ошибка на нашей тестовой машине. Ошибка:
System.TypeLoadException: Method 'SetShort' in type 'DummyItem' from assembly 'ActiveViewers (...)' does not have an implementation.
Я просто не могу понять почему. SetShort
есть в DummyItem
классе, и я даже перекомпилировал версию с записью в журнал событий, просто чтобы убедиться, что это не проблема развертывания / управления версиями. Странно то, что вызывающий код даже не вызывает SetShort
метод.
c#
.net
fusion
typeloadexception
Benjol
источник
источник
Ответы:
ПРИМЕЧАНИЕ. - Если этот ответ вам не поможет, найдите время, чтобы прокрутить список других ответов, добавленных с тех пор.
Короткий ответ
Это может произойти, если вы добавляете метод к интерфейсу в одной сборке, а затем к классу реализации в другой сборке, но вы перестраиваете сборку реализации без ссылки на новую версию сборки интерфейса.
В этом случае DummyItem реализует интерфейс из другой сборки. Метод SetShort был недавно добавлен как к интерфейсу, так и к DummyItem - но сборка, содержащая DummyItem, была перестроена со ссылкой на предыдущую версию сборки интерфейса. Таким образом, метод SetShort эффективен, но без волшебного соуса, связывающего его с эквивалентным методом в интерфейсе.
Длинный ответ
Если вы хотите попробовать воспроизвести это, попробуйте следующее:
Создайте проект библиотеки классов: InterfaceDef, добавьте только один класс и соберите:
Создайте проект библиотеки второго класса: Реализация (с отдельным решением), скопируйте InterfaceDef.dll в каталог проекта и добавьте в качестве ссылки на файл, добавьте только один класс и соберите:
Создайте третий консольный проект: ClientCode, скопируйте две библиотеки в каталог проекта, добавьте ссылки на файлы и добавьте следующий код в метод Main:
Запустите код один раз, консоль скажет «привет мир»
Раскомментируйте код в двух проектах dll и перестройте - скопируйте два dll обратно в проект ClientCode, перестройте и попробуйте запустить снова. Исключение TypeLoadException возникает при попытке создания экземпляра ImplementingClass.
источник
В дополнение к тому, что уже сказано в ответе автора, возможно, стоит отметить следующее. Причина, по которой это происходит, заключается в том, что класс может иметь метод с такой же сигнатурой, что и метод интерфейса, без реализации этого метода. Следующий код иллюстрирует это:
источник
Я получил это, когда мое приложение не имело ссылки на другую сборку, определяющую класс, который использовал метод в сообщении об ошибке. Запуск PEVerify дал более полезную ошибку: «Система не может найти указанный файл».
источник
Я наткнулся на то же сообщение, и вот что мы нашли: мы используем сторонние библиотеки в нашем проекте. После выхода новой версии мы изменили наш проект, чтобы он указывал на новый набор DLL, и успешно скомпилировали.
Исключение было вызвано, когда я попытался установить один из их сопряженных классов во время выполнения. Мы убедились, что все остальные ссылки были актуальны, но все же не повезло. Нам потребовалось некоторое время, чтобы определить (с помощью обозревателя объектов), что возвращаемый тип метода в сообщении об ошибке был совершенно новым типом из новой сборки без ссылки.
Добавили ссылку на сборку и ошибка исчезла.
источник
Я получил эту ошибку в следующем сценарии.
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 проекта модульного тестирования.
После этого обе ошибки исчезли и проект был построен.
источник
Я столкнулся с этой ошибкой в контексте, где я использовал 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.Immutable
1.1.37, и содержит реализацииIMyInterface<T1,T2>
интерфейса, который был определен в отдельномDefinitionAssembly
.DefinitionAssembly
ссылкаSystem.Collections.Immutable
1.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.Immutable
1.1.37. Ошибка загрузки произошла только тогда, когда GAC содержал более старую версию DLL.Таким образом, основной причиной сбоя загрузки сборки были несоответствующие ссылки
System.Collections.Immutable
. Определение и реализация интерфейса имели идентичные сигнатуры методов, но фактически зависели от разных версийSystem.Collections.Immutable
, что означало, что среда выполнения не считала класс реализации соответствующим определению интерфейса.Добавление следующей привязки к моему файлу конфигурации исправило проблему:
источник
System.Collections.Immutable
. В моем случае не было много других параметров-кандидатов или возвращаемых типов в затронутом методе. Я также помню, как использовал ILSpy для проверки метаданных зависимостей в скомпилированных DLL-библиотеках «DefinitionAssembly» и «PracticeAssembly», особенно обращая внимание на версии ссылок.System.Net.Http
пакета, я добавилdependentAssembly
элемент для него и скопировал информацию из ILSpy, и теперь она работает, ошибка исчезла!Я получил это с «ромбической» формой зависимости проекта:
Я перекомпилировал проект A, но не проект B, что позволило проекту B «внедрить» старую версию Project Dll
источник
Я столкнулся с этим, когда переименовал проект (и имя сборки), от которого зависел проект ASP.NET. Типы в веб-проекте реализованы интерфейсами в зависимой сборке. Несмотря на выполнение Clean Solution из меню Build, сборка с предыдущим именем осталась в
bin
папке, и когда мой веб-проект был выполненВышеуказанное исключение было выдвинуто с жалобой на то, что методы интерфейса в реализующих веб-типах фактически не были реализованы. Удаление сборки в
bin
папке веб-проекта вручную решило проблему.источник
Я также получил эту ошибку, когда ранее включил покрытие кода во время модульного тестирования для одной из сборок. По какой-то причине Visual Studio «буферизовала» старую версию этой конкретной библиотеки DLL, хотя я обновил ее, чтобы реализовать новую версию интерфейса. Отключение покрытия кода избавило от ошибки.
источник
Эта ошибка также может быть вызвана, если сборка загружается с использованием Assembly.LoadFrom (String) и ссылается на сборку, которая уже была загружена с использованием Assembly.Load (Byte []).
Например, вы встраивали ссылочные сборки основного приложения в качестве ресурсов, но ваше приложение загружает подключаемые модули из определенной папки.
Вместо использования LoadFrom вы должны использовать Load. Следующий код сделает работу:
источник
Другое объяснение проблемы такого типа, связанной с управляемым C ++.
Если вы попытаетесь заглушить интерфейс, определенный в сборке, созданной с использованием управляемого C ++, которая имеет специальную подпись, вы получите исключение при создании заглушки.
Это верно для Rhino Mocks и, вероятно, для любой фальшивой среды, которая использует
System.Reflection.Emit
.Определение интерфейса получает следующую подпись:
Обратите внимание, что тип C ++
long
отображаетсяSystem.Int32
(или простоint
в C #). Это несколько затемнить ,modopt
что вызывает проблему , как заявил Ayende Rahien в списке рассылки Rhino издевается .источник
System::Byte
. Я изменил подпись, чтобы принять,unsigned short
и небо снова стало голубым.Я просто обновил решение с MVC3 до MVC5 и начал получать то же исключение из моего проекта модульного тестирования.
Проверил все ссылки, ища старые файлы, в конечном итоге обнаружил, что мне нужно было выполнить несколько bindingRedirects для Mvc в моем проекте модульного тестирования.
источник
В моем случае это помогло сбросить набор инструментов WinForms.
Я получил исключение при открытии
Form
в дизайнере; однако компиляция и запуск кода были возможны, и код вел себя как ожидалось. Исключение произошло в локальнойUserControl
реализации интерфейса из одной из моих библиотек, на которые есть ссылки. Ошибка возникла после обновления этой библиотеки.Это
UserControl
было указано в наборе инструментов WinForms. Возможно, Visual Studio хранила ссылку на устаревшую версию библиотеки или где-то кэшировала устаревшую версию.Вот как я выздоровел из этой ситуации:
Reset Toolbox
в контекстном меню. (Это удаляет пользовательские элементы из панели инструментов).В моем случае элементы панели инструментов были восстановлены в состояние по умолчанию; однако стрелка-указатель отсутствовала в панели инструментов.
В моем случае 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
.Позже я сделал это правильно и использовал его через подмодуль 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, эти два шага решили проблему.
и ошибка ушла .
Перезапустите плагин VS
Спасибо Пол :)
Надеюсь, это поможет кому-то, кто сталкивался с этой ошибкой :)
источник
Я также столкнулся с этой проблемой при проведении моих юнит-тестов. Приложение работает нормально и без ошибок. Причиной проблемы в моем случае было то, что я выключил сборку тестовых проектов. Повторное включение сборки моих тестовых проектов решило проблемы.
источник
Я видел это в Visual Studio Pro 2008, когда два проекта создавали сборки с одинаковыми именами, один из них - класс lib SDF.dll, а другой - ссылался на библиотеку с именем сборки sdf.exe. Когда я изменил название ссылочной сборки, исключение исчезло
источник
Это просто означает, что проект внедрения в моих случаях устарел. DLL, содержащая интерфейс, была перестроена, но dll реализации устарела.
источник
Вот мое мнение об этой ошибке.
Добавлен
extern
метод, но моя паста была неисправна.DllImportAttribute
Получил надел закомментированной линии.Обеспечение фактического включения атрибута в исходный код решило проблему.
источник
Я получил это в службе 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 установило новое, но даже явно ссылается на него, обновляет перенаправления привязки и т. Д. Конечным результатом было просто изменение сигнатуры метода на нечто «стандартное», я думаю, вы могли бы сказать.
источник