Erstellungsfehler: "Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird."

Ich habe eine C # webforms-App, die bis heute nur schwimmend funktioniert hat.

Heute erhalte ich plötzlich jedes Mal, wenn ich versuche, die App auszuführen, einen Fehler beim Sperren von Dateien:

Datei "obj \ Debug \ MyProject.exe" kann nicht nach "bin \ Debug \ MyProject.exe" kopiert werden. Der Prozess kann nicht auf die Datei "bin \ Debug \ MyProject.exe" zugreifen, da sie von einem anderen Prozess verwendet wird.

Wenn Sie den Fehler googeln, wird nichts anderes als das Offensichtliche angezeigt, dh VS glaubt, dass die Datei gesperrt ist. Und es ist definitiv Visual Studio selbst, das die Datei sperrt, denn wenn ich VS schließe und wieder öffne, wird das Projekt beim ersten Mal einwandfrei ausgeführt. Wenn ich versuche, es ein zweites Mal auszuführen, wird der Fehler beim Sperren der Datei angezeigt.

Das Schließen von VS und das erneute Öffnen jedes Mal, wenn ich die App ausführen möchte, ist keine praktikable Problemumgehung! Wie finde ich heraus, was die Datei sperrt, und verhindere, dass sie gesperrt wird?

EDIT: Eine weitere interessante Entdeckung: Ich muss die App nicht einmal ausführen. Wenn Sie es nur einmal kompilieren, wird die Datei gesperrt. Ich kann nicht zweimal hintereinander kompilieren!

Dieses Problem ist spezifisch für ein Projekt in meiner Lösung. Alle anderen Projekte funktionieren einwandfrei und können so oft ausgeführt werden, wie ich möchte. Es ist nur dieses eine Projekt, das sich selbst einsperrt.

Ich habe eine einfache Lösung gefunden, die für mich funktioniert. Es geht so:

Wenn das Problem auftritt, ändern Sie einfach die Gebäudekonfiguration oben (wenn in „Release“ in „Debug“ und umgekehrt), erstellen Sie und wechseln Sie dann zurück zur vorherigen Konfiguration und erstellen Sie erneut.

Ich nehme an, dass das Ändern der Konfiguration den vcshost und den devenv freigibt.

Nun, ich habe das Problem selbst gelöst - obwohl ich immer noch keine Ahnung habe, warum. Ich beschloss, das Problem zu isolieren, indem ich alle Dateien aus dem Projekt entfernte, sie dann erneut hinzufügte und auf diese Weise feststellte, welche Datei die Ursache meiner Probleme war. Also habe ich nacheinander Dateien wieder in das Projekt eingeführt, jeden Schritt des Weges kompiliert und bereinigt ... bis ... ich den letzten hinzugefügt habe ...

... und alles hat noch gut funktioniert.

Ich habe einen Vergleich mit der Quellcodeverwaltung meiner ursprünglichen .csproj durchgeführt. Keine wirklichen Unterschiede. Und selbst als ich versuchte, zur vorherigen Version von .csproj zurückzukehren, funktionierte es immer noch.

Schwarze Magie. Wenn es funktioniert, ist es manchmal besser, nicht zu fragen, warum - akzeptieren Sie es einfach und fahren Sie fort ...

BEARBEITEN: Das Problem ist ein wiederkehrendes Problem, und ich glaube, ich habe es isoliert, wenn der Formular-Designer zur Kompilierungszeit ein abstraktes / generisches Formular geöffnet hat.

Lektion gelernt: Stellen Sie sicher, dass der Formular-Designer aller abstrakten oder generischen Formulare oder Steuerelemente geschlossen ist, bevor Sie kompilieren! Wenn nicht, müssen Sie VS schließen und erneut öffnen!

