Datei oder Assembly konnte nicht geladen werden ... Der Parameter ist falsch

Je nachdem, ob Sie X64 ausführen, müssen Sie möglicherweise einige weitere Stellen bereinigen. Nur mein Benutzerverzeichnis aufzuräumen reichte nicht aus.

1. % TEMP%\Temporäre ASP.NET-Dateien
2. C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporäre ASP.NET-Dateien
3. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporäre ASP.NET-Dateien
4. C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporäre ASP.NET-Dateien
5. C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporäre ASP.NET-Dateien

Diese Liste wird so wachsen, als ob andere Versionen des Frameworks installiert sind.

Ich musste klären 

C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET-Dateien

Erst dann wurde das Problem gelöst.

Um zu wissen, was Sie sicher löschen müssen, fügen Sie den folgenden Registrierungsschlüssel hinzu:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog (DWord set to 1).

Dann sehen Sie die Ausgabe wie unten. Hier erfahren Sie, wo asp.net versucht, Ihre DLLs zu laden. Löschen Sie dieses Verzeichnis.

LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\app\AtlasAdvisor\web\web.config
LOG: Using Host configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based Assembly bind).
LOG: Attempting download of new URL **file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/3c8629f7/dfa387b6/Avanade.ViddlerNet.DLL.**
LOG: Attempting download of new URL **file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/3c8629f7/dfa387b6/Avanade.ViddlerNet/Avanade.ViddlerNet.DLL**.

Löschen Sie die temporären Framework-Dateien für Ihr Projekt in: -

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporäre ASP.NET-Dateien \ 

Sie können auch das Paketverzeichnis löschen und NuGet die fehlenden Pakete erneut herunterladen

es löste das Problem für mich

Löschen Sie alle Dateien aus diesen Ordnern.

C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET-Dateien C: /Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Dateien

Löschen Sie einfach diesen Ordner: (nur Windows x64)

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporäre ASP.NET-Dateien

Es war hilfreich, neue Binärdateien von der Quellcodeverwaltung zu erhalten.

Vielen Dank

Danke Alex, dein zweiter Punkt hat mir geholfen, das zu beheben. 

Es scheint, dass, wenn Sie Visual Studio nicht als Administrator in Windows 7 ausführen, die temporären Dateien lokal gespeichert werden und nicht C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporäre ASP.NET-Dateien. 

Siehe folgenden Blogbeitrag: http://www.dotnetscraps.com/dotnetscraps/post/Location-of-Temporary-ASPNET-files-in-Vista-or-Windows-7.aspx

Ich lösche einfach meine temporären Anwendungsdaten aus diesem Pfad

C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files

Problem lösen

Ich hatte hier das gleiche Problem - oben genannte Lösungen funktionierten nicht. Problem war mit ActionMailer. Ich habe folgende Deinstallations- und Installationsbefehle ausgeführt

uninstall-package ActionMailer
install-package ActionMailer

Meine Probleme gelöst, wird hoffentlich jemand anderem helfen. 

Sie können Ihre Anwendung bereinigen, erstellen oder neu erstellen oder einfach Temporäre ASP.NET-Dateien unter C:\Users\IHR BENUTZERNAME\AppData\Local\Temp löschen

Das funktioniert wie Magie. In meinem Fall hatte ich ein Assembly-Bindungsproblem, in dem stand: Datei konnte nicht geladen werden bla bla bla

sie können Lösung 2 auch als http://www.codeproject.com/Articles/663453/Understanding-Clean-Build-and-Rebuild-in-Visual-St anzeigen.

Wie ich sehe, haben viele Technikfreaks über das Löschen temporärer Verzeichnisse von ASP .Net-Laufzeit zu jedem einzelnen .Net-Framework, das auf Ihrem Computer gehostet ist, wie in this answer, gepostet. Aber ich glaube, wir sollten die klare Logistik wissen, warum wir alle temporären Arbeitsverzeichnisse aller .NET-Frameworks blind löschen müssen. Meiner Meinung nach sollte dies nicht der Fall sein.

Mein Rat wäre, dass Sie einen Pin-Point-Verzeichnis-Clearing-Ansatz ausprobieren sollten, um dieses Problem zu beheben. Woher wissen Sie, welches Verzeichnis gelöscht werden soll?

1. Gehen Sie zu IIS und klicken Sie mit der rechten Maustaste auf Ihren Website-Knoten im linken Navigationsbereich, um das Kontextmenü zu öffnen. Zeigen Sie im Kontextmenü auf Manage Application -> Advanced Settings..., um das Fenster Advanced Settings zu öffnen.
2. Überprüfen Sie den Anwendungspool, dem Ihre Website zugewiesen ist. In meinem Fall ist dies DefaultAppPool wie folgt:

