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

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

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

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

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

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

    public void DoThis()
    {
    //
    }
}

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

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

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

Проблема заключалась в том, что настройки Nuget для пакета были установлены на least version; и старая версия победила и использовалась во время операций ....

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

💡 решение 💡

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

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

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

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

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

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

Проверьте ваши рекомендации!

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

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

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

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

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

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

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

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

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

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

using AutoMapper;

namespace Your.Namespace
{
    public class MappingProfile : Profile
    {
        MappingProfile()
        {
            CreateMap<Animal, AnimalDto>();
        }
    }
}

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

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

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

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

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

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

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

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

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

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

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

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

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

В моем случае MissingMethodException был для метода, который был в том же файле!

Однако я только что добавил пакет NuGet, который использует .Net Standard2, в мой проект нацеливания на 4.7.1, что вызвало конфликт версий для System.Net.Http (4.7.1: версия 4.0.0.0, пакет NuGet с использованием .NET Стандарт 2 хочет 4.2.0.0). Кажется, это известные проблемы, которые должны быть лучше в 4.7.2 (см. Примечание 2) .

Я использовал такой редирект привязки во всех других моих проектах, потому что были исключения, как только он пытался загрузить 4.2.0.0, которого у меня не было:

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>

За исключением этого одного проекта, где кажется, что он пытается загрузить System.Net.Http только при вызове локальной функции, которая использует System.Net.Http.HttpResponseMessage в качестве параметра или типа возврата (параметр во время отладки, тип возврата при запуске тесты без отладчика тоже немного странные). И вместо того, чтобы показать сообщение о том, что он не может загрузить версию System.Net.Http 4.2.0.0, он возвращает это исключение.

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

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

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

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

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

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

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

namespace Example
{
    public class ConfigFile
    {
        public ConfigFile()
        {
            Sensors = new List<ISensorInfo<Int32>>();
        }
        public List<ISensorInfo<Int32>> Sensors { get; set; }
     }
   }
}

**using Example.Sensors.Type1; // Added this to not throw the exception**
using System;

namespace Example.Sensors
{
    public interface ISensorInfo<T>
    {
        String SensorName { get; }
    }
}

using Example.Sensors;

namespace Example.Sensors.Type1
{
    public class Type1SensorInfo<T> : ISensorInfo<T>
    {
        public Type1SensorInfo() 
    }
}

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

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

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

Я вышел из Spotify и все снова заработало :)

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

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

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 - мы автоматизировали утилизацию AppPool каждый день в 3 часа ночи, и проблема началась в 3 часа ночи, а затем закончилась сама по себе в 3 часа ночи на следующий день.

Должно быть справочной ошибкой от Microsoft.

Я почистил, пересобрал все мои библиотеки и все еще получил ту же проблему и не смог решить эту проблему.

Я только закрыл приложение Visual Studio и снова открыл его. Это добилось цели.

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

В моем случае мой проект ссылался Microsoft.Net.Compilers.2.10.0. Когда я переключил его на Microsoft.Net.Compilers.2.7.0, ошибка исчезла. Какая загадочная ошибка с таким разнообразием причин.