TypeLoadException mówi „brak implementacji”, ale jest zaimplementowany

Mam bardzo dziwny błąd na naszej maszynie testowej. Błąd jest następujący:

System.TypeLoadException: Method 'SetShort' in type 'DummyItem' from assembly 'ActiveViewers (...)' does not have an implementation.

Po prostu nie rozumiem dlaczego. SetShortjest w DummyItemklasie, a nawet skompilowałem wersję z zapisem do dziennika zdarzeń, aby upewnić się, że nie jest to problem z wdrażaniem / wersjonowaniem. Dziwne jest to, że kod wywołujący nawet nie wywołuje SetShortmetody.

UWAGA - Jeśli ta odpowiedź ci nie pomoże, poświęć czas na przewinięcie w dół innych odpowiedzi dodanych od tego czasu.

Krótka odpowiedź

Może się tak zdarzyć, jeśli dodasz metodę do interfejsu w jednym zestawie, a następnie do klasy implementującej w innym zestawie, ale przebudujesz zespół implementujący bez odwoływania się do nowej wersji zestawu interfejsu.

W tym przypadku DummyItem implementuje interfejs z innego zestawu. Metoda SetShort została niedawno dodana zarówno do interfejsu, jak i do DummyItem - ale zestaw zawierający DummyItem został przebudowany w odniesieniu do poprzedniej wersji zestawu interfejsu. Zatem metoda SetShort jest skuteczna, ale bez magicznego sosu łączącego ją z równoważną metodą w interfejsie.

Długa odpowiedź

Jeśli chcesz spróbować to odtworzyć, spróbuj wykonać następujące czynności:

1. Utwórz projekt biblioteki klas: InterfaceDef, dodaj tylko jedną klasę i skompiluj:

   public interface IInterface
   {
       string GetString(string key);
       //short GetShort(string key);
   }

2. Utwórz projekt biblioteki drugiej klasy: Implementacja (z osobnym rozwiązaniem), skopiuj InterfaceDef.dll do katalogu projektu i dodaj jako odwołanie do pliku, dodaj tylko jedną klasę i skompiluj:

   public class ImplementingClass : IInterface
   {
       #region IInterface Members
       public string GetString(string key)
       {
           return "hello world";
       }
   
       //public short GetShort(string key)
       //{
       //    return 1;
       //}
       #endregion
   }

3. Utwórz trzeci, konsolowy projekt: ClientCode, skopiuj dwie biblioteki dll do katalogu projektu, dodaj odwołania do plików i dodaj następujący kod do metody Main:

    IInterface test = new ImplementingClass();
    string s = test.GetString("dummykey");
    Console.WriteLine(s);
    Console.ReadKey();

4. Uruchom kod raz, konsola mówi „witaj świecie”

5. Odkomentuj kod w dwóch projektach dll i przebuduj - skopiuj dwa dll z powrotem do projektu ClientCode, przebuduj i spróbuj uruchomić ponownie. TypeLoadException występuje podczas próby utworzenia instancji klasy ImplementingClass.

Oprócz tego, co już odpowiedziała własna pytająca, warto zwrócić uwagę na następujące kwestie. Dzieje się tak dlatego, że klasa może mieć metodę z tym samym podpisem co metoda interfejsu bez implementacji tej metody. Poniższy kod ilustruje to:

public interface IFoo
{
    void DoFoo();
}

public class Foo : IFoo
{
    public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
    void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}

Foo foo = new Foo();
foo.DoFoo();               // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo();              // This calls the interface method

Mam to, gdy moja aplikacja nie ma odwołania do innego zestawu definiującego klasę, której użyła metoda w komunikacie o błędzie. Uruchomienie PEVerify dało bardziej pomocny błąd: „System nie może znaleźć określonego pliku”.

Natknąłem się na tę samą wiadomość i oto, co znaleźliśmy: w naszym projekcie wykorzystujemy biblioteki DLL stron trzecich. Po wydaniu nowej wersji zmieniliśmy nasz projekt, aby wskazywał na nowy zestaw bibliotek DLL i pomyślnie skompilowaliśmy.

Wyjątek został zgłoszony, gdy próbowałem zainicjować jedną z klas interfejsu w czasie wykonywania. Zadbaliśmy o to, aby wszystkie pozostałe referencje były aktualne, ale nadal nie ma szczęścia. Potrzebowaliśmy trochę czasu, aby zauważyć (za pomocą Przeglądarki obiektów), że typ zwracany przez metodę w komunikacie o błędzie jest zupełnie nowym typem z nowego, niepowiązanego zestawu.