3. Gehen Sie nun in der linken Navigationsleiste des IIS zum Knoten Application Pools. Prüfen Sie nun, welche .Net CLR-Version von Ihrem App-Pool ausgeführt wird. In meinem Fall ist es v4.0 wie unten gezeigt:

Da die CLR-Version, die von meinem App-Pool gehostet wird, v4.0 ist, habe ich genau die temporären Dateien in dem Ordner, der zu ASP .NET v4.0 gehört, nur wie folgt gelöscht:

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

Und das ist es. Mein Problem wurde gelöst. 

Lesson Learned: Dies ist ein Hinweis auf die Tatsache, dass alle temporären Dateien, die von Ihrer Website verwendet werden, nicht auf mehrere Verzeichnisse verteilt sind, sondern gleichzeitig auf Ihren App-Pool verwiesen werden. Sie müssen also nur diesen bestimmten Ordner löschen.

Wenn Sie die Datentools von SQL Server 2012 verwenden, die die VS2010-Shell zum 1. Mai 2013 verwenden, überprüfen Sie Ihre Configuration Manager-Einstellungen. Eine Änderung des Servernamens von Workflow in xCPWorkflow war ausreichend, um genau dasselbe zu erzeugen. Der Parameter ist falsch (Ausnahme von HRESULT: 0x80070057 (E_INVALIDARG)) .

Das Löschen von C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporäre ASP.NET-Dateien hat für mich funktioniert. Denken Sie daran, den Löschvorgang zu automatisieren, um das Problem in Zukunft zu vermeiden. 

Dies kann passieren, wenn auf COM-Wrapper-DLLs verwiesen wird. Wählen Sie in Ihrem Visual Studio-Projekt unter Verweise die COM-Wrapper-DLLs aus, auf die verwiesen wird, und stellen Sie sicher, dass sie die folgenden Eigenschaftswerte aufweisen: "Interop-Typen einbetten": False und "Spezifische Version": False.

In meinem Fall löste das Ändern der IISExpress-Portnummer in meinen Projekteigenschaften das Problem.

Manchmal müssen Sie auch diesen Ordner bereinigen: C:\Windows\Temp\Temporary ASP.NET

In meinem Fall wollte ich eine COM-sichtbare DLL kompilieren. Das Problem war, dass sich eine ältere Version dieses DLL hier befand:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

Daher hat Visual Studio diese Version anstelle der neu kompilierten Version geladen, als versucht wurde, sie zu registrieren.

Löschen Sie alle Dateien aus dem temporären Ordner (C:\Users\Benutzername\AppData\Local\Temp\Temporäre ASP.NET-Dateien\Projektordner). 

Wenn jemand anderes das WiX-Toolset verwendet, stellte ich fest, dass mein Installer-Projekt einen Verweis auf ein altes Projekt hatte, das kürzlich aus der Lösung entfernt wurde. Es dauerte eine Weile, bis mir klar wurde, da es eine Reihe von Projekten in der Lösung gibt, die ich zu bauen versuchte, und die Nachricht nicht anzeigt, welches Projekt nicht erstellt werden konnte (und das Bereinigen, was ebenfalls fehlgeschlagen ist).

Das Problem bezieht sich auf die .NET-Laufzeitversion einer referenzierten Klassenbibliothek (erweiterte Referenzen, wählen Sie die Bibliothek aus und überprüfen Sie die "Laufzeitversion".) Ich hatte ein Problem mit Antlr3.Runtime, nachdem ich mein Visual Studio-Projekt auf Version 4.5 aktualisiert hatte benutzte NuGet zur Deinstallation von Microsoft ASP.NET Web Optimization Framework (aufgrund einer Reihe von Abhängigkeiten, durch die ich Antlr3 nicht direkt deinstallieren konnte)

Ich habe dann NuGet verwendet, um das Microsoft ASP.NET Web Optimization Framework neu zu installieren. Dadurch wurden die korrekten Laufzeitversionen erneut installiert.

Ich hatte Benutzer von Siemens Teamcenter 10 Client für Microsoft Office, die dieselbe Fehlermeldung über eine andere DLL erhalten haben. Keine der anderen Antworten funktionierte. Die Lösung bestand darin, die Ordner in zu löschen

C:\Users\%username%\AppData\Local\Assembly\

Ich habe denselben Fehler festgestellt, weil die Anwendung im C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\-Ordner keine abhängigen Frameworks gefunden hat. Ich repariere gerade mein Visual Studio, das den erforderlichen Rahmen in der obigen Position hinzufügte, und es funktioniert einwandfrei.

Ich hatte dieses Problem, als ich Controller in MVC machte. Ich habe das .NET-Framework der Version geändert. Das Problem wurde gelöst