Visual Studio-Build schlägt fehl: Exe-Datei kann nicht von obj \ debug nach bin \ debug kopiert werden


193

Update: Ein Beispielprojekt, das diesen Fehler reproduziert, finden Sie hier bei Microsoft Connect . Ich habe auch getestet und verifiziert, dass die in der unten akzeptierten Antwort angegebene Lösung für dieses Beispielprojekt funktioniert. Wenn diese Lösung für Sie nicht funktioniert, haben Sie wahrscheinlich ein anderes Problem (das in einer separaten Frage enthalten ist).


Dies ist eine Frage, die zuvor gestellt wurde, sowohl hier bei Stack Overflow als auch an anderen Stellen, aber keiner der Vorschläge, die ich bisher gefunden habe, hat mir geholfen, daher muss ich nur versuchen, eine neue Frage zu stellen.

Szenario: Ich habe eine einfache Windows Forms-Anwendung (C #, .NET 4.0, Visual Studio 2010). Es verfügt über einige Basisformulare, von denen die meisten anderen Formulare erben. Für den Datenbankzugriff werden Entity Framework (und POCO-Klassen) verwendet. Nichts Besonderes, kein Multithreading oder so.

Problem: Für eine Weile war alles in Ordnung. Dann konnte Visual Studio aus heiterem Himmel nicht erstellt werden, als ich die Anwendung starten wollte. Ich habe die Warnung "Datei '... bin \ Debug \ [ProjectName] .exe' kann nicht gelöscht werden. Der Zugriff auf den Pfad '... bin \ Debug \ [ProjectName] .exe' wird verweigert." und der Fehler "Datei 'obj \ x86 \ Debug \ [Projektname] .exe' kann nicht nach 'bin \ Debug \ [Projektname] .exe' kopiert werden. Der Prozess kann nicht auf die Datei 'bin \ Debug \ [Projektname] .exe zugreifen "Weil es von einem anderen Prozess verwendet wird." (Ich erhalte sowohl die Warnung als auch den Fehler beim Ausführen von Rebuild, aber nur den Fehler beim Ausführen von Build - halten Sie das nicht für relevant?)

Ich verstehe sehr gut, was in der Warn- und Fehlermeldung steht: Visual Studio versucht offensichtlich, die exe-Datei zu überschreiben, während sie gleichzeitig aus irgendeinem Grund gesperrt ist. Dies hilft mir jedoch nicht, eine Lösung für das Problem zu finden. Ich habe nur festgestellt, dass es funktioniert, Visual Studio herunterzufahren und erneut zu starten. Das Erstellen und Starten funktioniert dann, bis ich einige Formulare ändere, dann habe ich wieder das gleiche Problem und muss neu starten ... Ziemlich frustrierend!

Wie ich oben erwähnt habe, scheint dies ein bekanntes Problem zu sein, daher gibt es viele Lösungsvorschläge. Ich werde nur auflisten, was ich hier bereits versucht habe, damit die Leute wissen, was sie überspringen sollen:

  • Erstellen Sie eine neue saubere Lösung und kopieren Sie einfach die Dateien aus der alten Lösung.
  • Fügen Sie dem Pre-Build-Ereignis des Projekts Folgendes zu Folgendem hinzu:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
       if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
    
  • Hinzufügen der folgenden Elemente zu den Projekteigenschaften (.csproj-Datei):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Keiner von ihnen hat jedoch für mich gearbeitet, sodass Sie wahrscheinlich sehen können, warum ich anfange, ein bisschen frustriert zu werden. Ich weiß nicht, wo ich sonst suchen soll, also hoffe ich, dass mir jemand etwas zu geben hat! Ist das ein Fehler in VS und wenn ja, gibt es einen Patch? Oder habe ich etwas falsch gemacht, habe ich einen Zirkelverweis oder ähnliches und wenn ja, wie könnte ich das herausfinden?

Anregungen sind sehr dankbar :)

