it-swarm.com.de

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 gearbeitet hat.

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

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 er von einem anderen Prozess verwendet wird.

Beim Googeln des Fehlers wird nichts weiter als offensichtlich, d. H. VS denkt, dass die Datei gesperrt ist. Und es ist definitiv Visual Studio selbst, das die Datei sperrt, denn wenn ich VS schließe und es wieder öffne, wird das Projekt beim ersten Mal einwandfrei ausgeführt. Wenn ich versuche, es ein zweites Mal auszuführen, erhalte ich den Dateisperrfehler.

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

EDIT: Eine weitere interessante Entdeckung: Ich muss die App nicht einmal ausführen. Wenn Sie 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 gut und können beliebig oft ausgeführt werden. Nur dieses eine Projekt wird selbst eingesperrt. 

72
Shaul Behr

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 wieder hinzufügte und auf diese Weise herausfand, welche Datei die Ursache meines Problems war. Nach und nach führte ich Dateien wieder in das Projekt ein, kompilierte und bereinigte jeden Schritt des Weges ... bis ... ich den letzten hinzugefügt habe ...

... und alles hat noch gut funktioniert.

Ich habe einen Vergleich mit der Quellcodeverwaltung meines ursprünglichen .csproj vorgenommen; keine wirklichen Unterschiede Und selbst wenn ich versucht habe, auf die vorherige Version von .csproj zurückzugreifen, hat es trotzdem funktioniert.

Schwarze Magie. Wenn es funktioniert, ist es manchmal besser, nicht nach dem Grund zu fragen - akzeptieren Sie es einfach und machen Sie weiter ...

EDIT: Das Problem ist ein wiederkehrendes Problem, und ich glaube, ich habe es isoliert, wenn ich den Formulardesigner zur Kompilierzeit mit einem abstrakten/generischen Formular geöffnet habe. 

Gelernte Lektion: Stellen Sie sicher, dass der Formulardesigner von abstrakten oder generischen Formularen oder Steuerelementen geschlossen ist, bevor Sie kompilieren! Wenn nicht, müssen Sie VS schließen und erneut öffnen!

24
Shaul Behr

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 (bei „Release“ in „Debug“ und umgekehrt), erstellen Sie die vorherige Konfiguration und ändern Sie sie dann erneut.

screenshot

Ich nehme an, dass durch das Ändern der Konfiguration vcshost und devenv freigegeben werden.

105
Yechiel B.D.

Was wir hier entdeckt haben, ist folgendes: Deaktivieren Sie auf der Registerkarte "Debug" der Projekteigenschaften die Option "Visual Studio-Hosting-Prozess aktivieren". Ich bin nicht sicher, wofür diese Eigenschaft bestimmt ist, aber sie erledigt die Arbeit, sobald sie nicht aktiviert ist.

16
Yechiel B.D.

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

wenn vorhanden "$ (TargetPath) .locked" del "$ (TargetPath) .locked" Wenn vorhanden "$ (TargetPath)" falls nicht vorhanden "$ (TargetPath) .locked" bewegen "$ (TargetPath)" "$ (TargetPath) .locked "

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

Beachten Sie auch, dass -app-vshost.exe im Hintergrund ausgeführt wird, auch wenn Sie nicht debuggen. Das ist der Grund, warum es jedes Mal, wenn ich schätze, erfolgreich gebaut und ausgeführt wird. Es lief vorher nicht. Ich habe auch versucht, die Debug- und Release-Ordner zu bereinigen und den Zieltyp ständig zu ändern. Nichts hat funktioniert, außer wie oben beschrieben. Meine bisherige Lösung bestand darin, nur 5 Minuten zwischen den Builds zu warten, was sehr ärgerlich und zeitaufwendig wurde, um etwas zu erledigen. Ich habe keine Änderung im Verhalten festgestellt, bei der es darauf ankam, welche Registerkarten geöffnet waren oder XNA oder Windows-Formulare oder Designer geöffnet wurden. Dieses Problem trat in 32-Bit- oder 64-Bit-Builds auf und spielte keine Rolle, wenn ich eine App mit ALT-F4 oder mit dem Task-Manager tötete, was theoretisch das Schließen oder Freigeben von Ressourcen der App nicht zulässt. Zuerst dachte ich, es wäre ein Müllsammelproblem.

8
Justin W

Zum Beantworten ein wenig spät, aber ich löse das Problem, indem Sie zu den Eigenschaften des Projekts gehen> Registerkarte "Debuggen"> deaktivieren Sie "Aktivieren Sie den Visual Studio-Hosting-Prozess".

5
John Willemse

VS2017 - Behebung durch Schließen aller Instanzen von MSBuild.exe im Windows-Task-Manager

4
lloyd

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

3
Johannes Wentu

Ich habe dieses Problem überwunden, indem ich die gesperrte Datei umbenannt habe (mit Windows Explorer). Ich durfte die Datei nicht löschen, aber das Umbenennen der gesperrten Datei funktioniert!

2
Ola Eldøy

Ich hatte das gleiche Problem mit meiner Xamarin-Anwendung in Visual Studio. Dieses Problem wurde durch Ziehen des Testgeräts gelöst. Die Anwendung wurde geschlossen und der Debugger wurde angehalten, der Fehler trat jedoch 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 vom Netz getrennt hatte, weil ich einen Anruf erhalten musste. 

