System.MissingMethodException: Nie znaleziono metody?

Co kiedyś działało w mojej aplikacji webforms asp.net, teraz generuje ten błąd:

System.MissingMethodException: Nie znaleziono metody

DoThisMetoda jest w tej samej klasie i powinno działać.

Mam ogólny program obsługi jako taki:

public class MyHandler: IHttpHandler
{
    public void Processrequest(HttpContext context)
    {
      // throws error now System.MissingMethodException: Method not found?
      this.DoThis(); 
    }

    public void DoThis()
    {
    //
    }
}

Jest to problem, który może wystąpić, gdy wciąż istnieje gdzieś stara wersja biblioteki DLL. Upewnij się, że najnowsze zespoły zostały wdrożone, a żadne zduplikowane starsze zestawy nie ukrywają się w niektórych folderach. Najlepszym rozwiązaniem byłoby usunięcie każdego zbudowanego przedmiotu i przebudowanie / ponowne wdrożenie całego rozwiązania.

⚠️ Niepoprawna wersja pakietu Nuget ⚠️

Miałem projekt testowy jednostka, która ciągnęła się w naszych firmach wewnętrzny pakiet dostępu i dane EF Nuget że kod pociągnął w opakowania zewnętrznego, którego wersja była droga za bieżącej wersji.

Problem polegał na tym, że ustawienia pakietu Nuget dla pakietu były ustawione na least version; a starsza wersja wygrała i była używana podczas operacji ....

Dlatego po cichu otrzymała niewłaściwą wersję dla wspólnego zestawu używanego zarówno przez pakiet, jak i aplikację.

💡 Rozwiązanie 💡

Naprawiono problem, ustawiając / aktualizując pakiet w Nuget do używania i [pobierania] najnowszego .

Rozwiązałem ten problem, instalując poprawną wersję .NET Framework na serwerze. Witryna działała w wersji 4.0, a zestaw, do którego dzwoniła, został skompilowany dla wersji 4.5. Po instalacji .NET Framework 4.5 i aktualizacji strony do 4.5 wszystko działa dobrze.

Ponowne uruchomienie programu Visual Studio naprawiło to dla mnie. Myślę, że było to spowodowane wciąż używanymi starymi plikami asemblacji i wykonanie „Czystej kompilacji” lub ponowne uruchomienie VS powinno to naprawić.

Zdarzyło mi się to z plikiem, do którego odwołuje się ten sam zestaw, a nie oddzielnym dll. Po wykluczeniu pliku z projektu i ponownym dołączeniu go wszystko działało dobrze.

Właśnie natrafiłem na to w projekcie .NET MVC. Główną przyczyną były sprzeczne wersje pakietów NuGet. Miałem rozwiązanie z kilkoma projektami. Każdy z projektów miał kilka pakietów NuGet. W jednym projekcie miałem wersję pakietu Enterprise Library Semantic Logging, aw dwóch innych projektach (które odnoszą się do pierwszego) miałem starsze wersje tego samego pakietu. Wszystko kompiluje się bezbłędnie, ale przy próbie użycia pakietu wystąpił tajemniczy błąd „Nie znaleziono metody”.

Poprawka polegała na usunięciu starych pakietów NuGet z dwóch projektów, tak aby zostały uwzględnione tylko w jednym projekcie, który faktycznie tego potrzebował. (Przeprowadziłem również czystą przebudowę całego rozwiązania.)

Sprawdź swoje referencje!

Pamiętaj, aby stale wskazywać te same biblioteki innych firm (nie tylko ufaj wersjom, spójrz na ścieżkę) w swoich projektach rozwiązań.

Na przykład, jeśli korzystasz z iTextSharp v.1.00.101 w jednym projekcie i NuGet lub odwołujesz się do iTextSharp v1.00.102 w innym miejscu, dostaniesz tego rodzaju błędy w czasie wykonywania, które w jakiś sposób przedostaną się do twojego kodu.

Zmieniłem odniesienie do iTextSharp we wszystkich 3 projektach, aby wskazać tę samą bibliotekę DLL i wszystko działało.

Jeśli programujesz z własnym serwerem NuGet, upewnij się, że wersje zestawu są takie same:

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

także… spróbuj „wyczyścić” swoje projekty lub rozwiązanie i odbuduj ponownie!

Czy próbowałeś włączyć lub wyłączyć ponownie? Żarty na bok, zrestartowanie komputera było tym, co faktycznie zrobiło dla mnie lewę i nie jest wymienione w żadnej z pozostałych odpowiedzi.

Właśnie miałem ten problem i okazało się, że było tak, ponieważ odwoływałem się do poprzedniej wersji biblioteki DLL z mojego projektu interfejsu użytkownika. Dlatego podczas kompilacji był szczęśliwy. Ale podczas uruchamiania korzystał z poprzedniej wersji biblioteki DLL.