Update: Wie bereits erwähnt in Kommentar unten, ich habe auch geprüft , Process Explorer verwenden , dass es tatsächlich ist Visual Studio, das die Datei blockiert.


4
Haben Sie überprüft, ob Ihre Anwendung ordnungsgemäß geschlossen wird? Zeigt Ihnen der Task-Manager [ProjectName] .exe in der Liste der Prozesse an?
Miensol

2
Ich hatte dies schon einmal und habe die Datei einfach in .old etc umbenannt und den Build erneut ausgeführt. Nicht gerade ein Fix, den ich kenne, aber es hat bei mir funktioniert.
Codingbadger

@miensol: Ja, es scheint richtig zu schließen. Ich erhalte "Das Programm '[1848] [ProjectName] .vshost.exe: Managed (v4.0.30319)' wurde mit dem Code 0 (0x0) beendet." @Barry: Das Umbenennen der exe-Datei in bin \ Debug funktioniert, aber wie Sie sagten, ist es keine wirkliche Lösung und wird jedes Mal ziemlich ärgerlich sein, dies tun zu müssen. Ein bisschen besser als Visual Studio neu zu starten ...
Julian

2
@Naliluj: Ich bin auf diesen Artikel aus einem Microsoft-Forum gestoßen , in dem erklärt wird, dass er sich auf Ressourcendateien beziehen kann. Wenn Sie Resx-Dateien verwenden, kann dies einen Hinweis geben.
Patrick

1
Für die Nachwelt hatte ich dieses Problem und es wurde gelöst, indem das Element <GenerateResourceNeverLockTypeAssemblies> true </ GeneralResourceNeverLockTypeAssemblies> zu meiner csproj-Datei hinzugefügt wurde.
ThisIsTheDave

Antworten:


117

Das wird sich dumm anhören, aber ich habe alle diese Lösungen ausprobiert und VS2010 unter Windows 7 ausgeführt. Keine davon hat funktioniert, außer das Umbenennen und Erstellen, was gelinde gesagt SEHR mühsam war. Schließlich habe ich den Täter aufgespürt und es fällt mir schwer zu glauben. Aber ich habe den folgenden Code in AssemblyInfo.cs verwendet ...

[assembly: AssemblyVersion("2.0.*")]

Dies ist ziemlich häufig, aber aus irgendeinem Grund hat das Ändern der Version auf 2.0.0.0 dazu geführt, dass die Dinge wieder funktionieren. Ich weiß nicht, ob es sich um eine Windows 7-spezifische Sache handelt (ich benutze sie erst seit 3-4 Wochen) oder ob es zufällig ist oder was, aber es hat es für mich behoben. Ich vermute, dass VS jede generierte Datei im Griff hatte, damit es weiß, wie man Dinge erhöht? Ich bin mir wirklich nicht sicher und habe das noch nie gesehen. Aber wenn jemand anderes da draußen auch die Haare ausreißt, probieren Sie es aus.


12
Das ist eine verrückte Idee, das gebe ich dir;) Was noch verrückter ist, ist, dass es tatsächlich zu funktionieren scheint! Ich habe dies jetzt mehrmals getestet und kann bestätigen, dass bei Verwendung einer Assembly-Version wie "2.0. *" Der Fehler angezeigt wird, aber wenn ich stattdessen "2.0.0" verwende, funktioniert dies als Zauber! Ich fordere mehr Leute auf, dies zu testen, und wenn Sie feststellen, dass es funktioniert, stimmen Sie bitte über diese Antwort ab, denn dies muss bekannt sein! Hoffe, Microsoft greift dies auf ... Danke drharris :)
Julian

2
Dies hat bei mir nicht funktioniert. Beim Neustart von VS wurde für einige Zeit kein Fehler angezeigt. Jedes Mal, wenn ich diesen Fehler erhalte, muss ich VS 2010
Sharique

6
fyi ... das hat bei mir nicht funktioniert. Meine Einstellungen waren immer: [Assembly: AssemblyVersion ("1.0.0.0")] [Assembly: AssemblyFileVersion ("1.0.0.0")]
tbone

