Datei oder Assembly oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Der Zugriff wird verweigert. Das Problem ist zufällig, aber nachdem es einmal aufgetreten ist, wird es fortgesetzt

Ich habe viele Informationen zu diesem Fehler gefunden: 'FEHLER: Datei oder Assembly' * .dll 'oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Der Zugriff wird verweigert. ' Aber ich habe keine spezifische Antwort für mein Szenario gefunden. Meine Site wird auf 6 verschiedenen Produktionsservern bereitgestellt, nur auf einem Server, auf dem dieses Problem auftritt. Das Problem ist zufällig, aber nachdem es einmal aufgetreten ist, wird es fortgesetzt, bis die Site neu kompiliert wird, indem eine kleine Änderung in der Datei web.config vorgenommen wird (ich weiß, Trick, nach der Änderung in web.config die Webanwendung neu kompilieren) und die Site auf diesem Server gestartet wird Arbeiten. Gestern wurde das Problem nach einem Monat Arbeitszeit reproduziert. Wir können uns dieses Problem bei der Produktion nicht leisten.
Problemdetail:

Serverfehler in '/' Anwendung. ____________________________________ Datei oder Assembly 'MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Der Zugriff wird verweigert. Beschreibung: Während der Ausführung der aktuellen Webanforderung ist eine nicht behandelte Ausnahme aufgetreten. Bitte überprüfen Sie die Stapelverfolgung, um weitere Informationen über den Fehler und dessen Ursprung im Code zu erhalten.

Ausnahmedetails: System.IO.FileLoadException: Datei oder Assembly 'MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Der Zugriff wird verweigert.

Quellfehler: Während der Ausführung der aktuellen Webanforderung wurde eine nicht behandelte Ausnahme generiert. Informationen zum Ursprung und Ort der Ausnahme können mithilfe der folgenden Ausnahmestapelverfolgung identifiziert werden.

Assembly Load Trace: Die folgenden Informationen können hilfreich sein, um festzustellen, warum die Assembly 'MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null' nicht geladen werden konnte.

WRN: Die Protokollierung der Baugruppenbindung ist deaktiviert. Setzen Sie den Registrierungswert [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) auf 1, um die Protokollierung von Assemblybindungsfehlern zu aktivieren. Hinweis: Mit der Protokollierung von Assemblybindungsfehlern ist ein Leistungsverlust verbunden. Entfernen Sie den Registrierungswert [HKLM \ Software \ Microsoft \ Fusion! EnableLog], um diese Funktion zu deaktivieren.

Stapelverfolgung:

