Nie można załadować pliku lub zestawu lub jednej z jego zależności. Odmowa dostępu. Problem jest losowy, ale po jego jednorazowym wystąpieniu nadal występuje

Znalazłem wiele informacji na temat tego błędu: „BŁĄD: nie można załadować pliku lub zestawu„ * .dll ”lub jednej z jego zależności. Odmowa dostępu. Ale nie znalazłem odpowiedzi specyficznej dla mojego scenariusza. Moja witryna jest wdrażana na 6 różnych serwerach produkcyjnych, tylko na jednym serwerze mam do czynienia z tym problemem. Problem jest losowy, ale po tym, jak zdarzy się raz, trwa do momentu ponownej kompilacji witryny przez dokonanie niewielkiej modyfikacji w pliku web.config (znam sztuczkę, po modyfikacji w web.config ponownie skompiluj aplikację internetową) i uruchom witrynę na tym serwerze pracujący. Wczoraj emisja rozmnażała się po miesięcznym okresie pracy. Nie stać nas na ten problem na produkcji.
Szczegóły problemu:

Błąd serwera w aplikacji „/”. ____________________________________ Nie można załadować pliku lub zestawu „MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null” lub jednej z jego zależności. Odmowa dostępu. Opis: wystąpił nieobsługiwany wyjątek podczas wykonywania bieżącego żądania WWW. Zapoznaj się ze śladami stosu, aby uzyskać więcej informacji o błędzie i miejscu jego powstania w kodzie.

Szczegóły wyjątku: System.IO.FileLoadException: nie można załadować pliku lub zestawu „MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null” lub jednej z jego zależności. Odmowa dostępu.

Błąd źródła: podczas wykonywania bieżącego żądania internetowego został wygenerowany nieobsługiwany wyjątek. Informacje dotyczące pochodzenia i lokalizacji wyjątku można zidentyfikować za pomocą poniższego śladu stosu wyjątków.

Śledzenie ładowania zestawu: Poniższe informacje mogą być pomocne w ustaleniu, dlaczego nie można załadować zestawu „MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null”.

WRN: Rejestrowanie powiązań zestawu jest wyłączone. Aby włączyć rejestrowanie błędów powiązań zestawów, ustaw wartość rejestru [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) na 1. Uwaga: Istnieje pewien spadek wydajności związany z rejestrowaniem niepowodzenia powiązania zespołu. Aby wyłączyć tę funkcję, usuń wartość rejestru [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

Ślad stosu:

[FileLoadException: nie można załadować pliku lub zestawu „MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null” lub jednej z jego zależności. Odmowa dostępu.] ... DbImpl.Event.TTCEventController.GetEventFields (Int32 eventId) +0 WebSuite.SportChannel.ModelImpl.TTCModelController.AddEventFieldList (XmlElement eventNode, ITTCEventController, zdarzenie o nazwie RootController, ITTCEventController ...) \ ModelImpl \ Ttc \ TTCModelController.cs: 171 ... ModelImpl.TTCModelController.GetLatestFourTourSchedulesXml () w ... root \ SportChannel \ ModelImpl \ Ttc \ TTCModelController.cs: 283 ... WebRoot.UserCon.Ptrols.HeadlinesTababs , EventArgs e) +491 System.Web.Util.CalliHelper.EventArgFunctionCaller (IntPtr fp, Object o, Object t, EventArgs e) +25 System.Web.Util.
____________________________________

Informacje o wersji: Microsoft .NET Framework Wersja: 2.0.50727.5446; Wersja ASP.NET: 2.0.50727.5420

W moim scenariuszu stwierdziłem, że w pliku web.config znajdował się węzeł tożsamości.

<identity impersonate="true" userName="blah" password="blah">

Kiedy usunąłem parametry userName i hasło z węzła, zaczęło działać.

Inną opcją może być upewnienie się, że określona nazwa użytkownika ma dostęp do pracy z folderami „Tymczasowe pliki ASP.NET” znajdującymi się w różnych folderach C: \ Windows \ Microsoft.NET \ Framework {wersja}.

Mam nadzieję, że pomoże to komuś innemu!

Miał ten sam problem, naprawiony przez ustawienie parametru „Włącz aplikacje 32-bitowe” na „prawda” (w ustawieniach zaawansowanych puli aplikacji iis).

Moje rozwiązanie jest następujące:

Nie znalazłem folderu głównego wC:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files .