Dodaliśmy odniesienie do zestawu i błąd zniknął.

• Komunikat o błędzie był dość mylący, ale mniej więcej wskazywał na właściwy kierunek (właściwa metoda, zły komunikat).
• Wystąpił wyjątek, mimo że nie zastosowaliśmy omawianej metody.
• Co prowadzi mnie do pytania: Jeśli w ogóle zostanie zgłoszony ten wyjątek, dlaczego kompilator go nie wykryje?

Ten błąd wystąpił w następującym scenariuszu.

• Oba zestawy A i B odwoływały się do System.Web.Mvc w wersji 3.0.0.0
• Zestaw A odwoływał się do zestawu B i miał klasy, które implementowały interfejsy z zestawu B z metodami zwracającymi klasy z System.Web.Mvc.
• Zestaw A uaktualniony do System.Web.Mvc w wersji 4.0.0.0
• Zestaw C uruchomił poniższy kod (FertPin.Classes.Contact został zawarty w zestawie A):

var target = Assembly.GetAssembly(typeof(FertPin.Classes.Contact));

Dla mnie poprawką było uaktualnienie odwołania System.Web.Mvc w asemblerze B do 4.0.0.0. Teraz wydaje się oczywiste!

Dzięki oryginalnemu plakatowi!

Innym razem możesz otrzymać ten błąd, jeśli masz niepoprawną wersję podpisanego zestawu. To nie jest normalny objaw tej przyczyny, ale oto scenariusz, w którym ją dostałem

• Projekt asp.net zawiera zestaw A i zestaw B, nazwa B jest silnie nazwana

• zestaw A używa Activator.CreateInstance do załadowania zestawu C (tzn. nie ma odniesienia do C, które jest budowane osobno)

• C został zbudowany w odniesieniu do starszej wersji zestawu B niż obecnie

mam nadzieję, że to komuś pomoże - zrozumienie tego zajęło mi wieki.

Miałem też ten błąd, był on spowodowany przez dowolną exe CPU odwołującą się do dowolnych zestawów CPU, które z kolei odnosiły się do zestawu x86.

Wyjątek narzekał na metodę klasy w MyApp.Implementations (Any CPU), która wyprowadziła MyApp.Interfaces (Any CPU), ale w fuslogvw.exe znalazłem ukrytą „próbę załadowania programu z wyjątkiem niepoprawnego formatu” z MyApp .CommonTypes (x86), który jest używany przez oba.

Wracam do tego ... Wiele odpowiedzi tutaj świetnie tłumaczy, na czym polega problem, ale nie jak go naprawić.

Rozwiązaniem tego jest ręczne usunięcie plików bin z katalogu opublikowanego projektu. Wyczyści wszystkie referencje i zmusi projekt do korzystania z najnowszych bibliotek DLL.

Nie sugeruję używania funkcji usuwania narzędzi do publikowania, ponieważ ma to tendencję do odrzucania IIS.

Mam jeszcze inne ezoteryczne rozwiązanie tego komunikatu o błędzie. Uaktualniłem docelową platformę z .Net 4.0 do 4.6, a mój projekt testu jednostkowego dawał mi błąd „System.TypeLoadException ... nie ma implementacji” podczas próby kompilacji. Dał także drugi komunikat o błędzie dotyczący tej samej rzekomo niezaimplementowanej metody, która mówiła: „Zadanie„ BuildShadowTask ”nieoczekiwanie zakończyło się niepowodzeniem”. Żadna z tych rad nie pomogła, więc szukałem „BuildShadowTask” i znalazłem post na MSDN, który skłonił mnie do skorzystania z edytora tekstu do usunięcia tych wierszy z pliku csproj projektu testowego.

<ItemGroup>
  <Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>

Następnie oba błędy zniknęły i projekt został zbudowany.

Wystąpił ten błąd w kontekście, w którym korzystałem z funkcji Autofac i dużej ilości dynamicznego ładowania zespołu.

Podczas wykonywania operacji rozpoznawania Autofac środowisko wykonawcze nie może załadować jednego z zestawów. Komunikat o błędzie narzekał, że Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Symptomy występowały podczas działania na maszynie wirtualnej z systemem Windows Server 2012 R2, ale nie występowały na maszynach wirtualnych z systemem Windows 10 lub Windows Server 2016.

ImplementationAssemblyodwoływał się do System.Collections.Immutable1.1.37 i zawierał implementacje IMyInterface<T1,T2>interfejsu, który został zdefiniowany w osobnym DefinitionAssembly. DefinitionAssemblywymieniony System.Collections.Immutable1.1.36.