[FileLoadException: Datei oder Assembly 'MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Der Zugriff wird verweigert.] ... DbImpl.Event.TTCEventController.GetEventFields (Int32 eventId) +0 WebSuite.SportChannel.ModelImpl.TTCModelController.AddEventFieldList (XmlElement eventNode, ITTCEventController cTl) \ ModelImpl \ Ttc \ TTCModelController.cs: 171 ... ModelImpl.TTCModelController.GetLatestFourTourSchedulesXml () in ... root \ SportChannel \ ModelImpl \ Ttc \ TTCModelController.cs: 283 ... WebRoot.UserCtrol , EventArgs e) +491 System.Web.Util.CalliHelper.EventArgFunctionCaller (IntPtr fp, Objekt o, Objekt t, EventArgs e) +25 System.Web.Util.
____________________________________

Versionsinformationen: Microsoft .NET Framework Version: 2.0.50727.5446; ASP.NET-Version: 2.0.50727.5420

In meinem Szenario stellte ich fest, dass in der Datei web.config ein Identitätsknoten vorhanden war.

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

Als ich die Parameter userName und password vom Knoten entfernte, funktionierte es.

Eine andere Option könnte sein, dass Sie sicherstellen müssen, dass der angegebene Benutzername Zugriff auf die Ordner "Temporäre ASP.NET-Dateien" hat, die sich in den verschiedenen Ordnern C: \ Windows \ Microsoft.NET \ Framework {version} befinden.

Ich hoffe, das hilft jemand anderem!

Das gleiche Problem wurde behoben, indem der Parameter "32-Bit-Anwendungen aktivieren" auf "true" gesetzt wurde (in den erweiterten Einstellungen des iis-Anwendungspools).

Meine Lösung lautet wie folgt:

Ich habe nicht finden root - Ordner unter C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files.

Google hat mir mitgeteilt, dass es sich möglicherweise um ein Berechtigungsproblem für den aktuellen Benutzer handelt. Dann habe ich festgestellt, dass ich eine aktuelle Identität habe: IIS APPPOOLauf dem fehlerhaften Server, auf dem der Rest des Servers die aktuelle Identität hat : NT AUTHORITY\NETWORK SERVICE.

Dann habe ich die aktuelle Identität von IIS APPPOOLauf geändert NT AUTHORITY\NETWORK SERVICE.

Von hier aus stellte ich fest, dass durch das Zurücksetzen der Webanwendung der temporäre ASP.NET-Cache neu erstellt und das Problem behoben wird.

An alle anderen, die die meisten Lösungen ausprobiert haben und immer noch Probleme haben.

Meine Lösung unterscheidet sich von den anderen, die sich am Ende dieses Beitrags befindet. Bevor Sie es jedoch versuchen, stellen Sie sicher, dass Sie die folgenden Listen erschöpft haben. Natürlich habe ich alle ausprobiert, aber ohne Erfolg.

1. Neu kompilieren und von Grund auf neu bereitstellen. Aktualisieren Sie die vorhandene App nicht. SO Antwort

2. Gewähren Sie IIS_IUSRS vollen Zugriff auf das Verzeichnis "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporäre ASP.NET-Dateien".

   Beachten Sie die von Ihnen verwendete Framework-Version. Wenn Ihre App einen Identitätswechsel verwendet, verwenden Sie diese Identität anstelle von IIS_IUSRS

3. Löschen Sie den gesamten Inhalt des Verzeichnisses "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporäre ASP.NET-Dateien" .

   Beachten Sie die von Ihnen verwendete Framework-Version

4. Ändern Sie die Identität des AppPool, den Ihre App verwendet, von ApplicatonPoolIdentity in NetworkService.

   IIS> Anwendungspools> Aktuellen App-Pool auswählen> Erweiterte Einstellungen> Identität.

   SO Antwort (bitte auf Standard zurücksetzen, wenn es nicht funktioniert)

5. Überprüfen Sie die Kompatibilität von IIS-Version und AppPool .NET-Version mit Ihrer App. Sehr gut geeignet für erstmalige Bereitstellungen. SO Antwort

6. Überprüfen Sie gegebenenfalls die Konfiguration des Identitätswechsels. SO Antwort

Meine Lösung:

Ich fand heraus, dass bestimmte Antivirensoftware die Kompilierung von DLLs im Verzeichnis "Temporäre ASP.NET-Dateien" aktiv blockieren. Meine war McAfee. Die IT-Mitarbeiter haben mich nicht über die Installation informiert.

Gemäß den Empfehlungen von McAfee-Experten und Microsoft müssen Sie das Verzeichnis "Temporäre ASP.NET-Dateien" beim Echtzeit-Scannen ausschließen.

Quellen:

• McAfee Support Forum
• Microsoft-Support
• Asp.Net Forum

Deaktivieren Sie den Anti-Virus nicht, da er nur seine Aufgabe erfüllt. Kopieren Sie fehlende DLL-Dateien nicht manuell in das Verzeichnis \ Temporäre ASP.NET-Dateien {Projektname}, da dies Kanalband ist.

Wenn Sie den Identitätswechsel verwenden, müssen Sie dem entsprechenden Benutzerkonto im folgenden Ordner Berechtigungen erteilen, einschließlich Schreib- und Änderungsberechtigungen :

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

Mir fehlte die Änderungsberechtigung, weshalb das Hinzufügen der Standardberechtigungen für mich nicht funktionierte.

Wenn Sie immer noch mit dem Problem konfrontiert sind, versuchen Sie Folgendes:

Öffnen Sie Ihren IIS-Manager -> Anwendungspools -> wählen Sie Ihren App-Pool aus -> Erweiterte Einstellungen -> Setzen Sie unter 'Prozessmodell' die Einstellung 'Benutzerprofil laden' auf True

Ich glaube, ich habe 1 Tag damit verbracht, es zu erforschen, und das, was ich herausgebracht habe.

Sie müssen den imitierenden Benutzer zum Debug-Ordner Ihrer Lösung hinzufügen, da das Framework versucht, von diesem Speicherort aus auf die DLL zuzugreifen und sie im temporären Asp.Net-Ordner abzulegen.

Befolgen Sie also grundsätzlich diese 2 Schritte

1. Geben Sie dem temporären Asp.Net-Ordner unter C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Filesdie Berechtigung und stellen Sie sicher, dass der Benutzer, den Sie hier hinzufügen, derselbe ist, den Sie beim Identitätswechsel verwenden.

2. Fügen Sie den Benutzer Identitätswechsel zum Debug-Ordner Ihrer Lösung YourSolutionPath .. \ bin \ Debug hinzu

Das sollte funktionieren

Ich hatte das gleiche Problem, das durch das Neuerstellen und erneute Bereitstellen von ALL Dependents Dll-Dateien behoben wurde

In meinem Fall lag dies an der Zugriffsschutzfunktion meines Antivirenprogramms (McAfee). Es blockierte offensichtlich den Zugriff auf diese Datei, als solcher Fehler.

Ich habe es deaktiviert und die Lösung lief. Möglicherweise möchten Sie alle Dienstprogramme überprüfen, die möglicherweise ausgeführt werden und die den Zugriff auf einige Dateien beeinträchtigen könnten.

Gehen Sie zu IIS -> Anwendungspool -> Erweiterte Einstellungen -> 32-Bit-Anwendungen aktivieren

Überprüfen Sie die IIS-Einstellungen. Ich verwende IIS 7.5 mit 32- oder 64-Bit-Kompilierung innerhalb des .NET Frameworks. Wenn Sie eine App haben, die den 32-Bit-Modus verwendet, stellen Sie sicher, dass der App-Pool 32-Bit-Anweisungen verwenden kann. Ansonsten scheint nichts zu funktionieren, egal wie stark Sie die Sicherheit einstellen oder die DLL stark signieren.

Ich richte die Umgebung auf einem neuen Server ein. Meine web.config hat einen Identitätsknoten wie unten. Wenn ich mit "Datei oder Assembly oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Zugriff verweigert. Das Problem ist zufällig, aber nachdem es einmal passiert ist, wird es fortgesetzt."

Ccs \ HJKWeb als Benutzerliste meines neuen Servers hinzugefügt.

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

Für mich hat der folgende Hack funktioniert; Gehen Sie zu IIS -> Anwendungspools -> Erweiterte Einstellungen -> Prozessmodell -> Identität geändert von integriertem Konto (ApplicationPoolIdentity) zu benutzerdefiniertem Konto (Mein Domänenbenutzer)

Ich habe in meinem Fall keinen Identitätswechsel verwendet. Meine Lösung bestand darin, der Benutzergruppe "IIS_IUSRS" vollen Zugriff auf mein Projektverzeichnis zu gewähren.

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

Alle Dateien und Ordner löschen

 Rebuild Project.
 done!

Ich bin auf dieses Problem gestoßen und es stellte sich heraus, dass ein Paket / eine Assembly, auf die verwiesen wird, von Windows verschlüsselt wurde. Dies geschah, weil mein Unternehmen eine Richtlinie implementiert hat, nach der der Ordner "Eigene Dateien" verschlüsselt werden muss und sich meine Visual Studio-Lösungen zufällig in diesem Verzeichnis befinden.

Ich könnte manuell in die Datei- / Verzeichniseigenschaften im Windows Explorer gehen und die Verschlüsselung deaktivieren. In meinem Fall war dies jedoch eine vorübergehende Lösung, da die Netzwerkrichtlinie sie schließlich wieder ändern würde. Ich habe meine VS-Lösung an einen anderen unverschlüsselten Ort verschoben.

In meinem Fall hatte ich einen Dienst von einem Server auf einen anderen kopiert, ohne eine ordnungsgemäße Bereitstellung von Visual Studio durchzuführen. Lange Geschichte.

Wie auch immer, ich hatte alle entsprechenden NTFS-Berechtigungen eingerichtet und so weiter, aber die Haupt-DLL für den Dienst konnte immer noch nicht geladen werden.

Ich habe das Problem behoben, indem ich die entsprechende Datei service.pdb in etwas anderes umbenannt habe.

Hier ist zum Beispiel mein bin-Ordner: \bin\ service.dll service.dll.config service.pdb Ich habe service.pdb in zzservice.pdb umbenannt und dann die service.dll gut geladen.

Wenn Sie feststellen, dass die DLL nicht gefunden wurde, anstatt den Zugriff zu verweigern, stellen Sie sicher, dass Sie die entsprechende VC ++ Redistributable installiert haben.

Ich habe diesen Fehler von VS ausgeführt. Es stellte sich heraus, dass ich eine Lösung geöffnet hatte, ohne Visual Studio als Administrator auszuführen. Das Schließen von Visual Studio und das erneute Ausführen als Administrator und das anschließende Wiederherstellen haben dies für mich gelöst.

Hoffe das hilft jemandem.

In meinem Fall verwendete ich einen einfachen Identitätswechsel, und der Identitätswechselbenutzer hatte Probleme beim Zugriff auf eine der Projektbaugruppen. Meine Lösung:

1. Suchen Sie nach der Meldung der inneren Ausnahme, um die problematische Baugruppe zu identifizieren.

2. Ändern Sie die Sicherheitseigenschaften der Assemblydatei.

   a) Fügen Sie der Gruppe und den Benutzernamen das Benutzerkonto hinzu, das Sie für den Identitätswechsel verwenden.

   b) Geben Sie diesem Benutzerkonto vollen Zugriff auf die Assembly-Datei.