Nie można załadować typu z błędu zespołu


120

Napisałem następujący prosty test, próbując nauczyć się płynnego interfejsu Castle Windsor:

using NUnit.Framework;
using Castle.Windsor;
using System.Collections;
using Castle.MicroKernel.Registration;

namespace WindsorSample {
    public class MyComponent : IMyComponent {
        public MyComponent(int start_at) {
            this.Value = start_at;
        }
        public int Value { get; private set; }
    } 
    public interface IMyComponent {
        int Value { get; }
    }

    [TestFixture]
    public class ConcreteImplFixture {
        [Test]
        public void ResolvingConcreteImplShouldInitialiseValue() {
            IWindsorContainer container = new WindsorContainer();
            container.Register(Component.For<IMyComponent>().ImplementedBy<MyComponent>().Parameters(Parameter.ForKey("start_at").Eq("1")));
            IMyComponent resolvedComp = container.Resolve<IMyComponent>();
            Assert.AreEqual(resolvedComp.Value, 1); 
        }
    }
}

Kiedy wykonuję test za pomocą TestDriven.NET, pojawia się następujący błąd:

System.TypeLoadException : Could not load type 'Castle.MicroKernel.Registration.IRegistration' from assembly 'Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'.
at WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue()

Kiedy wykonuję test przez GUI NUnit, otrzymuję:

WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue:
System.IO.FileNotFoundException : Could not load file or assembly 'Castle.Windsor, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The system cannot find the file specified.

Jeśli otworzę zestaw, do którego się odwołuję w Reflector, zobaczę, że jego informacje to:

Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc

i że na pewno zawiera Castle.MicroKernel.Registration.IRegistration

Co się mogło dziać?

Powinienem wspomnieć, że pliki binarne są pobierane z najnowszej wersji Castle'a, chociaż nigdy nie pracowałem z nantem, więc nie zawracałem sobie głowy ponowną kompilacją ze źródła i po prostu wziąłem pliki z katalogu bin. Powinienem również zaznaczyć, że mój projekt kompiluje się bez problemu.

Odpowiedzi:


111

Czy zestaw znajduje się w globalnej pamięci podręcznej zestawów (GAC) lub w jakimkolwiek miejscu, w którym może nadpisywać zestaw, który Twoim zdaniem jest ładowany? Zwykle jest to wynikiem załadowania nieprawidłowego zestawu, dla mnie oznacza to, że zwykle mam coś w GAC, nadpisując wersję, którą mam w bin / Debug.


1
Dodałem zestawy, przeglądając pliki dll, więc GAC nie powinien wchodzić do równania. Kliknij również prawym przyciskiem myszy na złożeniu -> otwórz w reflektorze z eksploratora rozwiązań, wyświetlając go w reflektorze ze wszystkimi informacjami, których bym się spodziewał
— George Mauer

7
Nie ma znaczenia, w jaki sposób go dodałeś, jeśli zestaw o tej samej nazwie / wersji istnieje w GAC, załaduje ten.
— Eric Schoonover,

1
VS.NET wyświetli ścieżkę do wybranego zestawu, a reflector otworzy odpowiedni zestaw, ale gdy aplikacja wykona, środowisko uruchomieniowe .NET załaduje zestaw GAC.
— Eric Schoonover,

11
To już drugi raz, kiedy ta odpowiedź uratowała mi tyłek. Zagłosowałbym ponownie, gdybym mógł.
— whybird

17
(GAK. Powiedz to głośno. Sam dźwięk nazwy ostrzega, jak to jest.)
— whybird

131

Jeśli masz jeden projekt odwołujący się do innego projektu (na przykład typ „Aplikacja systemu Windows” odwołujący się do „Biblioteki klas”) i oba mają tę samą nazwę zestawu, zostanie wyświetlony ten błąd. Możesz albo silnie nazwać projekt, do którego się odwołujesz, albo (jeszcze lepiej) zmienić nazwę zestawu projektu, do którego się odwołujesz (w zakładce „Aplikacja” we właściwościach projektu w VS).


Ponadto: spróbuj wyczyścić folder wyjściowy. Prawdopodobnie zmiana nazwy biblioteki może spowodować ten sam problem, ponieważ obie (stara i nowa) zostaną umieszczone w tym samym folderze wyjściowym.
— Manushin Igor

Jeśli wycinasz i wklejasz projekt i nie edytujesz poprawnie wszystkich pól, może to doprowadzić do tego problemu!
— Michael Parker

1
To było to dla mnie, odwoływałem się już do Assembly w bibliotece klas, do której się odwołuje. Musiałem przejść do pliku web.config mojego projektu internetowego i usunąć odniesienie <dependantAssembly> po odinstalowaniu pakietu w nuGet, aby działało.
— Ivan