1
Tomislav3008

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

Erläuterung: Mein Problem begann, nachdem ein benutzerdefiniertes Steuerelement erstellt und in die Toolbox-Palette gezogen und dort abgelegt wurde, um es in Designformularen zu verwenden. Zuerst erschien eine Warnung, die besagte, dass es eine Redundanz zwischen der Quelldatei der benutzerdefinierten Steuerung (.cs) und der ausführbaren Datei (.exe) des Projekts gab. Beim Ausführen/Debuggen trat der Fehler auf: Der Zugriff auf die (.exe) -Datei ist nicht möglich, da sie verwendet wird (und der Wert true war).

Ich habe buchstäblich den gesamten Quellcode in Bezug auf das benutzerdefinierte Steuerelement entfernt, und das Problem blieb immer noch bestehen, bis ich die Verweise auscheckte und auf sich selbst verwies, um "das vorherige benutzerdefinierte Steuerelement" zu erhalten. Ich habe den Hinweis entfernt und fertig !!

1

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

net stop iisadmin /y

und dann

iisreset

arbeitete für mich . vs 2003

1
toha

Nur um meine 2 Cent zu werfen. Mein Problem wurde durch Öffnen des Task-Managers und Beenden der Anwendung behoben. Es lief im Hintergrund ohne Hinweis darauf, dass es überhaupt ausgeführt wurde (kein Element in der Taskleiste, keine Benutzeroberfläche, nichts), aber ich bin nicht sicher, warum dies passiert ist. Offensichtlich lief der Debugger nicht und ich hatte damals nur eine einzige Instanz von VS geöffnet. Es wundert mich, dass dies in diesem VS 2017 immer noch geschieht. 

Vielleicht kann ich einen Erstellungsschritt hinzufügen, der nach der Anwendung sucht, die den Hintergrund ausführt, und den Vorgang abtöten, bevor die neue gestartet wird.

1
Benjamin McGill

Für mich war es ein Windows-Dienst, der installiert wurde und ausgeführt wurde. Sobald ich damit aufhörte, war der Build erfolgreich.

1
Garrison Neely

Was für mich funktionierte, war, IIS neu zu starten

0
Beanwah

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

0
J T

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

Dies sollte jedoch normalerweise nicht passieren. Ich denke, ProcessExplorer kann Ihnen sagen, welche Dateien ein Prozess gesperrt hat. Wenn nicht, Explorer eines der anderen sysinternals-Tools verarbeiten.

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

0
Andy

ich hatte das gleiche Problem. Das Ändern der Debug-/Release-Konfiguration hat den Trick nicht gebracht. Zumindest nicht ohne dazwischen zu bauen.

in meiner Lösung (winform) wurde es gelöst, indem die mainform 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 bauen Sie alles neu auf (Strg-Umschalt-B). Das hat bei mir funktioniert.

es scheint, als hätte eine Art Handle aus der winform-App (die einen Backgroundworker ausführt) noch ein Dateizugriff für einige der anderen verwendeten Bibliotheken.

0
Obelix

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. Es wurde kein msbuild.exe-Prozess ausgeführt. Es wurde auch versucht, VS ohne Erfolg neu zu starten. Nur der Neustart von Docker hat funktioniert.

0
Carlos

Dieses Problem ist kürzlich aufgetreten, als ich versuchte, eine Lösung zu erstellen, an der ich gerade arbeite (nicht nur ein Winforms-Projekt).
Zusätzlich zu build fehlgeschlagen, stellte ich fest, dass das Löschen von Projekten leise fehlgeschlagen ist (das Überprüfen des Bin-Ordners hat gezeigt, dass die Dateien nicht wirklich gelöscht wurden) und das Schließen von Visual Studio den devenv-Prozess nicht beendet hat Absturz. Der Windows-Wiederherstellungsvorgang würde dann Visual Studio neu starten.

Nach einigem Ausprobieren stellte ich fest, dass die Probleme nur bei mir aufgetreten sind, als ich beim Starten von VS die Lösung über das Menü "Zuletzt" geöffnet habe.
Beim Öffnen der Lösung von File >> Open >> Project/Solution wurde festgestellt, dass sie ordnungsgemäß funktioniert.

Momentan keine Ahnung warum - werde das weiter untersuchen, aber vorerst kann ich wenigstens arbeiten!

0
Guy Passy

Ich bin kürzlich beim Bereitstellen auf Service Fabric auf das Problem gestoßen. Der Fehler bedeutet, dass eine 'Datei' verwendet wird. Ich habe jedoch festgestellt, dass der Port von einer anderen IDE verwendet wurde. Durch das Stoppen eines ausgeführten Dienstes, der bereits auf dem Port gehostet wurde, konnte das Auftreten dieser Ausnahme verhindert werden.

0
osoclever

Als ich den Prozess .Net Core Host beendete, baute alles gut. Ich musste Visual Studio nicht schließen oder etwas anderes ändern. 

0
slimeygecko

Der gleiche Fehler wurde durch das Aktualisieren der Supportpakete für Google Nuget behoben

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.

0
B.M.

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

0
Janis S.

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

0
Artem K