Was wir hier entdeckt haben, ist Folgendes: Deaktivieren Sie auf der Seite "Projekteigenschaften" auf der Registerkarte "Debuggen" das Kontrollkästchen "Visual Studio-Hosting-Prozess aktivieren". Ich bin mir nicht sicher, wofür diese Eigenschaft gedacht ist, aber sie erledigt die Arbeit, sobald sie deaktiviert ist.

Eigentlich sollten Sie "Visual Studio-Hosting-Prozess aktivieren" aktivieren. Zumindest für VS2010. Und ich habe auch:

falls vorhanden "$ (TargetPath) .locked" del "$ (TargetPath) .locked" falls vorhanden "$ (TargetPath)" falls nicht vorhanden "$ (TargetPath) .locked" move "$ (TargetPath)" "$ (TargetPath) .gesperrt"

in den Pre-Build-Optionen. Dieses Problem hat mich sehr lange verfolgt und erst als John W. dieses Kontrollkästchen erwähnte, bemerkte ich sogar, dass es existierte und niedrig war und siehe, es war bereits deaktiviert.

Beachten Sie auch, dass -app-vshost.exe im Hintergrund ausgeführt wird, auch wenn kein Debugging durchgeführt wird. Aus diesem Grund wird es jedes Mal erfolgreich erstellt und ausgeführt, wenn ich denke. Es lief vorher nicht. Außerdem habe ich versucht, die Debug- und Release-Ordner zu bereinigen und den Zieltyp ständig zu ändern, und nichts hat funktioniert, außer wie oben beschrieben. Meine vorherige Lösung bestand darin, zwischen den Builds nur 5 Minuten zu warten, was sehr nervig und zeitaufwändig wurde, um etwas zu erledigen. Ich habe keine Verhaltensänderung gesehen, bei der es darauf ankam, welche Registerkarten geöffnet waren oder XNA gegenüber Windows Forms oder Designern, die geöffnet wurden. Dieses Problem trat bei 32-Bit- oder 64-Bit-Builds auf und spielte keine Rolle, ob ich eine App mit ALT-F4 oder mit dem Task-Manager beendet habe, wodurch die App theoretisch keine Ressourcen schließen oder freigeben konnte. Zuerst dachte ich, es sei ein Problem mit der Speicherbereinigung.

VS2017 - Wird behoben, indem alle Instanzen von MSBuild.exe im Windows-Task-Manager geschlossen werden

Etwas spät zu beantworten, aber ich löse dieses Problem, indem ich zu den Eigenschaften des Projekts gehe> Registerkarte "Debuggen"> Deaktivieren Sie "Visual Studio-Hosting-Prozess aktivieren".

Ich habe dieses Problem durch Umbenennen der gesperrten Datei (mit Windows Explorer) behoben. Ich durfte die Datei nicht löschen, aber das Umbenennen der gesperrten Datei funktioniert!

Ich habe dieses Problem gelöst, indem ich den Ordner bin \ Debug gelöscht und möglicherweise VS neu gestartet habe

Für mich war es ein Windows-Dienst, der installiert wurde und ausgeführt wurde. Nachdem ich es gestoppt hatte, war der Build erfolgreich.

Führen Sie diesen Befehl im Feld Ausführen aus:

net stop iisadmin /y

und dann

iisreset

arbeitete für mich. vs 2003

Ich bin kürzlich auf dieses Problem gestoßen, als ich versucht habe, eine Lösung zu erstellen, an der ich arbeite (nicht nur ein Winforms-Projekt).
Zusätzlich zum buildFehler bemerkte ich, dass Reinigungsprojekte stillschweigend fehlschlugen (das Überprüfen des bin-Ordners ergab, dass die Dateien nicht tatsächlich gelöscht wurden) und das Schließen von Visual Studio das nicht beendetedevenv Prozess nicht beendete, sondern zum Absturz führte. Der Windows-Wiederherstellungsprozess startet dann Visual Studio neu.