Google powiedział mi, że może to być problem z uprawnieniami dla obecnego użytkownika, a następnie znalazłem aktualną tożsamość: IIS APPPOOLna źle działającym serwerze, na którym reszta serwera ma bieżącą tożsamość:NT AUTHORITY\NETWORK SERVICE .

Następnie zmieniłem bieżącą tożsamość z IIS APPPOOLna NT AUTHORITY\NETWORK SERVICE.

Stąd odkryłem, że zresetowanie aplikacji internetowej odbudowuje tymczasową pamięć podręczną ASP.NET, rozwiązując problem.

Dla każdego, kto wypróbował większość rozwiązań i nadal ma problemy.

Moje rozwiązanie różni się od innych, które znajdują się na dole tego postu, ale zanim spróbujesz, upewnij się, że wyczerpałeś poniższe listy. Oczywiście wypróbowałem je wszystkie, ale bezskutecznie.

1. Ponownie skompiluj i wdróż od podstaw, nie aktualizuj istniejącej aplikacji. TAK Odpowiedź

2. Przyznaj IIS_IUSRS pełny dostęp do katalogu „C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files”

   Pamiętaj o używanej wersji frameworka. Jeśli Twoja aplikacja używa personifikacji, użyj tej tożsamości zamiast IIS_IUSRS

3. Usuń całą zawartość katalogu „C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files” .

   Pamiętaj o używanej wersji frameworka

4. Zmień tożsamość puli aplikacji, której używa aplikacja, z ApplicatonPoolIdentity na NetworkService.

   IIS> Pule aplikacji> Wybierz bieżącą pulę aplikacji> Ustawienia zaawansowane> Tożsamość.

   Odpowiedź SO (przywróć ustawienia domyślne, jeśli nie działa)

5. Sprawdź zgodność wersji IIS i wersji AppPool .NET ze swoją aplikacją. Szerokie zastosowanie do wdrożeń po raz pierwszy. TAK Odpowiedź

6. W razie potrzeby sprawdź konfigurację personifikacji. TAK Odpowiedź

Moje rozwiązanie:

Dowiedziałem się, że niektóre programy antywirusowe aktywnie blokują kompilacje bibliotek DLL w katalogu „Temporary ASP.NET Files” , moim był McAfee, informatykom nie udało się powiadomić mnie o instalacji.

Zgodnie z radą ekspertów firmy McAfee i firmy Microsoft należy wykluczyć katalog „Temporary ASP.NET Files” podczas skanowania w czasie rzeczywistym.

Źródła:

• Forum pomocy McAfee
• Pomoc techniczna firmy Microsoft
• Forum Asp.Net

Nie wyłączaj antywirusa, ponieważ wykonuje on tylko swoje zadanie. Nie kopiuj ręcznie brakujących plików DLL w katalogu \ Temporary ASP.NET Files {nazwa projektu}, ponieważ to jest nagrywanie kanałów.

Jeśli używasz personifikacji, upewnij się, że nadałeś uprawnienia, w tym uprawnienia do zapisu i modyfikowania, odpowiedniemu kontu użytkownika w następującym folderze:

C:\Users\[username]\AppData\Local\Temp\Temporary ASP.NET Files

Brakowało mi uprawnienia do modyfikacji, dlatego samo dodanie domyślnych uprawnień nie działało.

Jeśli nadal masz problem, spróbuj tego:

Otwórz Menedżera usług IIS -> Pule aplikacji -> wybierz pulę aplikacji -> Ustawienia zaawansowane -> W obszarze „Model procesu” ustaw „Załaduj profil użytkownika” na wartość Prawda

Wydaje mi się, że zmarnowałem jeden dzień na badanie tego i to, z czym wyszedłem.

Musisz dodać użytkownika personifikującego do folderu debugowania rozwiązania, ponieważ platforma będzie próbowała uzyskać dostęp do biblioteki DLL z tej lokalizacji i umieścić ją w tymczasowym folderze Asp.Net.

Więc zasadniczo wykonaj te 2 kroki

1. Przyznaj uprawnienia do folderu tymczasowego Asp.Net w obszarze C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Filesi upewnij się, że dodawany tutaj użytkownik jest tym samym użytkownikiem, którego używasz podczas personifikacji.

2. Dodaj użytkownika personifikującego do folderu Debug swojego rozwiązania YourSolutionPath .. \ bin \ Debug

To powinno działać

Przejdź do IIS -> Pula aplikacji -> Ustawienia zaawansowane -> Włącz aplikacje 32-bitowe

