То, что когда-то работало в моем приложении 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()
{
//
}
}
Это проблема, которая может возникнуть, когда есть старая версия DLL, которая все еще задерживается где-то вокруг. Убедитесь, что последние сборки развернуты, а дублированные старые сборки не скрываются в определенных папках. Лучше всего было бы удалить каждый встроенный элемент и перестроить/переустановить все решение.
Я решил эту проблему, установив на сервере правильную версию .NET Framework. Веб-сайт работал под версией 4.0, а сборка, которую он вызывал, была скомпилирована для версии 4.5. После установки .NET Framework 4.5 и обновления сайта до версии 4.5 все работает нормально.
Перезапуск Visual Studio фактически исправил это для меня. Я думаю, что это было вызвано старыми файлами сборки, которые все еще используются, и выполнение "Чистой сборки" или перезапуск VS должно исправить это.
⚠️ Неверная версия пакета Nuget ⚠️
У меня был проект модульного тестирования, который включал в наши компании внутренний пакет доступа к данным EF Nuget, и этот пакет использовал версию пакета, которая значительно отставала от текущей версии.
Настройки Nuget для вышеупомянутого пакета были установлены в least version.
Следовательно, он молча получил неправильную версию для соответствующей сборки.
💡 решение 💡
Установив/обновив пакет в Nuget для использования и [получения] самой последней, исправили проблему.
У меня это случилось со мной с файлом, указанным в той же сборке, а не с отдельной dll. Как только я исключил файл из проекта, а затем включил его снова, все работало нормально.
Я просто столкнулся с этим в проекте .NET MVC. Коренной причиной были конфликтующие версии пакетов NuGet. У меня было решение с несколькими проектами. В каждом из проектов были некоторые пакеты NuGet. В одном проекте у меня была версия пакета Semantic Logging Enterprise Library, а в двух других проектах (эта ссылка была первой) у меня были более старые версии одного и того же пакета. Все они компилируются без ошибок, но при попытке использовать пакет он дал загадочную ошибку "Метод не найден".
Исправлено удаление старых пакетов NuGet из двух проектов, так что он был включен только в один проект, который действительно нуждался в нем. (Также я сделал чистую перестройку всего решения.)
Проверьте свои ссылки!
Убедитесь, что вы последовательно указываете на те же сторонние библиотеки (не просто доверяйте версиям, смотрите путь) в проектах решений.
Например, если вы используете iTextSharp v.1.00.101 в одном проекте, а вы NuGet или ссылаетесь на iTextSharp v1.00.102, то в другом месте вы получите эти типы ошибок времени выполнения, которые каким-то образом стекаются в ваш код.
Я изменил свою ссылку на iTextSharp во всех трех проектах, чтобы указать на одну и ту же DLL, и все сработало.
Если вы разрабатываете свой собственный сервер NuGet, убедитесь, что все версии сборки одинаковы:
[assembly: AssemblyVersion("0.2.6")]
[assembly: AssemblyFileVersion("0.2.6")]
[assembly: AssemblyInformationalVersion("0.2.6")]
также попробуйте "очистить" ваши проекты или решение и снова восстановить!
У меня была эта проблема, и оказалось, что это связано с тем, что я ссылался на предыдущую версию DLL из моего проекта пользовательского интерфейса. Поэтому при компиляции он был счастлив. Но при запуске он использовал предыдущую версию 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 'scorch' в моей рабочей области (https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f). Затем я внесла изменения и перекомпилировал проект. Таким образом, вы будете очищать любые "висячие партии", которые могут быть в вашем рабочем пространстве, и будут запускаться с новой. Это требует, конечно, использования TFS.
Также возможно, что проблема связана с параметром или возвращаемым типом метода, который сообщил об отсутствии, и "отсутствующий" метод сам по себе является прекрасным.
То, что происходило в моем случае, и вводящее в заблуждение сообщение заставило его заняться гораздо дольше, чтобы выяснить проблему. Оказывается, сборка для типа параметра имела более старую версию в GAC, но более старая версия имела более высокий номер версии из-за изменения используемых схем нумерации версий. Удаление этой старой/более высокой версии из GAC устранило проблему.
В моем случае это была проблема с копией/вставкой. Я как-то закончил конструктор PRIVATE для моего профиля отображения:
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 была в каталоге, из которого я тестировал свое приложение в отдельной системе от той, на которой оно было скомпилировано.
В моем случае это была папка с более ранними DLL-библиотеками с тем же именем, на которые ссылались в моем файле .csproj, хотя путь был явно задан, поскольку они были каким-то образом включены, поэтому несколько версий одних и тех же DLL находились в конфликте.
В случае, если проблема вызвана старой версией сборки в GAC.
Это может помочь: Как: удалить сборку из глобального кэша сборок.
Это случилось со мной с помощью MVC4, и я решил после прочтения этого потока переименовать объект, который выдавал ошибку.
Я сделал чистую и восстановил и отметил, что он пропускает два проекта. Когда я перестроил один из них, произошла ошибка, когда я запустил функцию и не закончил ее.
Итак, VS ссылался на модель, которую я переписал, не спрашивая меня, хочу ли я это сделать.
На всякий случай это помогает любому, хотя это старая проблема, моя проблема была немного странной.
У меня была эта ошибка при использовании Jenkins.
В конце концов выяснилось, что системная дата была вручную установлена на будущую дату, что вызвало слияние dll с этой будущей датой. Когда дата была возвращена в нормальное состояние, MSBuild интерпретировал, что файл был более новым и не требовал перекомпиляции проекта.
Я столкнулся с этой проблемой, и то, что для меня было одним проектом, было использование списка, который был в примере. Пространство имен сенсоров, а другой тип - интерфейс ISensorInfo. Класс Type1SensorInfo, но этот класс был одним слоем глубже в пространстве имен в примере. Sensors.Type1. При попытке десериализовать Type1SensorInfo в список, это исключило исключение. Когда я добавил использование примера .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 использовал тот же порт, который мой веб-проект 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, ошибка исчезла. Какая загадочная ошибка с таким разнообразием причин.
Это случилось со мной при преобразовании из обнуляемого типа в строку. Я забыл использовать ".GetValueOrDefault()" перед добавлением метода .ToString() к свойству при заполнении моей модели представления.
Он скомпилировался просто отлично, но когда я попытался загрузить представление, произойдет ошибка с этим исключением.