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

81

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

khawarPK
quelle
Wurde dieses Problem durch das Hochladen einer neuen Version der DLL verursacht?
Nunespascal
Keine Änderung, gleiche alte DLL auf allen Servern, nichts geändert
khawarPK
Dieselbe alte Version von MainCore.DbImpl.dll auf allen Servern, hat nichts hochgeladen oder geändert.
KhawarPK
Versuchen Sie, temporäre ASP.Net-Dateien zu bereinigen / zu löschen, wenn dies das nächste Mal passiert. Zum Bereinigen müssen Sie möglicherweise den IIS neu starten.
Furqan Hameedi
Wie vermeide ich dieses Problem beim nächsten Mal auf diesem Server?
KhawarPK

Antworten:

51

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!

stolzgeekdad
quelle
2
Für mich bedeutet das lokale Ausführen der Lösung, dass der Identitätsknoten vollständig aus web.config entfernt wird. Für die Bereitstellung auf Produktionsservern ist jedoch der Identitätswechsel erforderlich. Daher muss der Identitätsknoten hinzugefügt werden. Siehe meine Antwort hier für weitere Details
bkwdesign
3
Ich habe den imitierenden Benutzer der lokalen Gruppe mit dem Namen IIS_IUSRS hinzugefügt, anstatt zu versuchen, genau herauszufinden, welcher der "verschiedenen Framework-Ordner" verwendet werden soll.
Andreas Jansson
Vergessen Sie nicht, dass der Identitätswechsel über Code (ohne web.config) erfolgen kann. In meinem Fall wurde der Benutzer (anonyme Anmeldung) im Chrome-Browser gespeichert. Musste Chrome neu starten und die Website erneut besuchen, um meine Benutzeranmeldeinformationen einzugeben.
Volodymyr Kotylo
36

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

Fragment
quelle
Diese Antwort zusammen mit der Lösung von Love Chopra hat bei mir funktioniert.
Fall 303
Gute Antwort! Wenn Sie wie ich versuchen, in Azure zu veröffentlichen und denselben Fehler erhalten, gehen Sie zu Ihrer App im Azure-Portal, gehen Sie zu Anwendungseinstellungen und wählen Sie die Option "64-Bit" für die Einstellung "Plattform".
MV23
@ MV23 Warum 64-Bit? Warum hilft das?
nmit026
25

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.

khawarPK
quelle
Gibt es eine Lösung für dasselbe Problem mit der Assembly C1.Web.Wijmo.Controls.4? bekommenCould not load file or assembly 'C1.Web.Wijmo.Controls.4, Version=4.0.20163.250, Culture=neutral, PublicKeyToken=9b75583953471eea' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Prajwal Bhat
@Bhat: Dein ist ein ganz anderes Problem. Vergleichen Sie einfach die Fehlermeldungen.
JensG
22

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:

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.

Yorro
quelle
Das Löschen temporärer ASP.Net-Dateien funktionierte für mich, obwohl der Fehler nur (wiederholt) auf meinen lokalen Bin verwies. Sehr verwirrend.
DudeNumber4
1
Vielen Dank ... Ich kämpfe seit fast zwei Wochen gegen diesen nervigen Fehler. Wenn ich mein Antivirenprogramm (BitDefender Free Antivirus) deaktiviert habe, funktioniert alles wieder einwandfrei.
Alexandre Perez
1
Etwa alle 6 Monate habe ich eine fehlerhafte Entwicklerbereitstellung, die mich zu derselben SO-Antwort zurückschickt - großartige Beschreibung @Yorro!. Obwohl mein Identitätswechselbenutzer tatsächlich Zugriff auf das Verzeichnis Temporäre ASP.NET-Dateien benötigte, schien ich den Fehler erst zu finden, als ich meine Anwendung aus IIS (nicht den zugrunde liegenden Dateien) löschte und die erneut hinzufügte Anwendung zurück in IIS.
bkwdesign
In meinem Fall habe ich festgestellt, dass McAfee den Zugriff für die DLLs meiner .NET-Anwendung blockiert, wie in den Protokollen von McAfee angezeigt. Ich musste in McAfees "Access Protection" gehen und den "Anti-Spyware Maximum Protection" ändern. Entfernen Sie dann die Blockprüfung für das Element "Verhindern, dass alle Programme Dateien aus dem Ordner" Temp "ausführen". Dies kann konfiguriert anstatt deaktiviert werden, was besser ist. Sehen Sie in der AccessProctectionLog.txt nach, ob die Nachrichten blockiert oder gemeldet werden. Der Speicherort des Protokolls befindet sich auf der Registerkarte Berichte.
Paul Syfrett
Ich erhalte eine Fehlermeldung mit IIS Expresss in development environment. Das gleiche Problem mit AppPools .
Kiquenet
5

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.

kad81
quelle
Ich habe nur diese Schritte befolgt, anstatt der komplexeren in der ausgewählten Antwort - und dies allein hat es gelöst.
Veverke
Das hat auch bei mir funktioniert. Ich habe den Prozessmonitor von Sysinternal von Technet verwendet , um den blockierten Ordner zu finden, bei dem es sich um den erwähnten Ordner "Temporäre ASP.NET-Dateien" handelt. In Process Monitor deaktivieren Sie alles außer der Schaltfläche "Dateisystemaktivität" und können dann nach "ZUGRIFF VERWEIGERT" suchen.
Fordy
4

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

Geben Sie hier die Bildbeschreibung ein

Liebe Chopra
quelle
Diese Antwort zusammen mit der Lösung von Fragment hat bei mir funktioniert.
Fall 303
4

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

Naveen Kokcha
quelle
3

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

Yasser Amer
quelle
3

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.

Houdini Sutherland
quelle
Ich musste in McAfees "Access Protection" gehen und den "Anti-Spyware Maximum Protection" ändern. Entfernen Sie dann die Blockprüfung für das Element "Verhindern, dass alle Programme Dateien aus dem Ordner" Temp "ausführen". Dies kann konfiguriert anstatt deaktiviert werden, was besser ist.
Paul Syfrett
3

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

Payman Vali
quelle
Du schöne!! Ersparte mir eine Welt voller Probleme
Murphybro2
2

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

Mr_CSharp
quelle
2

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" />
user2211290
quelle
2

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)

Amjad
quelle
1

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.

MFry
quelle
1
 Go to run  : ctrl + R
 Type : %temp%

Alle Dateien und Ordner löschen

 Rebuild Project.
 done!
Saurin Vala
quelle
1

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.

mike bruner
quelle
1

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.

Van Vangor
quelle
Es kann Ihr Problem behoben haben, aber es erklärt nicht die Ursache
rollt
1

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.

js290
quelle
0

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.

garryp
quelle
0

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.

Erin Gibbs
quelle