Miałem ten sam problem, naprawiony przez przebudowę i ponowne wdrożenie WSZYSTKICH plików Dependents Dll

W moim przypadku było to spowodowane funkcją Access Protection mojego programu antywirusowego (McAfee). To oczywiście blokowało dostęp do tego pliku, jako taki błąd.

Wyłączyłem go i rozwiązanie działało. Możesz chcieć sprawdzić każdą uruchomioną aplikację narzędziową, która może mieć wpływ na dostęp do niektórych plików.

Sprawdź ustawienia usług IIS. Używam IIS 7.5 z kompilacją 32- lub 64-bitową w środowisku .NET. Jeśli masz aplikację, która korzysta z trybu 32-bitowego, upewnij się, że pula aplikacji umożliwia korzystanie z instrukcji 32-bitowych. W przeciwnym razie wydaje się, że nic nie działa, niezależnie od tego, ile ustawisz zabezpieczeń lub silnego znaku biblioteki DLL.

Konfiguruję środowisko na nowym serwerze. Mój web.config dostał węzeł tożsamości, jak poniżej. Kiedy pojawiło się pytanie „Nie można załadować pliku lub zestawu lub jednej z jego zależności. Odmowa dostępu.

Dodano ccs \ HJKWeb jako listę użytkowników mojego nowego serwera.

  <authentication mode="Windows" />
        <identity impersonate="true" password="******" userName="ccs\HJKWeb" />

Dla mnie następujący hack zadziałał; Przejdź do IIS -> Pule aplikacji -> Ustawienia zaawansowane -> Model procesu -> Tożsamość zmieniona z konta wbudowanego (ApplicationPoolIdentity) na konto niestandardowe (użytkownik mojej domeny)

W moim przypadku nie użyłem podszywania się. Moim rozwiązaniem było zapewnienie pełnego dostępu do katalogu mojego projektu grupie użytkowników „IIS_IUSRS”.

 Go to run  : ctrl + R
 Type : %temp%

usuń wszystkie pliki i foldery

 Rebuild Project.
 done!

Natknąłem się na ten problem i okazało się, że wspomniany pakiet / zestaw był szyfrowany przez system Windows. Stało się tak, ponieważ moja firma wdrożyła zasadę wymagającą zaszyfrowania folderu Moje dokumenty, a moje rozwiązania Visual Studio znajdowały się w tym katalogu.

Mogłem ręcznie wejść do właściwości pliku / katalogu w Eksploratorze Windows i wyłączyć szyfrowanie. Ale w moim przypadku było to rozwiązanie tymczasowe, ponieważ polityka sieciowa ostatecznie ją zmieniła. Skończyło się na przeniesieniu mojego rozwiązania VS do innej niezaszyfrowanej lokalizacji.

W moim przypadku skopiowałem usługę z jednego serwera na inny bez wykonywania odpowiedniego wdrożenia z Visual Studio. Długa historia.

W każdym razie skonfigurowałem wszystkie odpowiednie uprawnienia NTFS i tak dalej, ale nadal nie mogłem załadować głównej biblioteki DLL dla usługi.

Naprawiłem to, zmieniając nazwę odpowiedniego pliku service.pdb na coś innego.

Na przykład oto mój folder bin: \bin\ service.dll service.dll.config service.pdb Zmieniłem nazwę service.pdb na zzservice.pdb, a następnie service.dll został poprawnie załadowany.

Jeśli nie można znaleźć biblioteki DLL zamiast odmowy dostępu, upewnij się, że masz zainstalowany odpowiedni pakiet redystrybucyjny VC ++.

Otrzymałem ten błąd podczas uruchamiania z VS. Okazało się, że otworzyłem rozwiązanie bez uruchamiania programu Visual Studio jako administrator. Zamknięcie programu Visual Studio i ponowne uruchomienie go jako administrator, a następnie przebudowa rozwiązało ten problem.

Mam nadzieję, że to komuś pomoże.

W moim przypadku użyłem prostej personifikacji, a użytkownik podszywający się pod inne osoby miał problem z dostępem do jednego z zestawów projektu. Moje rozwiązanie:

1. Poszukaj komunikatu wewnętrznego wyjątku, aby zidentyfikować problematyczny zestaw.

2. Zmodyfikuj właściwości zabezpieczeń pliku zespołu.

   a) Dodaj konto użytkownika, którego używasz do personifikacji, do nazwy grupy i użytkownika.

   b) Daj temu kontu użytkownika pełny dostęp do pliku zestawu.