Datei oder Assembly 'Antlr3.Runtime (1)' oder eine ihrer Abhängigkeiten konnte nicht geladen werden

Ich erhalte diesen Fehler beim Versuch, mein MVC4Projekt auszuführen . Es hat bis zum letzten Mal auf meinen anderen Computern einwandfrei funktioniert. Wenn ich jedoch versuche, es von einem anderen Computer aus auszuführen, wird der folgende Fehler angezeigt:

Datei oder Assembly 'Antlr3.Runtime (1)' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040)

Nach der Lektüre über das hier habe ich zu versucht zu tun :

Install-Package Antlr3.Runtime -Pre

aber es hat nicht geholfen, irgendwelche Ideen?

Beim Experimentieren mit der kostenlosen Nlog-Protokollierungsplattform trat das gleiche Problem auf.

Das hat mir geholfen:

Geben Sie% TEMP% in den Datei-Explorer ein und löschen Sie alle temporären Dateien.

Danach habe ich beim Starten meines MVC5-Projekts in Visual Studio keinen Fehler mehr erhalten.

Versuchen Sie, die temporären Dateien für ASP.Net zu löschen, indem Sie einen der folgenden Schritte ausführen:

• Geben Sie% TEMP% in den Datei-Explorer ein und löschen Sie alle temporären Dateien.
• Wechseln Sie in den Ordner "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporäre ASP.NET-Dateien" und löschen Sie alle Dateien.

Vergessen Sie nicht, auch die temporären ASP.NET-Dateien in zu löschen Framework64. Das hat den Trick für mich getan.

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

Nur für den Fall, dass dies jemandem hilft.
Ich hatte dieses Problem mit einer MVC 5-Anwendung. Durch Löschen von Antlr3.Runtime.dll aus dem bin- Verzeichnis und erneutes Erstellen wurde das Problem behoben.

Mein Problem war, dass die neueste Version von WebGrease die Version 3.4.1.9004 von Antlr installiert. Nachdem ich WebGrease installiert und Antlr auf Version 3.5.0.2 aktualisiert hatte, verschwand der Fehler.

Wenn Lösungen Ihr Problem lösen, überprüfen Sie die web.config, die Version der Assembly

<dependentAssembly>
        <assemblyIdentity name="Antlr3.Runtime" publicKeyToken="eb42632606e9261f" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.5.0.2" newVersion="3.5.0.2" />
      </dependentAssembly>

Durch Entfernen dieses Knotens in der Datei web.config wurde die Fehlermeldung entfernt:

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

Was für mich jedoch wirklich funktioniert hat, war die Gewährung des vollständigen Zugriffs (auf den im Identitätswechsel angegebenen Benutzernamen) auf den Ordner "Temporäre ASP.NET-Dateien" in C: \ Windows \ Microsoft.NET \ Framework {version} (oder Framework64).

Die Identität kann auch in den Einstellungen des Website-Anwendungspools in IIS gespeichert werden.

Stellen Sie sicher, dass Ihr Nuget-Paket korrekt mit der richtigen Version installiert ist. Wenn nichts anderes funktioniert, fügen Sie einfach die Referenz aus einem lokalen Ordner erneut hinzu und setzen Sie sie auf Lokal kopieren.

Der einfachste Weg ist das Aktualisieren von Antlr und Webgrease

1. Gehe zu Paketkonsolenmanager
2. Versuchen Sie dann, diese Codes einzeln anzuwenden
3. PM> Update-Paket Antlr
4. PM> Update-Paket WebGrease

Endlich der Fehler behoben

Für mich wurde dies durch eine Nichtübereinstimmung zwischen der Debug- und der Laufzeitversion von Antlr verursacht.

Schließlich wurde es durch die Installation eines anderen Antlr-Pakets gelöst: Install-Package Antlr

Versuchen Sie, die Datei Antlr3.Runtime.dll zu entsperren, wenn Sie die Referenz manuell hinzufügen:

Es gab ein Problem mit impersonate = "true" in web.config, ich habe die Zeile entfernt, die funktioniert hat !!

Wieder platzierte ich die Zeile und gab dem Administrator die Erlaubnis, Benutzer mit Identitätswechsel zu konto, meine gesamte Anwendung funktionierte :)

Wenn Sie Identitätswechsel verwenden. Die Antwort besteht darin, dem Benutzer die Erlaubnis zu erteilen, dass Sie sich als Zugriff auf die folgenden Ordner ausgeben:

