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

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

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

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.

Musiałem wyczyścić

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

Dopiero wtedy problem został rozwiązany.

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

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

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

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

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

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

Dzięki

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

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

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

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.

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.

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

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:

3. 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:

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.

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.

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

Możesz wyczyścić, zbudować lub przebudować aplikację lub po prostu usunąć tymczasowe pliki ASP.NET z C: \ Users \ YOUR USERNAME \ AppData \ Local \ Temp

To działa jak magia. W moim przypadku miałem problem z wiązaniem zestawu, mówiąc, że nie można załadować pliku bla bla bla

możesz także zobaczyć rozwiązanie 2 jako http://www.codeproject.com/Articles/663453/Understanding-Clean-Build-and-Rebuild-in-Visual-St

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

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.

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

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

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

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.

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

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

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\

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