4
Wenn Sie derzeit über [Assembly: AssemblyVersion ("1.0.0.0")] verfügen, ersetzen Sie diese durch [Assembly: AssemblyVersion ("2.0.0.0")] (dh '2' anstelle von '1'). Es hat bei mir funktioniert. Obwohl ich nicht überprüft habe, ist es möglich, dass das Problem durch einfaches Ändern der Version auf etwas anderes als das, was Sie jetzt haben, behoben werden kann.
Frederick The Fool

1
Funktioniert auch für DLL! VS sagt, dass die DLL nicht kopiert werden kann und nach dem Ändern von BEIDEN [Assembly: AssemblyVersion] und [Assembly: AssemblyFileVersion ()] von 1.0. * Auf 2.0.0.0 hat es funktioniert.
AZ.

14

Da ich zu diesem Thema kein Feedback mehr erhalten habe, dachte ich, ich würde nur mitteilen, was meine Lösung war:

Wie von Barry in einem Kommentar zum ursprünglichen Beitrag vorgeschlagen, ist das manuelle Umbenennen der Datei ' ... bin \ Debug [ProjectName] .exe' in etwas anderes (z. B. '[ProjectName] 1.exe' ) eine Problemumgehung (I '). Ich darf die Datei jedoch nicht selbst löschen, und ich muss sagen, dass ich das etwas seltsam finde, da man glauben würde, dass dieselbe Sperre, die das Löschen verhindert, auch das Umbenennen verhindern würde ...). Es ist keine gute Lösung, aber es ist ziemlich schnell (zumindest nachdem Sie es ein paar Mal gemacht haben, wird es fast zur Routine) und zumindest viel schneller als ein Neustart von Visual Studio, wie ich es am Anfang getan habe.

Falls sich jemand wundert, könnte ich auch hinzufügen, dass ich dieses Problem nur halb zufällig sehe. Dies geschieht normalerweise, nachdem ich einige Änderungen im Entwurfsmodus eines Formulars vorgenommen habe (aber nicht immer). Es passiert normalerweise nicht, wenn ich nur Geschäftslogikcode oder nicht visuellen Code ändere (aber manchmal ...). In der Tat frustrierend, aber zumindest habe ich einen Hack, der für mich funktioniert - hoffen wir nur, dass mein nächstes Projekt nicht auch mit diesem Problem konfrontiert ist ...

@Barry: Wenn du eine Gutschrift für deinen Kommentar erhalten möchtest, kannst du ihn gerne als Antwort posten und ich werde ihn unbedingt akzeptieren :)


Ich habe dies abgestimmt, da ich dies in der Vergangenheit getan habe. Ich stimme zu, es ist eine schmutzige Lösung, aber es funktioniert. VS hatte dieses Problem für einige Iterationen. Ich lade mein Projekt auch aus einem Netzwerkverzeichnis. Es wurde voll vertraut, aber es spielt keine Rolle. Es spielt keine Rolle, ob es sich um eine Laufwerkszuordnung oder eine UNC handelt. Ja, MS muss dieses Problem wirklich beheben. Sie haben einen geschlossenen Fehler, der besagt, dass sie nicht reproduzieren können. Lame!
Josh Robinson

14

Ich habe eine einfache Lösung gefunden: Deaktivieren Sie einfach die Windows-Indizierungsdienste für den Projektordner und die Unterordner


2
Das hat auch bei mir funktioniert. Ich bin nicht sicher, ob ich verstehe, warum, wie der Prozess-Explorer zeigte, devenv.exe den Verriegelungsgriff hielt. Das Deaktivieren der Indizierung hat das Problem jedoch behoben.
Fopedush

1
@Fopedush Ich bin auf dieses Problem mit derselben Lösung gestoßen, obwohl ich diese Frage zu diesem Zeitpunkt nicht gesehen habe. Diese Antwort hat eine Erklärung, warum es hilft.
Darren Hale

