Nie można załadować pliku lub zestawu… Parametr jest niepoprawny

211

Ostatnio spotkałem następujący wyjątek w rozwiązaniu C #:

Błąd 2 Nie można załadować pliku lub zestawu „Newtonsoft.Json, Wersja = 3.5.0.0, Kultura = neutralny, PublicKeyToken = b9a188c8922137c6” lub jednej z jego zależności. Parametr jest niepoprawny. (Wyjątek od HRESULT: 0x80070057 (E_INVALIDARG))

Nie zależy to ani od mojego kodu, ani od nazwy zestawu (jak Newtonsoft.Jsonw tym przypadku).

Kiedy usuwam tę bibliotekę DLL z rozwiązania, kompilator informuje o innym w tym samym wyjątku. Przypuszczam więc, że coś powinno być wyłączone / włączone na moim komputerze :)

Liker777
źródło
3
Nie. Może to być błąd kompilatora lub wyjątek czasu wykonywania. Podejrzewam to drugie. Proszę wyjaśnić.
leppie
2
Zetknąłem się również z tym samym wyjątkiem, ale udało mi się to naprawić za pomocą rozwiązania Thomasa. Problem był spowodowany niewłaściwym zamknięciem systemu z powodu awarii zasilania
Sandeep

Odpowiedzi:

346

Wygląda na odwołanie do uszkodzonego zestawu.

Oba czyste:

  1. folder \ bin twojego projektu

  2. folder temp (powinien znajdować się C:\Users\your_username\AppData\Local\Temp\Temporary ASP.NET Filesw systemie Windows 7)

i sprawdź, czy błąd nadal występuje

Alex
źródło
3
alex bardzo za to dziękuję! druga rzecz pomogła: wyczyściłem tymczasowy katalog plików ASP.NEt)
Liker777,
Cieszę się, że to działa. pamiętaj, aby zaakceptować odpowiedź, jeśli pomogła :)
Alex
9
zobacz odpowiedź @Thomas dla innych lokalizacji do usunięcia (co zadziałało dla mnie)
Simon_Weaver,
3
Dzięki. Wyczyszczenie folderu temp użytkownika po awarii spowodowało dla mnie problem.
Petrus Theron,
13
% TEMP% \ Tymczasowe pliki ASP.NET C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Tymczasowe pliki ASP.NET C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Tymczasowe pliki ASP.NET C : \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Tymczasowe pliki ASP.NET C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Tymczasowe pliki ASP.NET C: /Windows/Microsoft.NET/Framework/ v4.0.30319 / Temporary ASP.NET Files Ta lista powiększy się, jakbyś miał inne wersje .NetFramework. Odpowiedź Src: stackoverflow.com/a/16033324/1724777 stackoverflow.com/a/11743430/1724777 Powód probu: BLUE_SCREEN_OF_DEATH
NavaRajan
286

W zależności od tego, czy używasz X64, może być konieczne wyczyszczenie kilku dodatkowych miejsc. Samo oczyszczenie mojego katalogu użytkownika nie wystarczyło.

  1. % TEMP% \ Tymczasowe pliki ASP.NET
  2. C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Tymczasowe pliki ASP.NET
  3. C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Tymczasowe pliki ASP.NET
  4. C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Tymczasowe pliki ASP.NET
  5. C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Tymczasowe pliki ASP.NET

Ta lista będzie rosła, jakbyś miał zainstalowane inne wersje frameworka.

Tomasz
źródło
72
może się okazać, że musisz to zrobić, jeśli komputer ma
niebieski ekran
2
+1 Ładnie skompilowany dodatek do odpowiedzi. Naprawiłem to, dziękuję
Ralph Lavelle,
7
Wygląda to na rozwiązanie, jeśli uruchamiasz program Visual Studio jako administrator, gdy komputer ulega awarii lub, jeśli jesteś tak samo głupkowaty jak ja, gdy bateria się wyczerpie.
Zapisz
4
O MÓJ BOŻE! Dostałem ponad 4 GB z moich prehistorycznych projektów w tych miejscach! Czy ta rzecz nigdy nie posprząta?!?! Dzięki!
user2173353,
2
Chciałem tylko poinformować, że od ponad 2 lat ten post nadal pomaga ludziom. Dziękuję bardzo.
Laurence Frost
42

Musiałem wyczyścić

C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files

Dopiero wtedy problem został rozwiązany.

Sachin Kainth
źródło
1
Ta odpowiedź zadziałała również dla mnie, w 64-bitowej maszynie Win 7 obsługującej MVC 4 w IIS Express
Ben H
13

Aby wiedzieć, co należy wyczyścić, na pewno - dodaj następujący klucz rejestru:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog (DWord set to 1).

