System.MissingMethodException: Nie znaleziono metody?

245

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()
    {
    //
    }
}
użytkownik603007
źródło
możesz napisać trochę więcej kodu, ponieważ ten kod jest nieprawidłowy.
mironych
2
Co to jest somepage? Jak zauważono w „dźwięku”, ten kod jest nieprawidłowy. Podaj nam pełny fragment kodu, który pokazuje problem.
Amy,

Odpowiedzi:

388

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.

Ustrój
źródło
62
W szczególności upewnij się, że starej wersji nie ma w GAC.
ladgedge
7
Ponadto, jeśli pracujesz w niefortunnym przypadku, w którym masz bibliotekę zależną od biblioteki, która zależy od biblioteki itp. Następnie upewnij się, że wyczyścisz / przebudujesz wszystkie zależne biblioteki z tą samą wersją dowolnej biblioteki dll, NHibernate w moim przypadku ...
Serj Sagan
2
Uaktualnienie docelowej struktury .NET dla projektu może również naprawić błąd. Aktualizowałem projekt MVC4 / Web API 1 ukierunkowany na .NET 4.5. Po uaktualnieniu wszystkich zależności MVC, Web API i Entity Framework napotkałem ten sam błąd; zmiana docelowej struktury na .NET 4.5.1 sprawiła, że ​​błąd zniknął.
Sergey K,
1
Zdarzyło mi się to, gdy wdrożyłem tylko zmieniony plik exe i nie wdrożyłem biblioteki pomocniczej, ponieważ nie zmienił kodu - ale został przebudowany. Po wdrożeniu przebudowanej biblioteki dll błąd zniknął. Wykonałem inne wdrożenia bez ponownego wdrażania biblioteki DLL bez zmian i nie miałem żadnych problemów, więc nadal nie jestem pewien, co dokładnie się tutaj wydarzyło. Wydaje mi się, że bezpieczną rzeczą jest wdrożenie każdego odbudowanego pliku bez względu na to, czy zawiera on zmiany w kodzie, czy nie.
Ho Ho Ho
14
Przydało mi się otwarcie okna Debugowanie -> Windows -> Moduły podczas debugowania, aby zobaczyć, skąd ładowany jest zestaw.
JamesD
32

⚠️ 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 .

ΩmegaMan
źródło
1
Naprawiłem to dla mnie. Zarządzanie pakietami dla rozwiązania nie działało, ale musiałem aktualizować każdy projekt indywidualnie.
aoakeson
Mój projekt testu jednostkowego odwoływał się do nowej wersji niż mój rzeczywisty projekt
Rhyous,
26

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.

Ben Gripka
źródło
2
jakiś problem z .NET 3.5 docelowego kompilacji i zainstalowany .NET 3. Naprawdę zastanawiam się, dlaczego nie jest bardziej podstawowe ostrzeżenie przy starcie ...
Martin Meeser
W przypadku .NET Framework w wersji> 4.0 należy określić jednostkę magazynową (SKU), która wskazuje wersję .NET Framework, na którą jest kierowana aplikacja. docs.microsoft.com/en-us/dotnet/framework/configure-apps/…
bgcode
21

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

Jelani
źródło
5

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.

Josh Noe
źródło
5

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

Mark Meuer
źródło
5

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.

Julie
źródło
Dla mnie dobrze działało czyszczenie projektu, usuwanie i ponowne dodawanie referencji.
Honza P.,
Jest to szczególnie problem z VS 2017, ponieważ często oferuje dodanie odniesienia, które ustawia ścieżkę źródłową do folderu wyjściowego innego projektu w rozwiązaniu, a nie do folderu wyjściowego zestawu referencyjnego.
Pan TA
4

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")]
sennett
źródło
Jak mam to sprawdzić?
SerG
Myślę w nupkg.
sennett
4

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

użytkownik384080
źródło
3

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.

Lee Bailey
źródło
3

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.

Jamie Lupton
źródło
2

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!

DaBeSoft
źródło
@RenaudGauthier może źle odczytałem coś w odpowiedzi Jona Skeetsa, ale stwierdza, że ​​klasy bez modyfikatora dostępu są wewnętrzne, a w komentarzach dosłownie stwierdza: „Nie, nie jest. Jeśli zadeklarujesz konstruktor i nie określisz dostępności, będzie to być prywatny. Patrz sekcja 10.3.5 specyfikacji C # ". Więc chyba mój konstruktor jest prywatny? Popraw mnie, jeśli się mylę. I tak, moja odpowiedź była poza kontekstem, przyszedłem tutaj z innego pytania (które nie dało mi odpowiedzi). Dodam tam również link do mojej odpowiedzi.
DaBeSoft,
Masz absolutną rację, nieważne, usunąłem bezużyteczny komentarz.
Renaud Gauthier
1

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.

Ron Kanagy
źródło
1

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ął ...

Irshu
źródło
1

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.

fbastian
źródło
1

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.

Jimmy
źródło
1

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.

grep65535
źródło
1

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.

Alexandre Daubricourt
źródło
1

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.

Legolas
źródło
0

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

TheWizardOfTN
źródło
0

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.

Renato Chencinski
źródło
0

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() 
    }
}
Steven Koxlien
źródło
0

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.

bytedev
źródło
0

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.

nuander
źródło
0

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

Arda Basoglu
źródło
0

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

Lord Darth Vader
źródło
0

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.

Jerzy
źródło
0

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.

JayJay Barnard
źródło
0

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.

jaycer
źródło