1
Dieser hat es für mich getan.
Martin Capodici

12

Ich habe das gleiche Problem (MSB3021) mit dem WPF-Projekt in VS2008 (unter Windows 7 x32). Das Problem tritt auf, wenn ich versuche, die Anwendung nach dem vorherigen Ausführen zu schnell erneut auszuführen. Nach ein paar Minuten wird die Exe-Datei von selbst entsperrt und ich kann die Anwendung erneut ausführen. Aber eine so lange Pause ärgert mich. Das einzige, was mir wirklich geholfen hat, war VS als Administrator auszuführen.


1
Ich habe diesen aktuellen Fehlerbericht zu genau diesem Problem gefunden: connect.microsoft.com/VisualStudio/feedback/details/558848/… Dieser Fehlerbericht enthielt ein Beispielprojekt, mit dem der Fehler reproduziert werden konnte. Die von drharris vorgeschlagene Lösung funktionierte auch dort (eine schrittweise Lösung für das Beispielprojekt finden Sie in der im obigen Link angegebenen Problemumgehung).
Julian

Dies ist die einzige Lösung, die auch für mich funktioniert hat. Danke @Nailuj!
Flügelspieler

Dies ist sicher einfacher als ein Neustart von VS.
Elvedin Hamzagic

1
"Seite nicht gefunden" für Verbindungsproblem, haben sie es nur aus Verlegenheit gelöscht = S Gab es jemals eine veröffentlichte Lösung / Problemumgehung dafür?
Coops

9

Wenn ich auf dieses Problem gestoßen bin, hat dies damit zu tun, dass das Projekt, das ich erstellen möchte, in der Lösung als Startprojekt festgelegt ist, wodurch die EXE-Datei im Ordner obj gesperrt wird (sie wird auch in Ihrem Task-Manager angezeigt). Klicken Sie mit der rechten Maustaste auf ein anderes Projekt in Ihrer Lösung und wählen Sie Startprojekt festlegen. Dadurch wird die Sperre aufgehoben, aus dem Task-Manager entfernt und Sie können sie erstellen.


1
Das funktioniert jedes Mal bei mir. Es scheint mit dem vshost-Prozess zu tun zu haben, der für Dienste generiert und gestartet wird
jaywayco

8

Ich habe alle anderen Vorschläge in den Antworten hier ausprobiert, von denen keiner funktioniert hat. Schließlich habe ich mithilfe von Process Monitor festgestellt, dass meine EXE-Datei, die VS2010 nicht erstellen konnte, vom Systemprozess gesperrt wurde (PID = 4). Die Suche in SO nach diesbezüglichen Situationen ergab diese Antwort.

Zusammenfassend: Wenn Sie den Application Experience-Dienst deaktiviert haben (wie ich), aktivieren Sie ihn erneut und starten Sie ihn. Zwei Jahre der Erschwerung endeten.


+1 Ich habe zuvor alles andere ausprobiert (1. Task-Manager, 2. Prozess-Explorer, dh Handle schließen, was Windows nicht zulässt, 3. Antivirus deaktivieren, 4. APP_DATA / Local / Microsoft / Visual Studio vom Windows-Indexdienst ausschließen. ) aber dieser Tipp zu: "Application Experience" -Dienst ist der einzige, der mir erspart hat, meinen Kopf gegen die Wand zu schlagen. Ich habe es aktiviert und das Problem ist verschwunden. Lustige Sache ist, nachdem ich es wieder deaktiviert hatte, war alles noch in Ordnung. Ich hatte keine Probleme mehr. Aber definitiv ist dies das einzige, was es für mich sortiert hat.
Tomás

Arbeite auch für mich !!! Die einzige andere Sache, die auch funktioniert, ist das Löschen des bin- Ordners vor dem Ausführen der Anwendung, aber Sie müssen immer vor dem Ausführen löschen, sehr ärgerlich.
E_Blue