Metody, z IMyInterface<T1,T2>których „nie zaimplementowano”, miały parametry typu IImmutableDictionary<TKey, TRow>zdefiniowane w System.Collections.Immutable.

Rzeczywista kopia System.Collections.Immutableznaleziona w katalogu programu to wersja 1.1.37. Na mojej maszynie wirtualnej z systemem Windows Server 2012 R2 GAC zawierał kopię System.Collections.Immutable1.1.36. W systemach Windows 10 i Windows Server 2016 GAC zawierał kopię System.Collections.Immutable1.1.37. Błąd ładowania wystąpił tylko wtedy, gdy GAC zawierał starszą wersję biblioteki DLL.

Tak więc główną przyczyną niepowodzenia ładowania zestawu były niedopasowane odwołania System.Collections.Immutable. Definicja interfejsu i implementacja miały identycznie wyglądające sygnatury metod, ale w rzeczywistości zależały od różnych wersji System.Collections.Immutable, co oznaczało, że środowisko wykonawcze nie uznało klasy implementacji za zgodną z definicją interfejsu.

Dodanie następującego przekierowania wiązania do mojego pliku konfiguracyjnego aplikacji naprawiło problem:

<dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.1.37.0" newVersion="1.1.37.0" />
</dependentAssembly>

Mam to w zależności od projektu w kształcie „rombu”:

• Projekt A wykorzystuje Projekt B i Projekt D
• Projekt B wykorzystuje Projekt D

Zrekompilowałem projekt A, ale nie projekt B, który pozwolił Projektowi B „wstrzyknąć” starą wersję biblioteki DLL projektu

Spotkałem się z tym, kiedy zmieniłem nazwę projektu (i nazwy zestawu), od którego zależał projekt ASP.NET. Typy w projekcie sieciowym implementują interfejsy w zespole zależnym. Pomimo wykonania Czystego rozwiązania z menu Kompilacja, zespół o poprzedniej nazwie pozostał w binfolderze i po uruchomieniu mojego projektu internetowego

var types = AppDomain.CurrentDomain.
   GetAssemblies().
   ToList().
   SelectMany( s => s.GetTypes() /* exception thrown in this call */ )
;

powyższy wyjątek został zgłoszony, narzekając, że metody interfejsu w implementujących typach sieci nie zostały faktycznie zaimplementowane. Ręczne usunięcie zestawu w binfolderze projektu internetowego rozwiązało problem.

Ten błąd również wystąpił, gdy wcześniej włączyłem Pokrycie kodu podczas testowania jednostek dla jednego z zespołów. Z jakiegoś powodu program Visual Studio „buforował” starą wersję tej konkretnej biblioteki DLL, mimo że ją zaktualizowałem, aby zaimplementować nową wersję interfejsu. Wyłączenie pokrycia kodu pozbyło się błędu.

Ten błąd może być również spowodowany, jeśli zestaw jest ładowany przy użyciu Assembly.LoadFrom (String) i odnosi się do zestawu, który został już załadowany przy użyciu Assembly.Load (Byte []).

Na przykład osadziłeś zestawy główne aplikacji jako zasoby, ale aplikacja ładuje wtyczki z określonego folderu.

Zamiast używać LoadFrom, powinieneś użyć Load. Następujący kod wykona zadanie:

private static Assembly LoadAssemblyFromFile( String filePath )
{
    using( Stream stream = File.OpenRead( filePath ) )
    {
        if( !ReferenceEquals( stream, null ) )
        {
            Byte[] assemblyData = new Byte[stream.Length];
            stream.Read( assemblyData, 0, assemblyData.Length );
            return Assembly.Load( assemblyData );
        }
    }
    return null;
}

Kolejne wyjaśnienie tego rodzaju problemu dotyczącego zarządzanego C ++.

Jeśli spróbujesz wkleić interfejs zdefiniowany w zestawie utworzonym przy użyciu zarządzanego C ++, który ma specjalną sygnaturę, otrzymasz wyjątek podczas tworzenia kodu pośredniczącego.

Jest to prawdą w przypadku Rhino Mocks i prawdopodobnie każdego używanego frameworka System.Reflection.Emit.

public interface class IFoo {
  void F(long bar);
};

public ref class Foo : public IFoo {
public:
  virtual void F(long bar) { ... }
};

Definicja interfejsu otrzymuje następujący podpis:

void F(System.Int32 modopt(IsLong) bar)