Nach einigem Ausprobieren stellte ich fest, dass die Probleme nur bei mir auftraten, als ich die Lösung beim Starten von VS über das Menü "Zuletzt verwendet" öffnete.
Wenn Sie die Lösung von File >> Open >> Project/Solutionöffnen, funktioniert sie wie gewohnt.

Derzeit keine Ahnung warum - werde mich weiter damit befassen, aber im Moment kann ich zumindest arbeiten!

Überprüfen Sie einfach die Referenzen und entfernen Sie die Selbstreferenz zum Projekt.

Erläuterung: Mein Problem begann nach dem Erstellen eines benutzerdefinierten Steuerelements und dem Ziehen und Ablegen in die Toolbox-Palette, um es in Entwurfsformularen zu verwenden. Zuerst erschien eine Warnung, dass zwischen der Quelldatei des benutzerdefinierten Steuerelements (.cs) und der ausführbaren Projektdatei (.exe) eine Redundanz bestand. Beim Ausführen / Debuggen trat der Fehler auf: Zugriff auf die (.exe) nicht möglich, da sie verwendet wird (und es war wahr).

Ich habe buchstäblich den gesamten Quellcode bezüglich des benutzerdefinierten Steuerelements entfernt und das Problem blieb weiterhin bestehen, bis ich die Referenzen überprüft habe und es sich selbst referenzierte, um das frühere benutzerdefinierte Steuerelement "erhalten" zu können. Ich habe die Referenz entfernt und fertig !!

Ich hatte das gleiche Problem mit meiner Xamarin-Anwendung in Visual Studio und es wurde behoben, indem ich mein Test-Mobilgerät aussteckte. Die Anwendung wurde geschlossen und der Debugger gestoppt, aber der Fehler trat immer noch auf, wenn versucht wurde, die Lösung zu erstellen oder neu zu erstellen. Es hörte erst auf, nachdem ich das Gerät ausgesteckt hatte, weil ich einen Anruf erhalten musste.

Nur um meine 2 Cent hineinzuwerfen. Mein Problem wurde gelöst, indem der Task-Manager geöffnet und die Anwendung beendet wurde. Es wurde im Hintergrund ausgeführt, ohne dass darauf hingewiesen wurde, dass es überhaupt ausgeführt wurde (kein Element in der Taskleiste, keine Benutzeroberfläche, nichts), aber ich bin mir nicht sicher, warum dies passiert ist. Offensichtlich lief der Debugger nicht und ich hatte zu diesem Zeitpunkt nur eine einzige Instanz von VS geöffnet. Es wundert mich, dass dies in diesem VS 2017 immer noch passiert.

Vielleicht kann ich einen Build-Schritt hinzufügen, der nach der Anwendung sucht, auf der der Hintergrund ausgeführt wird, und sie beendet, bevor die neue gestartet wird.

Ich hatte das gleiche Problem und konnte es mit keiner der in den vorherigen Antworten genannten Methoden beheben. Ich habe das Problem behoben, indem ich alle Instanzen von "SSIS Debug Hist (32 Bit)" im Task-Manager beendet habe und jetzt wie gewohnt arbeite.

Wie ist Ihre Web-App konfiguriert? Läuft es unter Cassini (dem Tray-Webserver) oder IIS?

Dies sollte jedoch nicht normal geschehen. Ich denke, ProcessExplorer kann Ihnen sagen, welche Dateien ein Prozess gesperrt hat. Wenn nicht, verarbeiten Sie Explorer eines der anderen sysinternalen Tools.

Bevor Sie eines der SI-Tools herunterladen, sollten Sie versuchen, den Cassini-Webserver zu stoppen und zu prüfen, ob dadurch die Datei freigegeben wird.

Was für mich funktioniert hat, war der Neustart von IIS

Ich hatte das gleiche Problem auch. Das Ändern der Debug- / Release-Konfiguration hat nicht funktioniert. Zumindest nicht ohne dazwischen zu bauen.