6

Ich hatte auch ein ähnliches Problem und stellte in meinem Fall fest, dass ich den Ordner bin \ debug als freigegebenen Ordner unter VMware und entweder VMware, Explorer unter dem VM-Gast oder sogar als Antivirenprogramm verfügbar gemacht hatte Das Programm unter dem Gast (obwohl ich nicht glaube, dass ich eines installiert habe) hielt ein Handle für die Datei (en).


Ich habe Avast installiert und heute Morgen habe ich einen zufälligen MVC-Fehler erhalten, der besagt, dass meine DLL einen Virus enthält. Nach dem Fehler konnte ich mein MVC-Projekt nicht mehr erstellen. Ich habe dem Avast File System Shield eine Ausnahme hinzugefügt und alles funktioniert wieder.
Dusty


4

Ich würde einen Download vorschlagen Process Explorer, um herauszufinden, durch welchen Prozess die Datei gesperrt wird. Es kann gefunden werden bei:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


Ich stimme zu - es ist nicht unbedingt VS, das die Datei sperrt. Virusprüfer können daran schuld sein. Schalten Sie den Virenprüfer aus, um festzustellen, ob dies hilfreich ist.
Polyfun

Entschuldigung, ich habe vergessen zu erwähnen, dass ich das bereits getan habe. Und es heißt, dass es sich um Visual Studio (devenv.exe) handelt, das eine Sperre für die Datei hat ([ProjectName] .vshost.exe). Das hilft mir auch nicht viel.
Julian

@ShellShock: Das Deaktivieren meines Antivirenprogramms (Avast) hilft auch nicht.
Julian

Wenn ich Sysinternals ProcessExplorer verwende, kann ich ein Handle für diese Datei sehen, aber wenn ich darauf klicke, wird keine Anwendung angezeigt, die es hält, und wenn ich versuche, das Handle zu schließen, wird der Fehler beim Öffnen des Handles angezeigt ungültig." Fehler im ProcessExplorer. Trotzdem bleibt die Sperre bestehen.
Knochen

4

Mit Visual Studio konnte ich nie ein einfaches Projekt entwickeln, um den Fehler zu reproduzieren.

Meine Lösung bestand darin, den Visual Studio-Hosting-Prozess zu deaktivieren.

Für Interessenten habe ich eine Handle-Spur für den beleidigenden Handle angehängt:

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

Wenn Sie ganz oben in der Frage sehen, gibt es einen Link zu Microsoft Connect mit einem Fehlerbericht und einem Beispielprojekt, das den Fehler reproduziert: connect.microsoft.com/VisualStudio/feedback/details/558848/…
Julian

Das Deaktivieren des Hosting-Prozesses hat bei mir funktioniert. Es funktioniert auch nach dem erneuten Aktivieren weiter. Ich habe 4 Stunden lang versucht, dieses Problem zu beheben, indem ich Hunderte von Lösungen ausprobiert habe. Dies ist die einzige, die auch nur aus der Ferne zu funktionieren schien.
Drew Chapin

4

WENN IHR PROBLEM NOCH NICHT GELÖST IST:

Der Fehler von Visual Studio ist:

"Der Prozess kann nicht auf die Datei 'bin \ Debug ** app.exe **' zugreifen, da sie von einem anderen Prozess verwendet wird."

Gehen Sie also zum Task-Manager von Windows (Strg + Umschalt + Esc), suchen Sie Ihren Anwendungsnamen und erzwingen Sie das Schließen durch Endprocces.


3

Hier ist eine andere Möglichkeit:

Nachdem ich diesen Fehler in vs2012 / win7 erhalten hatte, versuchte ich, die Datei im bin-Verzeichnis zu löschen, und der Explorer zeigte an, dass die Datei vom XAML UI Designer verwendet wurde.

Ich habe alle in VS geöffneten Registerkarten geschlossen, VS geschlossen und dann sichergestellt, dass alle MSBuild-Prozesse im Task-Manager beendet wurden. Nach dem Neustart von VS konnte ich schließlich die Lösung erstellen.


