2011-12-15 11 views
9

Po prostu chciałem się podzielić czymś, czego się nauczyłem. Istnieje wiele postów dotyczących Wyjątków TypeLoadException, ale żaden z nich nie posiadał odpowiedzi, której potrzebowałem.Rozwiązanie wyjątku TypeLoadException

Ta strona ma jakieś szczególnie dobre informacje, ale nie wydaje się szczególnie zająć co widziałem i jak rozwiązać go (może być źle):

TypeLoadException says 'no implementation', but it is implemented

roztworze dla mnie było proste: Usuń wszystkie pliki Visual Studio 2010 buforuje i wykorzystuje do generowania plików zespołu.


Tło Problem:

Oto kilka szczegółów. Ja widząc TypeLoadException jak:

Nieobsłużone Wyjątek System.TypeLoadException: Metoda [nazwa Metoda] w typu [nazwa Type] [nazwa z zespołu montażowego] Wersja = xxxx culture = neutralne TokenKluczaPublicznego = null nie ma implementacji.

Miałem wdrożenie ... Pomyślałem, dopóki nie spojrzałem na zgromadzenie z ILDASM. Odkryłem, że otrzymuję stare wersje bibliotek DLL zapisanych w folderze ouput, który ma przestarzałe interfejsy. Mój folder wyjściowy nie był domyślnym ustawieniem, ale względną ścieżką poza folderem projektu (może VS nie może tego całkowicie obsłużyć?). Po wyczyszczeniu/odbudowie projektu, folder projektu "obj" projektu był jedynym folderem we wszystkich folderach podrzędnych mojego folderu projektu, który miał poprawny znacznik daty w bibliotece DLL. Folder "bin" z jakiegoś powodu wciąż miał starą wersję. I przypuszczam, że to właśnie było kopiowane do folderu wyjściowego.

Wcześniej próbowałem:

  • czyste/odbudować
  • ponownym uruchomieniu Visual Studio (2010)
  • restartu
  • usuwanie moich DLL montażu w folderze wyjściowym (bin \ x86 \ debug)

... bez powodzenia.

Nie jestem pewien, dlaczego VS nie kopiował prawidłowego zestawu w "obj" do folderu wyjściowego ... Projekt, który odwołuje się do przestarzałego zespołu , był poprawny.

+2

Nie zamieszczaj rozwiązania w pytaniu. Po prostu opublikuj pytanie tak, jakby problem nadal występował, a następnie prześlij rozwiązanie jako odpowiedź.Lepiej poczekać dzień lub dłużej - dać ludziom czas na opublikowanie własnych rozwiązań, może się okazać, że jesteś lepszy od twojego. – ChrisF

+0

Muszę się zgodzić z @ChrisF, powinieneś najpierw opublikować pytanie, a potem odpowiedź Odpowiedź choć doceniam (pomogła mi), że mogłeś zdobyć trochę punktów za to też i może zobaczyłeś odpowiedzi innych ludzi, które zrobiłeś myślę. – iMortalitySX

Odpowiedz

2

Czy używasz jakiejś kontroli źródła i robi check in i sprawdź rzeczy? Jeśli tak, upewnij się, że foldery obj i bin nie są zaznaczone w elemencie źródłowym. Jeśli są one następnie usunąć je z kontroli źródła, sprawdź wszystko, a następnie ponownie zbudować rozwiązanie.

0

Miałem tego rodzaju problem w Visual Studio 2015, i rozwiązałem go za pomocą menedżera pakietów NuGet dla rozwiązania, aby ponownie zainstalować pakiet, który jakoś został zainstalowany w różnych wersjach.