Frage Visual Studio sperrt die Ausgabedatei beim Build


Ich habe eine einfache WinForms-Lösung in VS 2010. Immer wenn ich es erstelle, endet Ausgabedatei (bin \ debug \ app.exe) gesperrt, und nachfolgende Builds scheitern mit einer Nachricht wie "The process cannot access the file 'bin\Debug\app.exe' because it is being used by another process." Die einzige Möglichkeit, das Projekt zu erstellen, besteht darin, VS nach jedem Build erneut zu starten sehr peinlich.

Ich habe diesen alten Blogpost gefunden http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspx - Es scheint, dass das Problem wirklich alt ist. Weiß jemand, was hier vor sich geht, oder zumindest ein Workaround?

Aktualisieren

Ich eigentlich nicht Lauf die Datei. Die Sperrung erfolgt nach dem Build, nicht nach dem Debugging (z. B. Start VS - Build - Build - Fail!) Und ich habe versucht, Antivirus auszuschalten. Es hilft nicht.

Update 2

Process Explorer zeigt, dass devenv.exe die Datei geladen hat (in DLLs, nicht in Handles). Es sieht so aus, als hätte ein Fehler während des Builds das Entladen verhindert, aber der (erste) Build wird ohne weitere Nachrichten beendet, außer "1 erfolgreich, o fehlgeschlagen" /


75
2018-01-04 21:13


Ursprung


Antworten:


Hatte das gleiche Problem, fand aber eine Lösung (Danke an Keyvan Nayyeri):

Aber wie löst man das? Es gibt verschiedene Möglichkeiten, die auf Ihrem Projekttyp basieren, aber eine einfache Lösung, die ich Visual Studio-Add-In-Entwicklern empfehle, besteht darin, den Build-Ereignissen eines Projekts einen einfachen Code hinzuzufügen.

Sie können der Pre-Build-Ereignisbefehlszeile Ihres Projekts die folgenden Codezeilen hinzufügen.

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

64
2018-04-29 15:10



Es ist kein Virenproblem. Es ist Visual Studio 2010 Bug. Es scheint, dass das Problem mit Visual Studio GUI-Designer zu tun hat.

Die Problemumgehung besteht darin, die gesperrte Ausgabedatei im Pre-Build-Ereignis in eine andere temporäre Datei zu verschieben. Es ist sinnvoll, den Dateinamen nach dem Zufallsprinzip zu generieren.

del "$(TargetPath).locked.*" /q 
if exist "$(TargetPath)"  move "$(TargetPath)" "$(TargetPath).locked.%random%"
exit /B 0

Wenn Sie konstante temporäre Dateinamen verwenden, verschieben Sie einfach die Sperren:

Diese Problemumgehung funktioniert genau einmal

 if exist "$(TargetPath).locked" del "$(TargetPath).locked"
    if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Ich habe auch eine Lösung mit 2 temporären Dateien gefunden, die genau 2 mal funktioniert.


24
2017-10-14 15:14



Das Problem ist mir auch aufgefallen.

Mein Szenario war folgendes: Windows 7 ausführen (konnte aber auch in Windows XP passieren) und während ich an einem Projekt mit WPF User Control arbeitete konnte ich alle Zeiten aufbauen, bis ich die XAML-Datei des User Controls öffne - von da an habe ich Ich habe einen Build, und dann sind die Dateien gesperrt.

Außerdem habe ich festgestellt, dass ich Visual Studio (Devenv.exe) als Administrator ausgeführt habe. Ich habe Visual Studio ohne Administratorrechte gestartet und das Problem war weg!.

Lass es mich wissen, wenn es dir auch hilft. Viel Glück.


5
2018-05-24 18:26



Ich habe dies entweder auf einer gierigen Viren-Scan-Software gesehen, oder wenn app.exe nicht ordnungsgemäß heruntergefahren wird. Stellen Sie sicher, dass der Prozess noch nicht ausgeführt wird.


3
2018-01-04 21:23



Was ist mit Virenscannern auf Ihrem Computer? Können Sie Prozesse sehen, die Griffe für Ihre Datei enthalten? Process Explorer herausfinden)?

