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. Переконайтеся, що останні версії розгорнуті, а в певних папках не ховаються дублюючі старі збірки. Найкраще ставитись до того, щоб видалити кожен вбудований елемент та відновити / перезавантажити все рішення.

Version Неправильна версія нульового пакета ⚠️

У мене був блок тестового проекту , який тягнув в нашій компанії внутрішнього пакета доступу до даними 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.

Перевірте посилання на всі інші проекти, перш ніж припускати, що вам потрібно перебудувати / очистити / перерозподілити свої рішення.

У моєму випадку це була проблема копіювання / вставки. Я якось опинився з ПРИВАТНИМ конструктором для свого профілю відображення:

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. Конфігурація 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 '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 як параметр або тип повернення (параметр під час налагодження, тип повернення під час запуску тести без налагоджувача, теж трохи дивно). І замість того, щоб показувати повідомлення про те, що він не може завантажити версію 4.2.0.0 System.Net.Http, він повертає цей виняток.

Це сталося зі мною, використовуючи MVC4, і я вирішив, прочитавши цю тему, перейменувати об’єкт, який видав помилку.

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

Тож В.С. посилався на модель, яку я переписав, не питаючи, чи хочу я це робити.

На всякий випадок, коли це допомагає комусь, хоча це старе питання, моя проблема була трохи дивною.

У мене була помилка під час використання Дженкінса.

Врешті-решт з'ясувалося, що системну дату вручну встановлювали на майбутню дату, що спричинило компіляцію dll з цією майбутньою датою. Коли дата була повернена до нормальної норми, MSBuild інтерпретував, що файл новітній і не потребує перекомпіляції проекту.

Я зіткнувся з цим питанням, і це було для мене одним проектом, який використовував Список, який був у просторі імен 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 використовував той самий порт, який мій веб-проект 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, помилка пішла. Яка загадкова помилка при такій різноманітності причин.