System.MissingMethodException: метод не найден?

То, что когда-то работало в моем приложении asp.net webforms, теперь вызывает эту ошибку:

System.MissingMethodException: метод не найден

Метод DoThis находится в одном classе, и он должен работать.

У меня есть общий обработчик:

 public class MyHandler: IHttpHandler { public void Processrequest(HttpContext context) { // throws error now System.MissingMethodException: Method not found? this.DoThis(); } public void DoThis() { // } } 

Это проблема, которая может возникнуть, когда есть старая версия DLL, которая все еще задерживается где-то вокруг. Убедитесь, что последние сборки развернуты, а дублированные старые сборки не скрываются в определенных папках. Лучше всего было бы удалить каждый встроенный элемент и перестроить / переустановить все решение.

Я решил эту проблему, установив на сервере правильную версию .NET Framework. Веб-сайт работал под версией 4.0, а assembly, которую он вызывал, была скомпилирована для версии 4.5. После установки .NET Framework 4.5 и обновления сайта до версии 4.5 все работает нормально.

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

Неверная версия пакета Nuget

У меня был проект модульных тестов, который занимался сбором данных в наших компаниях EF Nuget, и эта версия была отстает от текущей версии.

В настройках Nuget для вышеупомянутого пакета использовалась least version для тех других пакетов, которые были пакетами, зависящими от второго уровня.

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

Решение

Установив / обновив пакет в Nuget, чтобы [получить] последний исправил проблему.

Я просто столкнулся с этим в проекте .NET MVC. Коренной причиной были конфликтующие версии пакетов NuGet. У меня было решение с несколькими проектами. В каждом из проектов были некоторые пакеты NuGet. В одном проекте у меня была версия пакета Semantic Logging Enterprise Library, а в двух других проектах (эта ссылка была первой) у меня были более старые версии одного и того же пакета. Все это компилируется без ошибок, но при попытке использовать пакет он дал загадочную ошибку «Метод не найден».

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

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

Если вы разрабатываете свой собственный сервер NuGet, убедитесь, что все версии сборки одинаковы:

 [assembly: AssemblyVersion("0.2.6")] [assembly: AssemblyFileVersion("0.2.6")] [assembly: AssemblyInformationalVersion("0.2.6")] 

также .. попробуйте «очистить» ваши проекты или решение и снова перестроить!

У меня была эта проблема, и оказалось, что это связано с тем, что я ссылался на предыдущую версию DLL из моего проекта пользовательского интерфейса. Поэтому при компиляции он был счастлив. Но при запуске он использовал предыдущую версию DLL.

Проверьте ссылки на все другие проекты, прежде чем считать, что вам нужно перестроить / очистить / перераспределить ваши решения.

Проверьте свои ссылки!

Убедитесь, что вы последовательно указываете на те же сторонние библиотеки (не просто доверяйте версиям, смотрите путь) в проектах решений.

Например, если вы используете iTextSharp v.1.00.101 в одном проекте, а вы NuGet или ссылаетесь на iTextSharp v1.00.102 где-то еще, вы получите эти типы ошибок времени выполнения, которые каким-то образом стекаются в ваш код.

Я изменил свою ссылку на iTextSharp во всех трех проектах, чтобы указать на одну и ту же DLL, и все сработало.

У меня был похожий сценарий, когда я получал такое же исключение. У меня было два проекта в моем решении для веб-приложений, названное, например, для DAL и DAL.CustSpec. Проект DAL имел метод Method1, но DAL.CustSpec этого не делал. В моем основном проекте была ссылка на проект DAL, а также ссылка на другой проект под названием AnotherProj. Мой главный проект сделал вызов Method1. Проект AnotherProj имел ссылку на проект DAL.CustSpec, а не на проект DAL. В конфигурации Build были сконфигурированы как проекты DAL, так и DAL.CustSpec. После того, как все было построено, в моем проекте веб-приложения были сборки AnotherProj и DAL в папке Bin. Однако, когда я запускал веб-сайт, временная папка ASP.NET для веб-сайта по какой-то причине имела сборку DAL.CustSpec в своих файлах, а не в сборке DAL. Конечно, когда я запускал часть, которая называлась Method1, я получил ошибку «Метод не найден».

Что мне нужно было сделать, чтобы исправить эту ошибку, так это изменить ссылку в проекте AnotherProj из DAL.CustSpec только на DAL, удалил все файлы в папке Временные файлы ASP.NET и затем повторно запустил веб-сайт. После этого все приступило к работе. Я также убедился, что проект DAL.CustSpec не был создан, сняв флажок в конфигурации сборки.

Я думал, что поделюсь этим, если это поможет кому-то еще в будущем.

Вы пробовали поворачиваться, если снова и снова? Шутки в сторону, перезагрузка моего компьютера была тем, что на самом деле сделал трюк для меня и не упоминается ни в одном из других ответов.

Я столкнулся с такой же ситуацией на своем веб-сайте ASP.NET. Я удалил опубликованные файлы, перезапустил VS, снова очистил и перестроил проект. После следующего опубликования ошибка исчезла …

Я решил эту проблему, сделав полки с моими изменениями и запустив TFS Power Tools ‘в моем рабочем пространстве ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Затем я внесла изменения и перекомпилировал проект. Таким образом, вы будете очищать любые «висячие партии», которые могут быть в вашем рабочем пространстве, и будут запускаться с новой. Это требует, конечно, использования TFS.

В моем случае это была проблема с копией / вставкой. Я как-то закончил конструктор PRIVATE для моего профиля отображения:

 using AutoMapper; namespace Your.Namespace { public class MappingProfile : Profile { MappingProfile() { CreateMap(); } } } 

(обратите внимание на недостающую «общественность» перед зданием)

который компилируется отлично, но когда AutoMapper пытается создать экземпляр профиля, он не может (конечно!) найти конструктор!

Использование Costura.Fody 1.6 и 2.0:
Потеряв кучу времени, просматривая такую ​​же ошибку, когда все другие потенциальные решения не работают, я обнаружил, что более старая версия DLL, которую я встраивал, была в том же каталоге, в котором я запускал свой недавно скомпилированный файл .exe. По-видимому, сначала он ищет локальный файл в том же каталоге, а затем обращается внутрь встроенной библиотеки. Удалено удаление старой DLL.

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

Это случилось со мной с помощью MVC4, и я решил после прочтения этого streamа переименовать объект, который выдавал ошибку.

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

Поэтому VS ссылался на модель, которую я переписал, не спрашивая меня, хочу ли я это сделать.

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

У меня была эта ошибка при использовании Дженкинса.

В конце концов выяснилось, что системная дата была вручную установлена ​​на будущую дату, из-за которой dll собиралось с этой будущей датой. Когда дата была возвращена в норму, MSBuild интерпретировал, что файл был более новым и не требовал перекомпиляции проекта.

Я столкнулся с этой проблемой, и то, что для меня было одним проектом, было использование списка, который был в примере. Пространство имен сенсоров, а другой тип – интерфейс ISensorInfo. Класс Type1SensorInfo, но этот class был одним слоем глубже в пространстве имен в примере. Sensors.Type1. При попытке десериализовать Type1SensorInfo в список, это исключило исключение. Когда я добавил использование примера.Sensors.Type1 в интерфейс ISensorInfo, больше никаких исключений!

 namespace Example { public class ConfigFile { public ConfigFile() { Sensors = new List>(); } public List> Sensors { get; set; } } } } **using Example.Sensors.Type1; // Added this to not throw the exception** using System; namespace Example.Sensors { public interface ISensorInfo { String SensorName { get; } } } using Example.Sensors; namespace Example.Sensors.Type1 { public class Type1SensorInfo : ISensorInfo { public Type1SensorInfo() } } 

У меня было то же самое, когда у меня было несколько процессов MSBuild, работающих в фоновом режиме, которые эффективно разбились (у них были ссылки на старые версии кода). Я закрыл VS и убил все процессы MSBuild в проводнике процессов, а затем перекомпилировал.

У меня был тестовый проект, который ссылается на 2 других проекта, каждый из которых ссылается на разные версии (в разных местах) одной и той же DLL. Это смутило компилятор.

В моем случае spotify.exe использовал тот же порт, который мой веб-проект api хотел использовать на машине разработки. Номер порта был 4381.

Я ухожу из Spotify, и все снова хорошо работает 🙂

Также может возникнуть проблема с параметром или возвращаемым типом метода, о котором сообщается, и «отсутствующий» метод сам по себе является прекрасным.

Это то, что происходило в моем случае, и вводящее в заблуждение сообщение заставило заняться гораздо дольше, чтобы выяснить проблему. Оказывается, assembly для типа параметра имела более старую версию в GAC, но более старая версия имела более высокий номер версии из-за изменения используемых схем нумерации версий. Исправлена ​​ошибка, связанная с тем, что старая / более высокая версия GAC исправила проблему.

У меня была эта проблема, когда для метода был задан параметр, который я не указывал

В моем случае вообще не было никакого изменения кода, и вдруг один из серверов начал получать это и только это исключение (все серверы имеют один и тот же код, но только у одного из них возникли проблемы):

 System.MissingMethodException: Method not found: '?'. 

стек:

 Server stack trace: at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request) at myAccountSearch.AccountSearchClient.myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request) at myAccountSearch.AccountSearchClient.searchtPhone(String ID, String HashID, searchtPhone Phone1) at WS.MyValidation(String AccountNumber, String PhoneNumber) 

Проблема, которая, как мне кажется, была испорчена AppPool – у нас автоматизированная утилизация AdPool происходит каждый день в 3 часа ночи, и проблема началась в 3 часа ночи, а затем закончилась сама по себе в 3 часа дня на следующий день.

Давайте будем гением компьютера.