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

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

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

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

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

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

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

решение

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

Я только что столкнулся с этим в проекте .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. 102 где-то еще, вы получите эти типы ошибок времени выполнения, которые каким-то образом просачиваются в ваш код.

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

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

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

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

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

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

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

Я столкнулся с такой же ситуацией в моем 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 интерпретировал, что файл был более новым и не требовал перекомпиляции проекта.

я столкнулся с этой проблемой, и для меня это был один проект, который использовал список, который был в Примере.Пространство имен датчиков и другой тип реализовали интерфейс 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 часа ночи на следующий день.