16

Rozwiązanie tego dla mnie nie zostało wymienione powyżej, więc pomyślałem, że dodam swoją odpowiedź do długiego ogona ...

Skończyło się na tym, że miałem stare odniesienie do klasy (a HttpHandler) w web.config, która nie była już używana (i nie była już poprawnym odniesieniem). Z jakiegoś powodu został zignorowany podczas pracy w Studio (a może mam tę klasę nadal dostępną w mojej konfiguracji deweloperskiej?), Więc ten błąd pojawił się dopiero po próbie wdrożenia w IIS. Szukałem nazwy zestawu w web.config, usunąłem nieużywane odniesienie do modułu obsługi, a następnie ten błąd zniknął i wszystko działa świetnie. Mam nadzieję, że to pomoże komuś innemu.


1
Miało coś bardzo podobnego, jedyną różnicą było to, że odwołanie z pliku web.config do biblioteki DLL wciąż było wdrożone w katalogu bin. Ten plik binarny z kolei odwoływał się do starej wersji współużytkowanej biblioteki DLL, która spowodowała wyjątek.
— Santos

10

Miałem ten sam problem i dla mnie nie miało to nic wspólnego z przestrzenią nazw ani nazwami projektów.

Ale jak sugerowało kilku użytkowników, miało to związek z tym, że wciąż istnieją odwołania do starego zestawu.

Zalecam usunięcie wszystkich folderów „bin” / binarnych wszystkich projektów i przebudowanie całego rozwiązania. Spowodowało to wymycie wszelkich potencjalnie przestarzałych zestawów, a następnie MEF wyeksportował wszystkie moje wtyczki bez problemu.


8

Otrzymałem ten błąd i nic, co znalazłem w StackOverflow ani w innym miejscu, nie rozwiązało go, ale odpowiedź bmoeskau na to pytanie wskazała mi właściwy kierunek dla poprawki, która nie została jeszcze wymieniona jako odpowiedź. Moja odpowiedź nie jest ściśle związana z pierwotnym pytaniem, ale zamieszczam ją tutaj, zakładając, że ktoś mający ten problem odnajdzie się tutaj, przeszukując Google lub coś podobnego (jak ja za miesiąc, kiedy to mnie znowu gryzie , arg!).

Mój zespół znajduje się w GAC, więc teoretycznie dostępna jest tylko jedna wersja zestawu. Z wyjątkiem tego, że IIS pomaga w buforowaniu starej wersji i daje mi ten błąd. Właśnie zmieniłem, przebudowałem i ponownie zainstalowałem zespół w GAC. Jednym z możliwych rozwiązań jest użycie Menedżera zadań do zabicia programu w3wp.exe . Zmusza to usługi IIS do ponownego odczytania zestawu z GAC: problem rozwiązany.


3

Wersja = 1.0.3.0 oznacza Castle RC3, jednak płynny interfejs został opracowany kilka miesięcy po wydaniu RC3. Dlatego wygląda na to, że masz problem z wersjonowaniem. Może masz Castle RC3 zarejestrowany w GAC i używa tego ...


Co ciekawe, najnowszą wersję mam tutaj: builds.castleproject.org/cruise/DownloadBuild.castle?number=956 To, co polecili na swoim forum. A gdyby tak było, wyobrażam sobie, że projekt w ogóle by się nie skompilował. Ale to nie stanowi problemu
— George Mauer,

Jeśli chodzi o posiadanie wersji w GAC to chyba tak, ale nie dodałem referencji z GAC-a i użycie reflektora na referencji wskazuje, że to ta, o której myślałem
— George Mauer

Spróbuj usunąć zduplikowany zestaw z GAC, jestem gotów to być twój problem.
— Eric Schoonover,

3

Od czasu do czasu dostaję to i zawsze chodziło o zgromadzenie w GAC


3

Jeśli ten błąd jest spowodowany zmianą przestrzeni nazw, upewnij się, że folder tego projektu ma tę samą nazwę i zamknij VS.NET Edytuj projekt, który ma problem z Notatnikiem i zamień tam węzły

"RootNamespace> New_Name_Of_Folder_Of_Your_Project_Namespace" RootNamespace> "AssemblyName> New_Name_Of_Folder_Of_Your_Project_Namespace" AssemblyName>


3

Usunięcie mojego pliku .pdb dla biblioteki dll rozwiązało ten problem. Domyślam się, że ma to coś wspólnego z faktem, że dll została utworzona przy użyciu ILMerge.


To było to dla mnie! Nie wiem, co to jest ILMerge, ale Epicor nie lubił mieć pliku pdb obok mojego zestawu.
— MDave

Brak ILMerge, ale usunięcie wszystkich plików PDB rozwiązało problem.
— hogarth45