Zauważ, że typ C ++ longodwzorowuje na System.Int32(lub po prostu intw C #). Jest to nieco niejasne, modoptktóre powoduje problem, jak stwierdził Ayende Rahien na liście mailingowej Rhino Mocks .

Właśnie zaktualizowałem rozwiązanie z MVC3 do MVC5 i zacząłem otrzymywać ten sam wyjątek od mojego projektu testu jednostkowego.

Sprawdziłem wszystkie referencje szukając starych plików, w końcu odkryłem, że muszę wykonać pewne przekierowania wiązania dla Mvc w moim projekcie testu jednostkowego.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

W moim przypadku pomogło zresetować zestaw narzędzi WinForms.

Mam wyjątek podczas otwierania Formw projektancie; kompilacja i uruchomienie kodu było jednak możliwe, a kod działał zgodnie z oczekiwaniami. Wyjątek wystąpił w lokalnej UserControlimplementacji interfejsu z jednej z moich bibliotek, do których istnieją odniesienia. Błąd pojawił się po aktualizacji tej biblioteki.

Zostało UserControlto wymienione w zestawie narzędzi WinForms. Prawdopodobnie Visual Studio zachował odnośnik do nieaktualnej wersji biblioteki lub buforował gdzieś nieaktualną wersję.

Oto, jak wyzdrowiałem z tej sytuacji:

1. Kliknij prawym przyciskiem myszy Przybornik WinForms i kliknij Reset Toolboxw menu kontekstowym. (Spowoduje to usunięcie niestandardowych elementów z Przybornika).
   W moim przypadku elementy Toolbox zostały przywrócone do stanu domyślnego; brakowało jednak strzałki-wskaźnika w Przyborniku.
2. Zamknij Visual Studio.
   W moim przypadku program Visual Studio zakończył działanie z wyjątkiem naruszenia i został przerwany.
3. Uruchom ponownie Visual Studio.
   Teraz wszystko działa płynnie.

FWIW, otrzymałem to, gdy istniał plik konfiguracyjny przekierowujący do nieistniejącej wersji zestawu odniesienia. Dzienniki Fusion dla wygranej!

Wystąpił ten błąd, ponieważ miałem klasę w zestawie „C”, która znajdowała się w wersji 4.5 frameworka, implementując interfejs w zestawie „A”, który był w wersji 4.5.1 frameworka i służąc jako klasa bazowa dla asemblera „B”, który był również w wersji 4.5.1 ram. System zgłosił wyjątek podczas próby załadowania zestawu „B”. Dodatkowo zainstalowałem kilka pakietów nuget ukierunkowanych na .net 4.5.1 na wszystkich trzech zestawach. Z jakiegoś powodu, mimo że odniesienia nuget nie były wyświetlane w zestawie „B”, budowanie przebiegło pomyślnie.

Okazało się, że prawdziwym problemem było to, że zestawy odwoływały się do różnych wersji pakietu nuget zawierającego interfejs, a sygnatura interfejsu zmieniała się między wersjami.

W moim przypadku wcześniej odwoływałem się do mylibprojektu w folderze rodzeństwa poza repozytorium - nazwijmy to v1.0.

|-- myrepo
|    |-- consoleApp
|    |-- submodules
|         |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)

Później zrobiłem to poprawnie i użyłem go przez submoduł git - nazwijmy to v2.0. Jeden projekt consoleAppnie został jednak poprawnie zaktualizowany. Nadal odwoływał się do starego v1.0projektu poza moim projektem git.

Mylące , mimo że *.csprojbyło to po prostu błędne i wskazuje v1.0, Visual Studio IDE pokazało ścieżkę jako v2.0projekt! F12, aby sprawdzić interfejs i klasę, również przeszedł do v2.0wersji.

Zespół umieszczony w folderze bin przez kompilator był v1.0wersją, stąd ból głowy.

Fakt, że IDE mnie okłamał, bardzo utrudnił zrozumienie błędu.

Rozwiązanie : usunięto odniesienia do projektu ConsoleAppi odczytałem je.

Porada ogólna: Ponownie skompiluj wszystkie zestawy od zera (tam, gdzie to możliwe, oczywiście nie jest to możliwe w przypadku pakietów nuget) i sprawdź znaczniki datetime w bin\debugfolderze. Wszystkie stare datowane zespoły są twoim problemem.

Napotkałem prawie ten sam problem. Drapałem się w głowę, co powoduje ten błąd. Sprawdziłem krzyżowo, wszystkie metody zostały wdrożone.