1. C:\Windows\Microsoft.NET\Framework[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files

2. Ihr Site-Verzeichnis.

Außerdem müssen Sie möglicherweise einen Ordner wie folgt erstellen:

C:\Windows\Microsoft.NET\Framework\[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files\[Application-Name-Goes-Here]

Aber versuchen Sie es zuerst, es hat bei mir funktioniert.

Diese beiden Änderungen zum Erteilen der imitierten Benutzerberechtigung, um die temporären Daten speichern und die DLL-Dateien sowie alle erforderlichen Dateien aus den Verzeichnissen abrufen zu können

Update für Windows 10 Dies ist die Lösung, die für mich funktioniert hat

Wir werden beide Schritte machen, aber stattdessen C:\Windows\Microsoft.NET\Framework[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files

Schreiben Sie% TEMP% in den Datei-Explorer und erteilen Sie dem Benutzer die Berechtigung, sich als Zugriff auf den folgenden Ordner auszugeben: C:\Users\[UserName]\AppData\Local\Temp\Temporary ASP.NET Files

In einem Projekt hatte ich einen Verweis auf WebGrease, aber es gab kein entsprechendes Element in packages.config. Ich entferne die Referenz aus dem Projekt, weil ich sie nicht mehr brauche. Es funktioniert jetzt.

Ich habe alle Antworten in diesem Beitrag ausprobiert, aber keine davon hat für mich funktioniert.

Also habe ich alle / bin-Verzeichnisse in allen Projekten aus meiner Lösung gelöscht, die Lösung bereinigt und neu erstellt und es hat endlich funktioniert!

Mein ganzer Morgen war damit verschwendet, das Problem herauszufinden ...

Was für mich funktionierte, war das Entfernen der Identität = true aus meiner Webkonfiguration (unter den Eigenschaften system.web) und das erneute Erstellen der Lösung und das erneute Veröffentlichen (falls erforderlich). Es funktionierte wie ein Zauber!

Mein Problem wurde durch eine Änderung der zugeordneten Laufwerke in unserer Gruppenrichtlinie verursacht. In meiner Lösung ist die Einstellung tempDirectory in der Datei Web.config festgelegt, um ein RAM-Laufwerks- Setup als mein Z: -Laufwerk zu verwenden. Anscheinend haben sie angefangen, das Laufwerk Z: zu verwenden, und die DLLs wurden wie gewohnt in tempDirectory kopiert, aber dann wurden sie wahrscheinlich von einem Prozess auf dem Remote-Server gelöscht (Virenscan wahrscheinlich). Ich konnte dies nur herausfinden, indem ich Process Monitor verwendete und nach Antlr filterte und feststellte, dass an einem Netzwerkstandort nach den DLLs gesucht wurde.

Ich habe alle Pakete im Nudget Package Manager aktualisiert und es hat funktioniert! In meinem Fall hoste ich meine Website in GoDaddy

Nachdem ich versucht hatte, die temporäre .netframework-Datei ohne Erfolg zu löschen, habe ich mich geändert

<system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.6.1" />
    <httpRuntime />
    <pages controlRenderingCompatibilityVersion="4.0" />
</system.web> 

Mit nur targetFramework = "4.6" anstelle von 4.6.1 wird die Website fehlerfrei angezeigt. Als nächstes habe ich wieder zu targetFramework = "4.6.1" gewechselt und den Server neu gestartet. Alles bleibt in Ordnung.

Für mich bestand die Lösung darin, Visual Studio als Administrator auszuführen. Es war anscheinend ein Berechtigungsproblem.

Die Lösung für mich bestand darin, Tools> NuGet Package Manager> Pakete für Lösung verwalten zu wählen

Klicken Sie dann auf Antlr3 und stellen Sie sicher, dass es installiert wurde in:

1. Das Startprojekt
2. Alle Bibliotheken, die Reflection verwenden
3. Alle Bibliotheken, die die Bibliotheken aufrufen, die Reflection verwenden

In meinem Fall waren das 4 Projekte, die es brauchten. Sobald dies erledigt war, wurde dieses Problem endgültig behoben.

Ich war gerade mit diesem Problem konfrontiert und habe die oben genannten Lösungen ausprobiert, aber im Moment hat nichts funktioniert. Ich musste die DLL aus dem Bin Floder löschen und neu erstellen und dann alle neu veröffentlichten Dateien aus dem Paketordner löschen und die Pakete mithilfe der Paketmanagerkonsole wiederherstellen

% Temp% gelöscht

Bin gelöscht

.Vs gelöscht

Jetzt hat für mich gearbeitet

In meinem Fall hat Visual Studio 2019 beim Klonen eines Projekts ein Leerzeichen durch '% 20' im Projektpfad ersetzt. Als VS dann versuchte, die Nugget-Pakete zu finden, konnte es nicht den richtigen Pfad finden.

Ich habe dieses Problem nach dem Upgrade festgestellt Microsoft.AspNet.Web.Optimization

update-package WebGreaseund update-package Antlr(in dieser Reihenfolge), um die neuesten Versionen zu erhalten und das Problem mit der Antlr-Version zu beheben.

Für mich habe ich vor , und es ist für mich gearbeitet:

1) Ich löschte binund objOrdner (einige Dateien nicht durch gelöscht CleanProjekt)

2) Ich habe einige Dateien wie JS , die vor langer Zeit gelöscht wurden , aber sie wurde in Projektdateien enthält . Also schließe ich sie aus.

Ich habe eine einfache Lösung. Gehen Sie zu Ihrem eigenen Projektordner und suchen Sie einen Paketordner.