und eine andere mögliche Ursache:

Ich habe eine andere mögliche Ursache für dieses Problem festgestellt. Nachdem ich einige Code-Umgestaltungen durchgeführt und Projekte in eine Lösung hinein- und herausbewegt hatte, verwiesen meine Projektreferenzen nicht mehr wie erwartet auf die Projekte in der Lösung.

Dieses irreführende visuelle Studio glaubt, es könnte einige Projekte gleichzeitig erstellen und so die Dateisperren erstellen.

BEARBEITEN: Ich habe dies sogar kürzlich mit VS2012 einige Male erlebt und es behebt es, sobald ich die Erstellungsreihenfolge auf die richtigen Abhängigkeiten eingestellt habe, alle von VS ausgeführten msbuild-Prozesse beendet und dann VS neu gestartet habe. Ich töte die msbuild-Prozesse nur, um sicherzugehen, aber das Schließen von VS sollte sie auch beenden.

Was ich normalerweise tue, um dies zu verursachen, ist, ein Projekt so umzugestalten, dass es auf einem anderen Projekt innerhalb der Lösung basiert, auf das es beim letzten Build nicht verwiesen hat. Dies scheint VS manchmal zu verwirren und aktualisiert die Erstellungsreihenfolge nicht.

So überprüfen Sie die Erstellungsreihenfolge: Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Lösung, wählen Sie "Projekterstellungsreihenfolge ..." aus und überprüfen Sie, ob die Abhängigkeiten für jedes Projekt ordnungsgemäß notiert sind.


Wir haben dies kürzlich bei einem WinPhone 8-Projekt erlebt. Unerklärlicherweise war die Ursache die Verwendung des Tupel-Typs. Durch Entfernen des Codes, der ein Tupel verwendet hat, ist das Problem behoben. Fügen Sie den Code zurück, den das Problem zurückgegeben hat.
Seamus

Ich hatte das gleiche Problem mit VS2012, das Schließen von VS hat nicht den Trick getan - ich musste alle msbuild.exe-Aufgaben manuell
beenden

Ich verwende VS 2013 und konnte vor jedem Build den Prozess "XDesProc.exe * 32" (Microsoft Visual Studio XAML-UI-Designer) im Task-Manager beenden, und das hat den Trick getan. VS muss nicht neu gestartet werden, da der XAML-UI-Designer jedes Mal neu zu laden scheint, wenn Sie eine * .xaml-Datei in der Entwurfsansicht öffnen.
Tim Sexton

3

IIS neu starten - kann ein Prozess sein, der an den Debugger angehängt ist


3

Deaktivieren Sie Antivirus und versuchen Sie es. Ich hatte auch dieses Problem ... aber in meinem Fall blockierte Antivirus meine Anwendung, als ich Antivirus deaktivierte, das behoben wurde.


3

Ich hatte den gleichen Fehler.

Ich habe das Problem gelöst, indem ich den gesamten Inhalt der Bin- Ordner aller abhängigen Projekte / Bibliotheken gelöscht habe .

Dieser Fehler tritt hauptsächlich aufgrund von Versionsänderungen auf.



1

Mach zuerst die einfachen Dinge.

Stellen Sie sicher, dass ein Teil Ihrer Lösung nicht durch einen laufenden Prozess gesperrt ist.

Zum Beispiel habe ich "InstallUtil" auf meinem Windows-Dienst ausgeführt (den ich normalerweise von einer Konsole aus teste).

Dadurch wurden einige meiner DLLs im Ordner bin des Windows-Dienstprojekts gesperrt. Bei einem Umbau habe ich die Ausnahme in dieser Ausgabe erhalten.

Ich habe den Windows-Dienst gestoppt, neu erstellt und es war erfolgreich.

Überprüfen Sie den Windows Task-Manager für Ihre Anwendung, bevor Sie die in dieser Ausgabe beschriebenen Schritte ausführen.