In meiner Lösung (Winform) wurde es gelöst, indem die Hauptform der Winform im Designer geöffnet wurde. Umschalten auf Code (F7). Schließen Sie dann den Code, schließen Sie den Designer der Winform und erstellen Sie alle neu (Strg-Umschalt-B). Das hat bei mir funktioniert.

Es scheint, als hätte eine Art Handle aus der Winform-App (auf der ein Hintergrundarbeiter ausgeführt wird) noch ein Datei-Handle für einige der anderen verwendeten Bibliotheken.

Ich hatte zwei Instanzen von Visual Studio die gleiche Lösung geöffnet.

In meinem Fall wurden einige vstest-Prozesse ausgeführt (mit verschiedenen Namen, die jedoch alle die Zeichenfolge vstest enthalten). Ich musste sie in taskmgr beenden.

Gleicher Fehler, behoben durch Aktualisierung der Google Nuget-Support-Pakete

Als ich den Prozess beendet habe .Net Core Host, hat sich alles gut entwickelt. Ich musste Visual Studio nicht schließen oder etwas anderes ändern.

Starten Sie für diejenigen, die in VS mit Docker entwickeln, den Docker für Windows-Dienst neu, und das Problem wird sofort behoben.

Vor dem Neustart von Docker habe ich alle genannten Antworten ausprobiert, keinen laufenden msbuild.exe-Prozess gefunden und auch versucht, VS ohne Erfolg neu zu starten. Nur das Neustarten von Docker hat funktioniert.

Eine weitere Lösung: Wenn die Dateien gesperrt werden, wird ein Blockierungsprozess gemeldet (z. B. "ServiceHub.Host.CLR.x64 (7764)"), dessen ID in Klammern steht. Um den Prozess zu beenden, öffnen Sie PowerShell (x + Win + I) und geben Sie Folgendes ein: "Stop-Process -Id idNumber".

Ich bin kürzlich auf das Problem bei der Bereitstellung in Service Fabric gestoßen. Der Fehler impliziert, dass eine 'Datei' verwendet wird. Ich habe jedoch festgestellt, dass der Port von einer anderen IDE verwendet wurde. Durch das Stoppen eines laufenden Dienstes, der bereits auf dem Port gehostet wurde, konnte ich das Auftreten dieser Ausnahme verhindern.

Ich hatte das gleiche Problem. Ich habe mehrere der oben aufgeführten Lösungen ausprobiert, aber sie haben bei mir nicht funktioniert.

Ich habe dieses Problem gelöst, indem ich die Verbindung über den Server-Explorer geschlossen und alle in Visual Studio geöffneten Registerkarten geschlossen habe.

Wenn dies ein SSIS-Projekt ist, öffnen Sie den Task-Manager und beenden Sie alle Instanzen von DtsDebugHost.exe, die die gesperrten Dateien freigeben sollen.

Ich verwende Visual Studio Code und habe diesen Fehler erhalten, weil der Dev-Server ausgeführt wurde (ich habe den Dev-Server durch Drücken von ausgeführt Ctrl + F5).

Daher habe ich einfach auf das Stoppschild geklickt, um es zu stoppen, und der Fehler ist verschwunden.

Ich hatte dieses Problem (und es ist ein Problem, das ich an anderen Orten gesehen habe, nicht nur bei VS).

Es wird von Dropbox verursacht (in meinem Fall). Nach dem Bearbeiten von Code und dem Ausführen von "Ausführen" sperrt Dropbox die Datei manchmal sofort (damit sie verarbeitet werden kann).

Lösung 1. Drücken Sie einfach erneut auf Ausführen

Lösung 2. Dropbox anhalten. (nicht gut, wenn Sie Dropbox als Cloud-Backup verwenden)

Lösung 3. Entfernen Sie den Build-Ordner aus der Dropbox-Synchronisierungsliste.

Das Löschen des Obj-, Retail- und Debug-Ordners des .NET-Projekts und das erneute Erstellen funktionierten für mich.