Na Googlingu dostałem ten link między innymi. Na podstawie komentarza @Paul McLink, te dwa kroki rozwiązały problem.

1. Uruchom ponownie Visual Studio
2. Oczyść, zbuduj (przebuduj)

i błąd zniknął .

Uruchom ponownie wtyczkę VS

Dzięki Paul :)

Mam nadzieję, że to pomoże komuś, kto napotka ten błąd :)

Zetknąłem się również z tym problemem podczas uruchamiania moich najsprawniejszych. Aplikacja działała poprawnie i bez błędów. Przyczyną problemu w moim przypadku było to, że wyłączyłem budowę projektów testowych. Ponowne włączenie budowy moich projektów testowych rozwiązało problemy.

Widziałem to w programie Visual Studio Pro 2008, gdy dwa projekty budowały zestawy o tej samej nazwie, jeden klasowy lib SDF.dll i jeden, który odwoływał się do biblioteki lib o nazwie zestawu sdf.exe. Kiedy zmieniłem nazwę zestawu odniesienia, wyjątek zniknął

Oznacza to po prostu, że projekt wdrożeniowy jest nieaktualny w moich przypadkach. Biblioteka DLL zawierająca interfejs została przebudowana, ale dll implementacji był nieaktualny.

Oto moje zdanie na temat tego błędu.

Dodano externmetodę, ale moja pasta była wadliwa. DllImportAttributeGot umieścić na zakomentowanym linii.

/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")] 
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);

Sprawdzenie, czy atrybut został faktycznie dołączony do źródła, rozwiązało problem.

Dostałem to w usłudze WCF ze względu na wybranie typu kompilacji x86, co powoduje, że pojemniki działają pod bin \ x86 zamiast bin. Wybranie dowolnego procesora spowodowało, że skompilowane biblioteki DLL trafiły do ​​właściwych lokalizacji (nie będę szczegółowo omawiał, jak to się stało).

Miałem ten sam problem. Doszedłem do wniosku, że mój zestaw, który jest ładowany przez program główny, zawierał pewne odniesienia z ustawieniem „Kopiuj lokalnie” na true. Te lokalne kopie referencji szukały innych referencji w tym samym folderze, które nie istniały, ponieważ „Kopiuj lokalnie” innych referencji ustawiono na fałsz. Po usunięciu „przypadkowo” skopiowanych referencji błąd zniknął, ponieważ program główny ustawiono tak, aby szukał poprawnej lokalizacji referencji. Najwyraźniej lokalne kopie referencji spieszyły sekwencję wywoływania, ponieważ te lokalne kopie zostały użyte zamiast oryginalnych kopii obecnych w programie głównym.

Komunikat zabrania do domu jest taki, że ten błąd pojawia się z powodu brakującego łącza do załadowania wymaganego zestawu.

W moim przypadku próbowałem użyć TypeBuilderdo utworzenia typu. TypeBuilder.CreateTyperzucił ten wyjątek. W końcu zdałem sobie sprawę, że muszę dodać MethodAttributes.Virtualdo atrybutów, gdy wzywam TypeBuilder.DefineMethodmetodę, która pomaga zaimplementować interfejs. Wynika to z faktu, że bez tej flagi metoda nie implementuje interfejsu, a zamiast tego nową metodę z tym samym podpisem (nawet bez określenia MethodAttributes.NewSlot).

Jako uzupełnienie: może to również nastąpić, jeśli zaktualizujesz pakiet nuget, który został użyty do wygenerowania fałszywego zestawu. Załóżmy, że instalujesz wersję 1.0 pakietu nuget i tworzysz fałszywy zestaw „fakeLibrary.1.0.0.0.Fakes”. Następnie aktualizujesz do najnowszej wersji pakietu nuget, powiedzmy v1.1, która dodała nową metodę do interfejsu. Biblioteka Fakes nadal szuka wersji 1.0 biblioteki. Po prostu usuń fałszywy zespół i zregeneruj go. Jeśli to był problem, prawdopodobnie to rozwiąże.

Ten błąd wystąpił po ostatniej aktualizacji systemu Windows. Miałem klasę usług ustawioną na dziedziczenie z interfejsu. Interfejs zawierał podpis, który zwrócił ValueTuple, dość nową funkcję w języku C #.

Mogę tylko zgadywać, że aktualizacja systemu Windows zainstalowała nową, ale nawet wyraźnie ją odwołuje, aktualizuje przekierowania wiązania itp. Ostatecznym rezultatem była zmiana podpisu metody na coś „standardowego”. Myślę, że można powiedzieć.