Wenn Sie also Schritte hören, denken Sie an Pferde, nicht an Zebras! (vom Medizinstudentenfreund)


1

Ich hatte das gleiche Problem. Es hieß, es könne nicht von bin \ debug nach obj kopiert werden .....

Als ich ein Webprojekt erstellte, stellte ich fest, dass sich meine DLL alle im Ordner bin und nicht in bin \ debug befanden. Während der Veröffentlichung suchte vs nach Dateien in bin \ debug. Also habe ich die Webprojektdatei im Editor geöffnet und nach Instanzen von bin \ debug gesucht und festgestellt, dass alle DLLs als bin \ debug \ mylibrary.dll erwähnt wurden. Ich habe all \ debug aus dem Pfad entfernt und erneut veröffentlicht. Diesmal konnte vs die gesamte DLL im Ordner bin finden und erfolgreich veröffentlichen.

Ich habe keine Ahnung, wie dieser Pfad in der Webprojektdatei geändert wurde.

Ich habe mehr als 5 Stunden damit verbracht, dies zu debuggen und schließlich selbst eine Lösung gefunden.

Das ist die richtige Antwort .


1

Wenn keines der oben genannten Verfahren funktioniert und Sie eine Konsolenanwendung entwickeln:

Versuchen Sie, ein beliebiges Zeichen in Program.cs einzugeben, und löschen Sie es dann. Ich habe keine Ahnung, warum dies funktioniert, aber es scheint das Problem "Kopieren nicht möglich" jedes Mal zu lösen.


1

Dies wird eher häufig von Avast verursacht.

Normalerweise kann ich meine Projekte unabhängig davon in Release ausführen, aber beim Ausführen im Debug würde dies ziemlich regelmäßig fehlschlagen.

Ich füge nur einen Ausschluss für meinen Projektordner hinzu und das Problem scheint zu verschwinden. Ich gehe davon aus, dass dies auch durch andere Antivirensoftware verursacht werden kann.


1

Das Umbenennen der EXE- und PUB-Datei hat bei mir funktioniert, war aber sehr mühsam. Ich habe auch das Problem, dass ich während einer Debug-Sitzung keine Bearbeitung durchführen konnte. Schließlich ging ich zur Seite mit den erweiterten Sicherheitseinstellungen wie folgt:

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMoniker-%WORK % 3dV4.0% 22% 29 & rd = true

Ich hebe die Auswahl auf und aktiviere das Kontrollkästchen "ClickOnce-Sicherheitseinstellungen aktivieren" erneut. Es ist seit einigen Tagen problemlos ...


1

Für mich wurde dies dadurch verursacht, dass eine Eingabeaufforderung im Zielordner ( C:\users\username\source\repos\project\project\bin\debug\app.publish) geöffnet war .

Ich bin mir nicht sicher, warum DEBUGGING den Zugriff auf den Veröffentlichungsordner erfordert, aber das Schließen des Befehlsfensters hat das Problem für mich gelöst.


1

Falls jemand beim Versuch, einen Unit-Test zu debuggen oder einen Unit-Test auszuführen, darauf stößt, musste ich die folgenden zwei Prozesse beenden, damit die Datei freigegeben wurde:

Prozesse zu töten.


0

Ich habe verschiedene von Ihnen bereitgestellte Lösungen ausprobiert, aber gelegentlich erhalte ich immer noch diesen Fehler. Ich bin mir sicher, dass mein Prozess nicht ausgeführt wird, und wenn ich versuche, die ausführbare Datei mit dem Internet Explorer zu löschen, wird sie aus der Dateiliste entfernt, aber dann drücke ich F5 und voila, die Datei ist zurück. Es wurde überhaupt nicht gelöscht.

Aber wenn ich die Datei über den TotalCommander lösche, wird die exe-Datei tatsächlich gelöscht und ich kann das Projekt erfolgreich erstellen.