Następnie zobaczysz wynik jak poniżej. To powie ci, gdzie asp.net próbuje załadować twoje biblioteki DLL. Wyczyść ten katalog.

LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\app\AtlasAdvisor\web\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL **file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/3c8629f7/dfa387b6/Avanade.ViddlerNet.DLL.**
LOG: Attempting download of new URL **file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/3c8629f7/dfa387b6/Avanade.ViddlerNet/Avanade.ViddlerNet.DLL**.
voidsstr
źródło
3
No i zresetowanie usług IIS było konieczne, aby zobaczyć ścieżki.
Landon Poch
Gdzie wyświetla się ten dziennik?
Luke Rice
Dziennik pojawia się na wyjściu błędu, gdy wystąpi wyjątek
voidsstr
12

Wyczyść tymczasowe pliki ram dla swojego projektu w: -

C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Tymczasowe pliki ASP.NET \

andy
źródło
5

Możesz także wyczyścić katalog pakietów i pozwolić NuGet na ponowne pobranie brakujących pakietów

rozwiązało to dla mnie problem

megz
źródło
... i ja, chociaż właśnie usunąłem niepoprawny katalog pakietu.
Phil Cooper
Usunąłem szablony w AppData temp & c: \ ... \ micorosoft.net \ .. \ temp, iisreset, ... wszystko wyżej. ale ze mną nie działa. Po usunięciu wszystkich pakietów i przywróceniu ... to działa ze mną ... wielkie dzięki: D
bunjeeb
@ bunjeeb to przyjemność koleś :)
megz
4

Usuń wszystkie pliki z tych folderów.

C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files C: /Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files

Rakin
źródło
3

Pomogło uzyskanie nowego zestawu plików binarnych z kontroli źródła.

Dzięki

Jak gdyby
źródło
3

Po prostu wyczyść ten folder: (tylko Windows x64)

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Tymczasowe pliki ASP.NET

pixparker
źródło
2

Dzięki Alex twój drugi punkt pomógł mi to naprawić.

Wygląda na to, że jeśli nie uruchomisz programu Visual Studio jako administrator w systemie Windows 7, pliki tymczasowe będą przechowywane lokalnie, a nie C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files.

Zobacz następujący post na blogu: http://www.dotnetscraps.com/dotnetscraps/post/Location-of-Temporary-ASPNET-files-in-Vista-or-Windows-7.aspx

Mrówka
źródło
2

Miałem tutaj ten sam problem - powyższe rozwiązania nie działały. Problem dotyczył ActionMailer. Uruchomiłem następujące polecenia deinstalacji i instalacji nuget

uninstall-package ActionMailer
install-package ActionMailer

Mam nadzieję, że rozwiążę moje problemy.

LiamB
źródło
2

Może się to zdarzyć podczas odwoływania się do bibliotek otoki COM. W projekcie Visual Studio Project w obszarze Odwołania wybierz dll otoki COM, do którego się odwołujesz, i upewnij się, że mają one następujące wartości właściwości: „Osadzanie typów interakcji”: Fałsz i „Określona wersja”: Fałsz.

Nemo
źródło
To świetna odpowiedź i powinna uzyskać więcej pozytywnych opinii. Wszystkie pozostałe odpowiedzi przyjmują za pewnik kontekst ASP.NET. Jednak miałem ten sam wyjątek podniesiony przez wywołanie COM w prostej aplikacji konsoli; to działało idealnie dla mnie. Dziękuję Panu.
alexlomba87
2

Właśnie usuwam dane tymczasowe aplikacji z tej ścieżki

C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files

Problem rozwiązany

atik sarker
źródło
2

Widzę, że wielu techników napisało o czyszczeniu tymczasowych katalogów środowiska ASP .Net w czasie wykonywania dotyczących każdego środowiska .Net hostowanego na twoim komputerze, jak w tym odpowiedzi. Uważam jednak, że powinniśmy znać przejrzystą logistykę, dlaczego musimy ślepo usuwać wszystkie tymczasowe katalogi robocze wszystkich platform .Net. Według mnie tak nie powinno być.

Moja rada jest taka, że ​​powinieneś wypróbować podejście polegające na czyszczeniu katalogów, aby rozwiązać ten problem. Skąd wiesz, który katalog wyczyścić?

  1. Przejdź do IIS i kliknij prawym przyciskiem myszy węzeł witryny w lewym okienku nawigacji, aby otworzyć menu kontekstowe. W menu kontekstowym wskaż Manage Application->, Advanced Settings...aby otworzyćAdvanced Settings okno.
  2. Sprawdź pulę aplikacji, do której przypisana jest witryna. W moim przypadku jest DefaultAppPooltak, jak pokazano poniżej:

wprowadź opis zdjęcia tutaj

  1. Teraz przejdź do Application Poolswęzła na lewym pasku nawigacji w IIS. Teraz sprawdź, która wersja .Net CLR jest uruchamiana przez twoją pulę aplikacji. W moim przypadku jest to wersja 4.0, jak pokazano poniżej:

wprowadź opis zdjęcia tutaj

Ponieważ wersja CLR obsługiwana przez moją pulę aplikacji to v4.0, więc dokładnie wyczyściłem tylko pliki tymczasowe w folderze dotyczące ASP .NET v4.0 tylko jak poniżej:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files

I to wszystko. Mój problem został rozwiązany.

Wyciągnięta lekcja : wskazuje to na fakt, że wszystkie pliki tymczasowe używane przez twoją witrynę nie są rozproszone w kilku katalogach, ale są od razu kierowane przez pulę aplikacji. Musisz więc wyczyścić tylko ten konkretny folder.

RBT
źródło
1

Czyszczenie C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Tymczasowe pliki ASP.NET działały dla mnie. Myślisz o zautomatyzowaniu procesu usuwania, aby uniknąć problemu w przyszłości.

Stephen ebichondo
źródło
1

Jeśli używasz narzędzi danych programu SQL Server 2012, które korzystają z powłoki VS2010 na dzień 1 maja 2013 r., Sprawdź ustawienia programu Menedżer konfiguracji. Wystąpiła zmiana nazwy serwera z Workflow na xCPWorkflow, aby uzyskać dokładnie to samo . Parametr jest niepoprawny (wyjątek od HRESULT: 0x80070057 (E_INVALIDARG)) .

SAINCA
źródło
1

Miałem ten problem podczas tworzenia kontrolera w MVC. Zmieniłem wersję .NET Framework. Problem został rozwiązany

Hossein Hajizadeh
źródło
0

Problem dotyczy wersji środowiska uruchomieniowego .Net biblioteki klas, do której się odwołuje (odniesienia rozszerzone, wybierz bibliotekę i zaznacz „Wersja środowiska wykonawczego”. Miałem problem z Antlr3.Runtime, po uaktualnieniu mojego projektu Visual Studio do wersji 4.5. użyłem NuGet do odinstalowania Microsoft ASP.NET Web Optimization Framework (z powodu łańcucha zależności, które uniemożliwiły mi bezpośrednie odinstalowanie Antlr3)

Następnie użyłem NuGet, aby ponownie zainstalować program Microsoft ASP.NET Web Optimization Framework. Spowodowało to ponowne zainstalowanie prawidłowych wersji środowiska wykonawczego.

Dave Russell
źródło
0

W moim przypadku chciałem skompilować widoczną bibliotekę DLL COM. Problem polegał na tym, że starsza wersja tej biblioteki DLL znajdowała się tutaj:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

W ten sposób program Visual Studio załadował tę wersję zamiast nowo skompilowanej, próbując ją zarejestrować.

manekin
źródło
0

Wyczyść wszystkie pliki z folderu tymczasowego (C: \ Users \ nazwa_użytkownika \ AppData \ Local \ Temp \ Temporary ASP.NET Files \ folder projektu)

Kaushal
źródło
0

Czasami również musisz wyczyścić ten folder: C: \ Windows \ Temp \ Temporary ASP.NET

Eriendel
źródło
0

Napotkałem ten sam błąd, ponieważ aplikacja nie znalazła zależnych ram w C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\folderze. Właśnie naprawiam moje Visual Studio, które dodało wymaganą platformę w powyższej lokalizacji i działa dobrze.

Vijay Kumbhoje
źródło
0

W moim przypadku zmiana numeru portu IISExpress we właściwościach mojego projektu rozwiązała problem.

h3n
źródło
0

Jeśli ktoś jeszcze korzysta z zestawu narzędzi WiX, odkryłem, że mój projekt instalatora zawierał odniesienie do starego projektu, który został niedawno usunięty z rozwiązania. Zajęło mi to trochę czasu, ponieważ uświadomiłem sobie, że w rozwiązaniu, które próbowałem zbudować, jest wiele projektów, a komunikat nie wskazuje, który projekt nie został skompilowany (i wyczyścił, a także zawiódł).

zardzewiały
źródło
0

Miałem użytkowników Siemens Teamcenter 10 Client dla Microsoft Office otrzymujących ten sam błąd dotyczący innej biblioteki DLL. Żadna z pozostałych odpowiedzi nie zadziałała. Rozwiązaniem było usunięcie folderów z

C:\Users\%username%\AppData\Local\assembly\
Caleb Mauer
źródło
0

Miałem podobny problem podczas otwierania menedżera pakietów Nuget, usunąłem wszystkie pliki tymczasowe i skompilowałem projekt, działało dobrze.

Shreya Singh
źródło