Vielleicht ist "app.exe" in Ihrer Prozessliste sichtbar, d. H. Die letzte Version, die Sie debuggten, läuft noch? Wenn Sie Anwendungen mit mehreren Threads entwickeln, kann dies passieren, wenn Sie dies nicht tun joinalle von ihnen.


3
2018-02-17 10:09



Ich hatte das gleiche Problem und ich fand heraus, dass VS nur die exe sperrt, wenn ich ein Formular oder UserControl in VS vor dem Aufbau geöffnet habe. Die Lösung war ziemlich einfach, ich musste einfach jedes Form / UserControl schließen, bevor ich die Lösung erstellte und es funktionierte.


3
2017-09-09 09:51



Es gibt auch ein bekanntes Problem 533411 Die Verwendung automatisch aktualisierender Build-Nummern kann das Sperrproblem verursachen. Umgehung des Fehlerberichts

Temporäre Problemumgehung würde das Aktualisieren der Assemblyversion nach der Neuerstellung deaktivieren. Entfernen Sie in der Datei AssemblyInfo.cs die Platzhalterkarte aus dem AssemblyVersion-Attribut, zum Beispiel:
  Ersetze dies:
      [assembly: AssemblyVersion ("1.4. *")]
      [assembly: AssemblyFileVersion ("1.4")]
  mit diesem:
      [assembly: AssemblyVersion ("1.4.0.0")]
      [assembly: AssemblyFileVersion ("1.4.0.0")]


2
2017-10-14 16:06



Ich hatte dieses Problem und löste es mit einem benutzerdefinierten Code. Siehe hier: Visual Studio 2010 baut Dateisperrprobleme auf

Kompilieren Sie das Dienstprogramm in der akzeptierten Antwort, und verweisen Sie es während des Erstellungsschritts wie beschrieben, um das Problem zu umgehen. Ich schalte immer noch VS 2010 beim Mittagessen aus, um die Arbeit am Morgen zu säubern.

Der Grund für den benutzerdefinierten Code war, dass die oft empfohlene Lösung nur einmal funktionierte und dann die umbenannten Dateien ebenfalls gesperrt wurden, was das Umbenennen verhinderte. Hier fügen wir einfach die Datenzeitinformationen an die Datei an, damit die umbenannten Versionen nicht in Konflikt geraten können.


2
2018-03-04 15:52



Base auf dem großen Stormenet AntwortIch habe ein kleines Skript aufgesetzt, das in allen Fällen funktionieren sollte.

Hier ist der Code, der in das Textfeld für den Pre-Build-Event eingefügt werden soll

$(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

Pre build event

Hier ist das Skript, das in die Datei kopiert werden soll $(SolutionDir)\BuildProcess\PreBuildEvents.bat  (Natürlich können Sie diesen Pfad ändern):

REM This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!

echo PreBuildEvents 
echo  $(TargetPath) is %1
echo  $(TargetFileName) is %2 
echo  $(TargetDir) is %3   
echo  $(TargetName) is %4

set dir=C:\temp\LockedAssemblies

if not exist %dir% (mkdir %dir%)

REM delete all assemblies moved not really locked by a process
del "%dir%\*" /q

REM assembly file (.exe / .dll) - .pdb file - eventually .xml file (documentation) are concerned
REM use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1"  move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"

REM Code with Macros
REM   if exist "$(TargetPath)"  move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM   if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM   if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"

2
2018-04-09 09:04



Das Einzige, was für mich funktionierte, war, Visual Studio 2012 zu beenden, die BIN- und OBJ-Ordner für das Projekt zu löschen und Visual Studio erneut zu öffnen.

Problem gelöst ... Bis zum nächsten Mal.


0
2017-07-15 12:51



Wenn Ihr $ (TargetPath) auf eine DLL verweist, die COM verwendet, stellen Sie sicher, dass Sie über einen Standardkonstruktor verfügen. Nicht sicher, warum der Standardkonstruktor dort nicht abgeleitet wird. Das Hinzufügen des Standardkonstruktors funktionierte für mich in diesem Szenario.


0
2017-10-06 18:30