3

Kiedy napotykam taki problem, narzędzie FUSLOGVW jest bardzo pomocne. Sprawdza informacje o powiązaniach zestawu i rejestruje je dla Ciebie. Czasami brakuje bibliotek, czasami GAC ma różne wersje, które są ładowane. Czasami platforma bibliotek, do których istnieją odniesienia, powoduje problemy. To narzędzie wyjaśnia, w jaki sposób są rozwiązywane powiązania zależności, a to może naprawdę pomóc w zbadaniu / debugowaniu problemu.

Fusion Log Viewer / fuslogvw / Assembly Binding Log Viewer. Sprawdź więcej / pobierz tutaj: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx .


Czy istnieje sposób, aby FUSLOGVW współpracował z Visual Studio Designer? Visual Studio Designer zgłasza wyjątek, gdy próbuję edytować jedno z moich okien dialogowych („Nie znaleziono metody”) dla metody, o której wiem, że istnieje (aplikacja działa poprawnie). O ile widzę, nic nie pojawia się w FUSLOGVW podczas edytowania czegoś w Visual Studio Designer.
— Jimmy

3

Miałem ten problem po uwzględnieniu nazwy klasy:
Could not load type 'Namspace.OldClassName' from assembly 'Assembly name...'.

Zatrzymanie usług IIS i usunięcie zawartości w Temporary ASP.NET Filesrozwiązaniu dla mnie.

W zależności od projektu (wersja 32/64-bitowa, .net, itp.) Poprawne Temporary ASP.NET Filesróżnią się:

  • 64-bitowy
    %systemroot%\Microsoft.NET\Framework64\{.netversion}\Temporary ASP.NET Files\
  • 32-bitowy
    %systemroot%\Microsoft.NET\Framework\{.netversion}\Temporary ASP.NET Files\
  • Na moim komputerze deweloperskim było to (może dlatego, że jest to IIS Express?)
    %temp%\Temporary ASP.NET Files

3

Może nie tak prawdopodobne, ale dla mnie było to spowodowane tym, że moja aplikacja próbowała załadować bibliotekę o tej samej nazwie zestawu (xxx.exe ładuje xxx.dll).


2

Po prostu napotkaj to z inną przyczyną:

przeprowadzanie testów jednostkowych w trybie wydania, ale ładowana biblioteka była wersją trybu debugowania, która nie została zaktualizowana


2

Jeszcze inne rozwiązanie: stare biblioteki DLL wskazujące na siebie i buforowane przez program Visual Studio w

C:\Users\[yourname]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

Wyjdź z VS, usuń wszystko w tym folderze i Bob jest twoim wujem.


2

Miałem ten sam problem. Właśnie rozwiązałem ten problem, aktualizując zestaw za pośrednictwem GAC.

Aby korzystać gacutil na maszynie rozwoju adresem: Start -> programs -> Microsoft Visual studio 2010 -> Visual Studio Tools -> Visual Studio Command Prompt (2010).

Użyłem tych poleceń odpowiednio do odinstalowania i ponownej instalacji.

gacutil /u myDLL

gacutil /i "C:\Program Files\Custom\mydllname.dll"

Uwaga: nie odinstalowałem mojej biblioteki dll w moim przypadku właśnie zaktualizowałem bibliotekę dll z aktualną ścieżką.


2

Wpadłem na ten scenariusz, próbując załadować typ (przez odbicie) w zestawie, który został skompilowany na podstawie innej wersji odwołania wspólnego dla aplikacji, w której pojawił się ten błąd.

Ponieważ jestem pewien, że typ jest niezmieniony w obu wersjach zestawu, w końcu utworzyłem niestandardowy program rozpoznawania zestawu, który mapuje brakujący zestaw na ten, który moja aplikacja już załadowała. Najprostszym sposobem jest dodanie konstruktora statycznego do klasy programu w następujący sposób:

using System.Reflection
static Program()
{
    AppDomain.CurrentDomain.AssemblyResolve += (sender, e) => {
        AssemblyName requestedName = new AssemblyName(e.Name);

        if (requestedName.Name == "<AssemblyName>")
        {
            // Load assembly from startup path
            return Assembly.LoadFile($"{Application.StartupPath}\\<AssemblyName>.dll");
        }
        else
        {
            return null;
        }
    };
}

To oczywiście zakłada, że ​​Assembly znajduje się na ścieżce startowej aplikacji i można je łatwo dostosować.


Powinienem zauważyć, że to rozwiązanie ma zastosowanie w przypadkach, w których przekazujesz swoje zestawy stronom trzecim i nie możesz upewnić się, że wszyscy zaktualizują się na czas, gdy to zrobisz. W przeciwnym razie zaleca się ponowną kompilację z poprawionymi odwołaniami.
— JBartlau