Sprawdź referencje dotyczące wszystkich innych projektów przed założeniem, że musisz odbudować / wyczyścić / ponownie wdrożyć swoje rozwiązania.

W moim przypadku był to problem z kopiowaniem / wklejaniem. Jakoś skończyłem z PRYWATNYM konstruktorem dla mojego profilu mapowania:

using AutoMapper;

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

(zwróć uwagę na brakujące „publiczne” przed ctor)

który skompilował się doskonale, ale kiedy AutoMapper próbuje utworzyć profil, nie może (oczywiście!) znaleźć konstruktora!

Miałem podobny scenariusz, w którym zgłaszano mi ten sam wyjątek. Miałem dwa projekty w moim rozwiązaniu aplikacji internetowych, nazwane na przykład DAL i DAL.CustSpec. Projekt DAL miał metodę o nazwie Method1, ale DAL.CustSpec nie. Mój główny projekt miał odniesienie do projektu DAL, a także odniesienie do innego projektu o nazwie AnotherProj. Mój główny projekt zadzwonił do Method1. Projekt AnotherProj miał odniesienie do projektu DAL.CustSpec, a nie do projektu DAL. W konfiguracji kompilacji skonfigurowano zarówno projekty DAL, jak i DAL.CustSpec. Po tym, jak wszystko zostało zbudowane, mój projekt aplikacji internetowej miał zestawy AnotherProj i DAL w folderze Bin. Jednak gdy uruchomiłem witrynę, folder Temporary ASP.NET witryny miał w swoich plikach zestaw DAL.CustSpec, a nie zestaw DAL, z jakiegoś powodu. Oczywiście, kiedy uruchomiłem część o nazwie Metoda 1, otrzymałem błąd „Nie znaleziono metody”.

Aby naprawić ten błąd, musiałem zmienić odniesienie w projekcie AnotherProj z DAL.CustSpec na tylko DAL, usunąć wszystkie pliki w folderze tymczasowych plików ASP.NET, a następnie przenieść stronę ponownie. Potem wszystko zaczęło działać. Upewniłem się również, że projekt DAL.CustSpec nie jest budowany, odznaczając go w konfiguracji kompilacji.

Pomyślałem, że podzielę się tym na wypadek, gdyby pomógł komuś innemu w przyszłości.

Tę samą sytuację spotkałem na mojej stronie ASP.NET. Usunąłem opublikowane pliki, ponownie uruchomiłem VS, wyczyściłem i ponownie przebudowałem projekt. Po kolejnej publikacji błąd zniknął ...

Rozwiązałem ten problem, tworząc zestaw półek z moimi zmianami i uruchamiając narzędzie Scorch TFS Power Tools w moim obszarze roboczym ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Potem odsunąłem zmiany i ponownie skompilowałem projekt. W ten sposób wyczyścisz wszystkie „wiszące imprezy”, które mogą znajdować się w twoim obszarze roboczym i zaczniesz od nowa. Wymaga to oczywiście korzystania z TFS.

Możliwe jest również, że problem dotyczy parametru lub typu zwracanej metody, o której zgłoszono brak, a sama metoda „brakująca” jest w porządku.

Tak właśnie działo się w moim przypadku, a wprowadzający w błąd komunikat sprawił, że znacznie dłużej było zajęcie się problemem. Okazuje się, że zestaw dla typu parametru miał starszą wersję w GAC, ale starsza wersja faktycznie miała wyższy numer wersji z powodu zmiany zastosowanych schematów numeracji wersji. Usunięcie tej starszej / wyższej wersji z GAC naprawiło problem.

Korzystanie z Costura.Fody 1.6 i 2.0:
Po marnowaniu czasu na szukanie tego samego rodzaju błędu przy wszystkich innych potencjalnych niedziałających rozwiązaniach, stwierdziłem, że starsza wersja osadzanej przeze mnie biblioteki DLL znajdowała się w tym samym katalogu, w którym działałem nowo skompilowane .exe z. Najwyraźniej najpierw szuka lokalnego pliku w tym samym katalogu, a potem zagląda do wbudowanej biblioteki. Usunięcie starej biblioteki DLL działało.

Żeby było jasne, nie chodziło o to, że moje odniesienie wskazywało na starą bibliotekę DLL, ale o to, że kopia starej biblioteki DLL znajdowała się w katalogu, z którego testowałem moją aplikację w innym systemie niż ten, na którym została skompilowana.

W moim przypadku był to folder ze starszymi bibliotekami DLL o tej samej nazwie, do których były odniesienia w moim pliku .csproj, chociaż ścieżka została wyraźnie podana, że ​​zostały one w jakiś sposób uwzględnione, dlatego kilka wersji tych samych bibliotek DLL było w konflikcie.

W przypadku, gdy problem jest spowodowany przez starą wersję zestawu w GAC .
Może to pomóc: Jak: Usunąć zestaw z globalnej pamięci podręcznej zestawu .