Ich benutze Windows 7 x64 und Total Commander 7.56a 32 Bit.


0

Keine der anderen Antworten hat bei mir funktioniert, aber das Schließen aller geöffneten Registerkarten in Visual Studio scheint das Problem gelöst zu haben.


0

Ich weiß, dass dies eine sehr alte Frage ist, aber ich habe kürzlich den Fehler "Kann nicht von obj nach bin kopieren" in VS 2012 festgestellt. Jedes Mal, wenn ich versuchte, ein bestimmtes Projekt neu zu erstellen, wurde die Meldung angezeigt. Die einzige Lösung bestand darin, vor jedem Umbau eine Reinigung durchzuführen.

Nach langem Nachforschen stellte sich heraus, dass ich in einer meiner Dateien eine unvollständige Pragma-Warnmeldung hatte, die den Erfolg der Kompilierung nicht verhinderte, VS jedoch irgendwie verwirrte, die Datei (en) gesperrt zu halten.

In meinem Fall hatte ich oben in der Datei Folgendes:

#pragma warning(

Das ist es. Ich glaube, ich habe vor einiger Zeit versucht, etwas zu tun, war abgelenkt und habe den Vorgang nie beendet, aber die VS-Warnungen zu dieser bestimmten Zeile gingen im Shuffle verloren. Schließlich bemerkte ich die Warnung, entfernte die Leitung und baute seitdem jedes Mal neu auf.


0

Als ich vor einem ähnlichen Problem stand, schien nur Folgendes zu funktionieren:

  • Klicken Sie mit der rechten Maustaste auf das Projekt, gehen Sie zu Einstellungen und stellen Sie sicher, dass sowohl Debug- als auch Release-Builds auf dieselben Einstellungen abzielen oder dass dort die Einstellungen vorhanden sind, die die Anwendung zu laden oder zu speichern versucht.
  • Löschen des Ordners C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
  • Stellen Sie sicher, dass keine Dateien, die ich dort hatte, als "blockiert" betrachtet wurden. Wenn ich mit der rechten Maustaste auf die enthaltenen Dateien meines Projekts klickte, stellte ich fest, dass ein Symbol tatsächlich blockiert und als fehlerhaft angesehen wurde, da es aus dem Internet heruntergeladen wurde. Ich musste auf die Schaltfläche "Blockierung aufheben" klicken (siehe Beispiel: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Diese Datei stammt von einem anderen Computer und wurde möglicherweise blockiert, um zu helfen Schützen Sie diesen Computer. ").

0

Für Windows-Dienste, die WCF verwenden, habe ich den WFC-Hostprozess beendet und es hat funktioniert. Ich hasse es, wenn dies passiert, und es passiert manchmal zufällig.


0

Meine Lösung hat nichts mit Versionen, gesperrten Prozessen, Neustarten oder Löschen von Dateien zu tun.

Das Problem war tatsächlich darauf zurückzuführen, dass der Build fehlschlug und nicht den richtigen Fehler gab. Das eigentliche Problem war ein Konstruktionsfehler:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

Nachdem Task.Factory.StartNew();ich den Bereich von "a" außerhalb der Funktion geändert oder "a" danach nicht mehr verwendet hatte , konnte ich erneut erstellen.

Dies geschah bei Verwendung von VS2012 Update 4 unter Windows 7x64 SP1.

Fehlermeldung:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (3390,5): Fehler MSB3030: Die Datei "obj \ x86 \ Debug \ xxx.exe" konnte nicht kopiert werden, da sie nicht gefunden wurde .


0

Ich habe mit VS2013 festgestellt, dass ich diesen Fehler regelmäßig bekomme. Etwas, das einigermaßen gut zu funktionieren scheint, ist die Durchführung einer Neuerstellungslösung, bevor Sie versuchen, die Anwendung auszuführen. Ich habe festgestellt, dass das Ausführen eines CLEAN manchmal funktioniert, aber die Rebuild-Lösung scheint konsistenter zu funktionieren.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.