2

Po prostu napotkaj to z inną przyczyną:

Używałem scalonego zestawu utworzonego za pomocą ILRepack. Zestaw, z którego wysyłasz zapytanie o typy, musi być pierwszym przekazanym do ILRepack lub jego typy nie będą dostępne.



1

Zwykle dzieje się tak, gdy masz jedną wersję zestawu wdrożoną w GAC, ale nie została ona zaktualizowana o nowe klasy, które mogły zostać dodane do zestawu w środowisku IDE. Dlatego upewnij się, że zestaw na GAC ​​jest aktualizowany zmianami, które mogłeś wprowadzić w projekcie.

Np. Jeśli masz bibliotekę klas Common i w tej bibliotece klas masz typ Common.ClassA i wdrażasz go w GAC o silnej nazwie. Przychodzisz później i dodajesz inny typ o nazwie Common.ClassB i uruchamiasz swój kod w swoim IDE bez wcześniejszego wdrażania zmian wprowadzonych w GAC of Common z nowo dodanym typem Common.ClassB.


1

Ten sam błąd wystąpił po zaktualizowaniu biblioteki DLL, do której istnieje odwołanie w projekcie wykonywalnym na komputerze stacjonarnym. Problem polegał na tym, że ludzie tutaj wspominali, odnosili się do starego odniesienia i był łatwy do naprawienia, ale nie został tutaj wspomniany, więc pomyślałem, że może to zaoszczędzić czas innych ludzi.

W każdym razie zaktualizowałem bibliotekę dll A i otrzymałem błąd z innej biblioteki dll, do której się odwołujemy, nazwijmy ją tutaj B, gdzie dll A ma odniesienie do biblioteki dll B.

Aktualizacja biblioteki dll B rozwiązała problem.


1

Dodawanie biblioteki DLL do GAC (globalna pamięć podręczna zestawu)

Visual Studio Command Prompt => Uruchom jako administrator

gacutil / i "ścieżka do pliku dll"

Możesz zobaczyć dodany zestaw C: \ Windows \ system32 \

Rozwiązuje również brakujące dll lub „Nie można załadować pliku lub zestawu” w zadaniu skryptu SSIS


1
Zwrócę uwagę, że dodawanie rzeczy do GAC jest zwykle złym pomysłem, utrudnia wdrażanie i generalnie jest czymś, od czego wycofuje się nawet Microsoft.
— George Mauer

1

Podobny problem wystąpił w programie Visual Studio 2017 przy użyciu MSTest jako platformy testowej. Otrzymywałem wyjątki System.TypeLoadException podczas uruchamiania niektórych (nie wszystkich) testów jednostkowych, ale te testy jednostkowe były przekazywane po debugowaniu. Ostatecznie wykonałem następujące czynności, które rozwiązały problem:

  1. Otwórz plik Local.testsettings w rozwiązaniu
  2. Przejdź do ustawień „Test jednostkowy”
  3. Usuń zaznaczenie pola wyboru „Użyj kontekstu ładowania dla zestawów w katalogu testowym”. pole wyboru

Po wykonaniu tych czynności wszystkie testy jednostkowe zaczęły przechodzić pomyślnie.


1

Doświadczyłem tego samego, co powyżej po usunięciu podpisywania zestawów w rozwiązaniu. Projekty nie powstały.

Okazało się, że jeden z projektów odwoływał się do pakietu StrongNamer NuGet, który modyfikuje proces kompilacji i próbuje podpisać niepodpisane pakiety Nuget.

Po usunięciu pakietu StrongNamer mogłem ponownie zbudować projekt bez podpisywania / silnego nazewnictwa zestawów.


0

Jeśli jest to aplikacja systemu Windows, spróbuj poszukać duplikatu w Global Assembly Cache (GAC). Coś przesłania Twoją wersję bin / debug.

Jeśli jest to aplikacja internetowa, może być konieczne usunięcie na serwerze i ponowne przesłanie. Jeśli publikujesz, możesz chcieć zaznaczyć pole wyboru Usuń wszystkie istniejące pliki przed publikacją. W zależności od wersji programu Visual Studio powinien znajdować się w pozycji Publikuj> Ustawienia> Opcje publikowania plików Usuń wszystkie istniejące pliki przed opublikowaniem


-2

Właśnie rozwiązałem ten problem, uruchamiając polecenie iisreset za pomocą wiersza poleceń ... Zawsze pierwszą rzeczą, którą robię, gdy otrzymuję takie błędy.


4
Przykro mi, ale to nie ma nic wspólnego z pytaniem, przyjmuje założenia dotyczące używania iis i nie wyjaśnia, co jest przyczyną problemu.
— George Mauer
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.