Система.MissingMethodException: метод не найден?

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

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

Неправильная Версия Пакета Nuget

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

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

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

решение

установив / обновив пакет в Nuget до [get] последние Исправлена проблема.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

using AutoMapper;

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

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

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

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

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

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

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

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

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

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

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

я столкнулся с этой проблемой, и для меня это был один проект, который использовал список, который был в Примере.Пространство имен Sensors и другой тип реализовали интерфейс ISensorInfo. Класс Type1SensorInfo, но этот класс был на один слой глубже в пространстве имен в Примере.Аппаратура наблюдения.Тип1. При попытке десериализовать Type1SensorInfo в список он выдал исключение. Когда я добавил, используя пример.Аппаратура наблюдения.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 в Process explorer, а затем перекомпилировал.

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

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

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

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

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