W moim przypadku MissingMethodException dotyczył metody, która była w tym samym pliku!

Jednak właśnie dodałem pakiet NuGet, który używa .Net Standard2 do mojego projektu ukierunkowanego na 4.7.1, co spowodowało konflikt wersji dla System.Net.Http (4.7.1: wersja 4.0.0.0, pakiet NuGet przy użyciu .NET Standard 2 chce wersji 4.2.0.0). Wydaje się, że są to znane problemy, które powinny być lepsze w 4.7.2 (patrz uwaga 2) .

Użyłem takiego przekierowania powiązania we wszystkich innych moich projektach, ponieważ były wyjątki, gdy tylko próbowano załadować 4.2.0.0, których nie miałem:

  <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>

Z wyjątkiem tego jednego projektu, w którym wydaje się, że próbuje załadować System.Net.Http tylko podczas wywoływania funkcji lokalnej korzystającej z System.Net.Http.HttpResponseMessage jako parametru lub typu zwracanego (parametr podczas debugowania, zwracany podczas uruchamiania testy bez debuggera, również trochę dziwne). Zamiast wyświetlać komunikat, że nie można załadować wersji System.Net.Http 4.2.0.0, zwraca ten wyjątek.

Zdarzyło mi się to przy użyciu MVC4 i po przeczytaniu tego wątku postanowiłem zmienić nazwę obiektu, który zgłosił błąd.

Zrobiłem porządek i odbudowałem i zauważyłem, że pomijałem dwa projekty. Kiedy przebudowałem jeden z nich, wystąpił błąd, w którym uruchomiłem funkcję i jej nie ukończyłem.

Więc VS odnosił się do modelu, który przepisałem, nie pytając mnie, czy chcę to zrobić.

Na wszelki wypadek to pomaga, chociaż jest to stary problem, mój problem był nieco dziwny.

Miałem ten błąd podczas korzystania z Jenkinsa.

W końcu okazało się, że data systemowa została ręcznie ustawiona na datę przyszłą, co spowodowało kompilację biblioteki dll z tą datą przyszłą. Kiedy data została ustawiona na normalną, MSBuild zinterpretował, że plik jest nowszy i nie wymaga ponownej kompilacji projektu.

Natknąłem się na ten problem i dla mnie jednym projektem był List, który znajdował się w przestrzeni nazw Przykład.Sensors, a inny typ zaimplementował interfejs ISensorInfo. Klasa Type1SensorInfo, ale ta klasa była o jedną warstwę głębiej w przestrzeni nazw w Example.Sensors.Type1. Podczas próby przekształcenia Type1SensorInfo z listy na postać, zwrócił wyjątek. Kiedy dodałem przy użyciu Example.Sensors.Type1 do interfejsu ISensorInfo, nie ma już wyjątku!

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

Zdarzyło mi się tak samo, gdy w tle działało wiele procesów MSBuild, które uległy awarii (miały odniesienia do starych wersji kodu). Zamknąłem VS i zabiłem wszystkie procesy MSBuild w eksploratorze procesów, a następnie ponownie skompilowałem.

Miałem projekt testowy, który odwołuje się do 2 innych projektów, z których każdy odnosi się do różnych wersji (w różnych lokalizacjach) tej samej biblioteki DLL. To pomieszało kompilator.

W moim przypadku spotify.exe używał tego samego portu, którego mój projekt interfejsu API chciał użyć na maszynie programistycznej. Numer portu to 4381.

Porzuciłem Spotify i wszystko znowu działało dobrze :)

Miałem ten problem, gdy metoda wymagała parametru, którego nie określałem

W moim przypadku nie było żadnej zmiany kodu i nagle jeden z serwerów zaczął otrzymywać ten i tylko ten wyjątek (wszystkie serwery mają ten sam kod, ale tylko jeden zaczął mieć problemy):

System.MissingMethodException: Method not found: '?'.

Stos:

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)

Wydaje mi się, że problem jest uszkodzony AppPool - zautomatyzowaliśmy recykling AppPool, który trwa codziennie o 3 nad ranem, a problem zaczął się o 3 nad ranem, a następnie zakończył się sam o 3 nad ranem następnego dnia.

Musi to być błąd referencyjny firmy Microsoft.

Wyczyściłem, przebudowałem we wszystkich bibliotekach i nadal mam ten sam problem i nie mogłem tego rozwiązać.

Wszystko, co zrobiłem, to zamknąłem aplikację Visual Studio i otworzyłem ją ponownie. To załatwiło sprawę.

To bardzo frustrujące, że tak prosty problem może zająć tyle czasu, ponieważ nie wydaje się, że będzie to coś takiego.

W moim przypadku mój projekt się odnosił Microsoft.Net.Compilers.2.10.0. Kiedy przestawiłem go Microsoft.Net.Compilers.2.7.0, błąd zniknął. Co za tajemniczy błąd z tak różnorodnymi przyczynami.