| 

.NET C# Java Javascript Exception

1
Hallo zusammen,
ich habe immer wieder das Problem, dass beim Kompilieren eine Fehlermeldung kommt:
'Unable to copy file "obj\x86\Debug\X.exe" to "bin\Debug\X.exe". The process cannot access the file 'bin\Debug\X.exe' because it is being used by another process.'
Ich habe im Netz gesucht, und ich habe folgende Abhilfen gefunden, die aber nicht zum Erfolg geführt haben:
1. Build event mit folgendem Code:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
2. In den Project Properties / Debug den Haken "Enable the Visula Studion hosting process" wegnehmen.
Wie schon gesagt, hat alles nichts genützt. Im Taskmanager sehe ich den Prozess nicht. Die einzige Abhilfe ist, dass Studio neu zu starten.
Hat jemand eine Idee, was ich noch tun kann?
News:
26.07.2011
KN
KN
1,7k ● 1 ● 8
Editiert 26.07.2011
KN
KN
1,7k ● 1 ● 8
Könnte ein Virenscanner o. ä. die Dateien gerade am Wickel haben?
– jsc 26.07.2011
Nein, das ist wahrscheinlich nicht das Problem. Dazu tritt das Problem zu oft auf.
– KN 26.07.2011
2 Antworten
2
Ich hab das Problem auch manchmal (recht selten) aber ich behelf mich dann auch immer mit nem VS neustart.

Wenn bei dir das Problem häufiger auftritt, versuchs mal mit eine Batch die die als PreBuild-Event einträgst und die die Zieldatei - wenn vorhanden - umbennt. Z.B. in X.ex_. Eine laufende Exe kannst du zwar nicht löschen, aber du kannst Sie umbennen.
26.07.2011
Floyd
Floyd
14,6k ● 3 ● 9
Danke, das werde ich gleich probieren.
– KN 26.07.2011
1
Da ein VS-Neustart hilft, wird wohl auch VS die Datei irgendwo festhalten. Evtl. nutzt du ein Addon, dass dafür verantwortlich sein könnte? Oder irgendeine unglückliche Einstellung?
Die Variante mit der Script wäre ja nur ein Workaround.
– jsc 26.07.2011
Nein, ich nutze kein Addon. Das Problem hatte ich auch schon bei anderen Projekten.
– KN 26.07.2011
Deine Idee, Floyd, wird schon von meinem Pre-Build-Event gemacht (siehe Frage). Die exe wird umbenannt, und wenn sie noch von wem auch immer festgehalten wird, dann bleibt das auch so, und das Script geht beim nächsten kompilieren schief, wenn die umbenannte Datei nicht gelöscht werden kann. Ich kann natürlich eine Batch-Datei erzeugen, die die Namen der umbenannten Datei hochzählt. Aber ich würde gerne wissen, wie ich das Problem grundsätzlich angehe. Das Problem tritt ja auch nicht immer auf, nur bei jedem 3 - 10. Build, auch wenn ich das Programm vorher an der gleichen Stelle beendet habe.
– KN 26.07.2011
1
Wenn ich das richtig sehe macht das Pre-Build-Event was du in deiner Frage gepostet hast ein "delete".
Aber natürlich wäre es interessant zu wissen wo das echte Problem liegt.
– Floyd 26.07.2011
Die erste Zeile des Pre-Build-Events löscht den beim letzen Build-Vorgang umbenannten File. Die zweite Zeile benennt die aktuelle exe um, die dann bei nächsten Build gelöscht wird. Das Problem wird also um ein Build nach hinten geschoben. Oder sehe ich das falsch?
– KN 26.07.2011
Stimmt .. sorry mein Fehler :D
– Floyd 26.07.2011
Hi ihr lieben Mitdiskutieren, ich mache jetzt mal einen Kommentar, weil ich das Problem jetzt anscheinend selbst gelöst habe und ich es dich wissen lassen wollte, weil ihrso nett mitdiskutiert habt. Siehe meine Antwort auf die Frage.
– KN 28.07.2011
2
Ich habe jetzt selbst eine Lösung gefunden (Internetrecherche):

try changing the [assembly: AssemblyVersion("1.0.*")] in AssemblyInfo.cs to [assembly: AssemblyVersion("1.0.0")] (i.e. without the "auto increment" asterisk for build/revision number). His suggestion to why this causes the problem, is "I'm guessing that VS was keeping a handle on each file it generated, so it would know how to increment things", which does sound at least plausible.

Bis jetzt ist das Problem nicht mehr aufgetaucht.
28.07.2011
KN
KN
1,7k ● 1 ● 8
Editiert 28.07.2011
Floyd
Floyd
14,6k ● 3 ● 9

Stelle deine .net-Frage jetzt!
».NET Software-Entwickler (m/w)
TOP TECHNOLOGIES CONSULTING GmbH