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

Question

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

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()
    {
    //
    }
}

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

using AutoMapper;

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

(обратите внимание на отсутствующее "public" перед ctor)

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

Answer 10

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