it-swarm.com.de

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

Ich erhalte diesen Fehler beim Versuch, mein MVC4-Projekt auszuführen, es funktionierte bis zum letzten Mal auf meinen anderen Computern. Wenn ich jedoch versuche, es von einem anderen Computer aus auszuführen, gibt es diesen Fehler:

Datei oder Assembly 'Antlr3.Runtime (1)' oder einer ihrer .__-Dateien konnte nicht geladen werden. Abhängigkeiten. Die Manifestdefinition der gefundenen Assembly lautet nicht passen Sie die Assembly-Referenz an. (Ausnahme von HRESULT: 0x80131040)

Nachdem ich über dieses hier gelesen habe, habe ich versucht, do :

Installationspaket Antlr3.Runtime -Pre

aber es hat nicht geholfen, irgendwelche ideen?

76
Maven

Beim Experimentieren mit der kostenlosen Protokollierungsplattform Nlog ist das gleiche Problem aufgetreten.

Das hat mir geholfen:

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

Danach habe ich beim Starten meines MVC5-Projekts in Visual Studio keine Fehlermeldung erhalten.

94
AH.

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

  • Geben Sie im Datei-Explorer% TEMP% ein und löschen Sie alle temporären Dateien.
  • Gehen Sie zum Ordner "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporäre ASP.NET-Dateien" und löschen Sie alle Dateien.
39
sachin kulkarni

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

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

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

21
fhilton

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

17
YeeHaw1234

Wenn eine Lösung Ihr Problem löst, überprüfen Sie die Version von Assembly web.config

<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>
10
Daniel Melo

Der einfache Weg ist Update Antlr und Webgrease

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

Zum Schluss wurde der Fehler behoben

6
dee pan

Durch das Entfernen dieses Knotens in der Datei web.config wurde die Fehlernachricht für mich entfernt:

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

Was für mich wirklich gut funktionierte, war, vollen Zugriff (auf den in impersonate angegebenen Benutzernamen) auf den Ordner "Temporäre ASP.NET-Dateien" in C:\Windows\Microsoft.NET\Framework {version} (oder Framework64) zu gewähren.

Die Identität wird möglicherweise auch in den Einstellungen des Website-Anwendungspools in IIS gespeichert. 

Stellen Sie sicher, dass Ihr Nuget-Paket mit der richtigen Version korrekt installiert ist. Wenn nichts anderes funktioniert, fügen Sie einfach den Verweis aus einem lokalen Ordner hinzu und setzen Sie ihn auf Copy Local.

6
live-love

Für mich war dies auf einen Konflikt zwischen der Debug- und der Laufzeitversion von Antlr zurückzuführen. 

Schließlich wurde es gelöst, indem ein anderes Antlr-Paket installiert wurde: Install-Package Antlr

2
edson-

Versuchen Sie, die Antlr3.Runtime.dll zu entsperren, wenn Sie manuell einen Verweis hinzufügen: enter image description here

2
ADM-IT

Es gab ein Problem mit dem Identitätswechsel = "true" in web.config. Ich habe die Zeile entfernt, in der es funktioniert !!

Wieder legte ich die Leitung auf und erteilte dem Kontenbenutzer die Berechtigung admin, meine ganze Anwendung funktionierte :)

Wenn Sie Identitätswechsel verwenden. Die Antwort besteht darin, dem Benutzer die Berechtigung zu geben, dass Sie sich als nachahmender 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 Standortverzeichnis.

möglicherweise müssen Sie 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 für die Erlaubnis des imitierten Benutzers, die temporären Daten speichern und die DLL-Dateien sowie alle erforderlichen Dateien aus den Verzeichnissen ziehen zu können

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

Wir werden beide Schritte ausführen, aber anstelle von 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, den nachahmenden Zugriff auf den folgenden Ordner vorzunehmen: C:\Users\[UserName]\AppData\Local\Temp\Temporary ASP.NET Files

1

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 den richtigen Pfad nicht finden.

0
Martin

% Temp% gelöscht

Gelöscht bin

Gelöschte .vs

Nun arbeitete ich für mich

0
Arun Prasad E S

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

Mein Problem wurde letztendlich durch eine Änderung der zugeordneten Laufwerke in unseren Gruppenrichtlinien verursacht. In meiner Lösung ist die Einstellung tempDirectory in der Web.config festgelegt, um ein RAM - Laufwerk setup als Z: -Laufwerk zu verwenden. Anscheinend haben sie angefangen, das Z: -Laufwerk zu verwenden, und die DLLs wurden wie üblich in tempDirectory kopiert, aber ich glaube, sie wurden von einem Prozess auf dem Remote-Server gelöscht (wahrscheinlich Virenscan). Ich konnte das nur herausfinden, indem ich Process Monitor verwendete und nach Antlr filterte und feststellte, dass in einem Netzwerk nach DLLs gesucht wurde.

0
Schmalls

Nach dem Versuch, die .netframework-Temp-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 Die Website wird ohne Fehler angezeigt . Als Nächstes habe ich erneut auf targetFramework = "4.6.1" geändert und den Server ..__ neu gestartet. Alles bleibt in Ordnung.

0
Laurent DANE

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.

0
Tomas Kubes

Ich habe all packages im Nuget Package Manager aktualisiert und es hat funktioniert! In meinem Fall hoste ich meine Website in GoDaddy

0
joalcego

Für mich war die Lösung Tools> NuGet Package Manager> Pakete für Lösung verwalten

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

  1. Das Startup-Projekt
  2. Alle Bibliotheken, die Reflektion verwenden
  3. Alle Bibliotheken, die die Bibliotheken aufrufen, die Reflektion verwenden

In meinem Fall waren das 4 Projekte, die es brauchten. Nachdem dies erledigt war, wurde dieses Problem endgültig gelöst.

0
Chris Moschini

Ich habe mich gerade mit diesem Problem konfrontiert und die oben genannten Lösungen ausprobiert, aber im Moment hat nichts geklappt Ich musste die dll von bin floder löschen und neu erstellen und dann alle released-Dateien aus dem Paketordner löschen und die Pakete mithilfe der Package Manager Console wiederherstellen

0
Ikram Shah

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

Also löschte ich alle/bin-Verzeichnisse in allen Projekten aus meiner Lösung, bereinigte und baute die Lösung neu auf und es funktionierte endlich!

Mein ganzer Morgen war vergeudet, um das Problem herauszufinden ...

0
Velociround

was für mich funktionierte, bestand darin, die Identität = true aus meinem webconfig (unter den Eigenschaften von system.web) zu entfernen, die Lösung erneut zu erstellen und erneut zu veröffentlichen (falls erforderlich) und es funktionierte wie ein Zauber! 

0
Anchit