webentwicklung-frage-antwort-db.com.de

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

Update:Ein Beispielprojekt, das diesen Fehler reproduziert, finden Sie hier bei Microsoft Connect . Ich habe auch getestet und verifiziert, dass die in die unten akzeptierte 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 steht).


Dies ist eine Frage, die vorhin gestellt wurde, sowohl hier auf Stack Overflow als auch an anderen Stellen, aber keiner der Vorschläge, die ich bisher gefunden habe, hat mir geholfen, also 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, und verwendet Entity Framework (und POCO-Klassen) für den Datenbankzugriff. Nichts Besonderes, kein Multithreading oder so.

Problem: Für eine Weile war alles in Ordnung. Dann konnte Visual Studio aus heiterem Himmel nicht mehr erstellen, als ich die Anwendung starten wollte. Ich habe die Warnung "Datei '... bin\Debug\[Projektname] .exe' kann nicht gelöscht werden. Der Zugriff auf den Pfad '... bin\Debug\[Projektname] .exe' wird verweigert." und der Fehler "Die Datei 'obj\x86\Debug\[Projektname] .exe' kann nicht nach 'bin\Debug\[Projektname] .exe' kopiert werden. Der Prozess kann nicht auf die Datei 'bin\Debug\[ ProjectName] .exe ', 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. Findest du das nicht relevant?)

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

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

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

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
       if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
    
  • Folgendes zu den Projekteigenschaften hinzufügen (.csproj-Datei):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
    

Allerdings hat keiner von ihnen für mich gearbeitet, so dass 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 geben kann! Ist das ein Bug 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 im Kommentar unten erwähnt, habe ich auch mit Process Explorer überprüft, dass es tatsächlich Visual Studio ist, das die Datei sperrt.

185
Nailuj

Das hört sich dumm an, aber ich habe alle diese Lösungen ausprobiert und VS2010 unter Windows 7 ausgeführt. Keiner von ihnen funktionierte außer dem Umbenennen und Bauen, was sehr lästig war. Schließlich habe ich den Schuldigen ausfindig gemacht und es fällt mir schwer zu glauben. Aber ich habe den folgenden Code in AssemblyInfo.cs verwendet ...

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

Das ist ziemlich üblich, aber aus irgendeinem Grund hat die Änderung der Version auf 2.0.0.0 wieder funktioniert. Ich weiß nicht, ob es sich um ein Windows 7-spezifisches Ding handelt (ich habe es nur für 3-4 Wochen verwendet) oder ob es zufällig ist oder was, aber es hat es für mich behoben. Ich vermute, dass VS jede erzeugte Datei im Griff hatte, um zu wissen, wie man Dinge erhöht? Ich bin mir wirklich nicht sicher und habe noch nie gesehen, dass dies passiert. Aber wenn jemand anderes da draußen auch die Haare herauszieht, probieren Sie es aus.

114
drharris

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

14
Pedro

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

Wie von Barry in einem Kommentar zum Originalbeitrag vorgeschlagen, die '... bin\Debug [ProjectName] .exe' in etwas anderes umbenennen (zB '[ProjectName] 1.exe' ) ist eine Problemumgehung (ich darf die Datei jedoch nicht selbst löschen, und ich muss sagen, dass ich ein bisschen komisch finde, da man glauben würde, dass die gleiche Sperre, die das Löschen verhindert, auch das Umbenennen verhindern würde ...). Es ist keine gute Lösung, aber es ist schnell akzeptabel (zumindest nachdem Sie es ein paar Mal gemacht haben, wird es fast zur Routine) und zumindest viel schneller als beim Neustart von Visual Studio, was ich anfangs getan habe.

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

@Barry: Wenn Sie Wertschätzung für Ihren Kommentar erhalten möchten, können Sie ihn gerne als Antwort posten und ich werde sicher sein, ihn zu akzeptieren :)

14
Julian

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 Lauf zu schnell wieder auszuführen von selbst entsperrt und ich kann die Anwendung erneut ausführen. Aber eine so lange Pause macht mich ängstlich .. Das einzige, was mir wirklich geholfen hat, war VS als Administrator auszuführen.

12
Sergey

Wenn ich auf dieses Problem gestoßen bin, habe ich es mit der Tatsache zu tun, dass das Projekt, das ich erstellen möchte, als Startprojekt in der Projektmappe festgelegt ist und die .exe-Datei im obj-Ordner gesperrt wird. Klicken Sie mit der rechten Maustaste auf ein anderes Projekt in Ihrer Lösung und wählen Sie Startprojekt festlegen. Dadurch wird die Sperre freigegeben, aus dem Task-Manager entfernt und Sie sollten die Erstellung zulassen.

9
Adrian Booth

Ich habe alle anderen Vorschläge in den Antworten ausprobiert, von denen keiner funktionierte. Schließlich habe ich Process Monitor verwendet, um festzustellen, dass meine .exe, die VS2010 nicht erstellen konnte, vom Systemprozess gesperrt wurde (PID = 4). Das Durchsuchen von SO nach Situationen, in denen dies auftritt, ergab diese Antwort.

Zusammengefasst: Wenn der Application Experience-Dienst (wie ich) deaktiviert ist, aktivieren Sie ihn erneut und starten Sie ihn. Zwei Jahre der Verschärfung endeten.

8
Eight-Bit Guru

Ich hatte auch ein Problem, das diesem sehr ähnlich war, und fand den Grund in meinem Fall darin, dass ich den Ordner bin\debug als freigegebenen Ordner unter VMware und entweder VMware, Explorer unter dem VM - Gast oder möglicherweise sogar verfügbar gemacht hatte Ein Antivirenprogramm unter dem Gast (obwohl ich glaube, ich habe keines installiert) hielt die Datei (en) in den Griff.

6

Deaktivieren Sie "Aktivieren des Visual Studio-Hosting-Prozesses"  Project Debug Settings

5
BCS Software

WENN IHR PROBLEM IS NOCH NICHT GELÖSCHT:

Visual Studio's Fehler ist:

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

Gehen Sie zum Task-Manager von Windows (Strg + Umschalt + Esc) und suchen Sie nach dem Namen Ihrer Anwendung und zwingen, es durch Endprocces zu schließen.

4

Mit Visual Studio konnte ich niemals ein einfaches Projekt zur Reproduktion des Fehlers entwickeln.

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

Für Interessenten habe ich eine Handle-Trace für den beleidigenden Handle beigefügt:

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
3
danielm

Ich hatte den gleichen Fehler.

Ich habe das Problem gelöst, indem ich alle Inhalte der Ordner bin aller abhängigen Projekte/Bibliotheken gelöscht habe.

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

3
Utsav Dawn

Deaktiviere Antivirus und versuche es. Ich hatte auch dieses Problem ... aber in meinem Fall blockierte Antivirus meine Anwendung, als ich das Antivirusprogramm deaktivierte.

3
Hassan_Jaffrani

Restart IIS- könnte ein Prozess sein, der an den Debugger angehängt ist

3
Alan

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 Tabs geschlossen, die ich in VS geöffnet hatte, VS geschlossen und dann sichergestellt, dass alle MSBuild-Prozesse im Taskmanager 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. Nach einigen Code-Refactoring-Vorgängen, dem Verschieben von Projekten in eine Lösung und aus dieser heraus, referenzierten meine Projektverweise nicht mehr wie erwartet auf die Projekte in der Lösung.

Dieses irreführende visuelle Studio lässt vermuten, dass es einige Projekte gleichzeitig erstellen könnte, wodurch die Dateisperren erstellt werden.

BEARBEITEN: Bei VS2012 war dies auch in letzter Zeit ein paar Mal der Fall, und es behebt das Problem, wenn ich die Build-Reihenfolge auf die richtigen Abhängigkeiten eingestellt habe, alle msbuild-Prozesse, die VS ausgeführt hat, beenden und VS neu starten. Ich töte die Msbuild-Prozesse nur um sicher zu sein, aber das Schließen von VS sollte sie auch abtöten.

Was ich normalerweise tue, um dies zu bewirken, ist ein Refactor eines Projekts, so dass es auf ein anderes Projekt in der Lösung angewiesen ist, auf das beim letzten Build nicht verwiesen wurde. Dies scheint manchmal VS zu verwirren und die Build-Reihenfolge wird nicht aktualisiert.

So überprüfen Sie die Build-Reihenfolge: Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Lösung, wählen Sie "Project Build Order ..." und überprüfen Sie, ob die Abhängigkeiten für jedes Projekt richtig angegeben sind.

3
Kevin Shanahan

Dies wurde mehrmals auf Connect, der Community-Website zur Fehlerberichterstattung von Microsoft, eingereicht. Zu Ihrer Information, ich glaube, dieser Fehler hat Visual Studio seit 2003 befallen und wurde jedes Mal nach RTM behoben. :( Eine der Referenzen lautet wie folgt:

https://connect.Microsoft.com/VisualStudio/feedback/details/568672/handles-to-project-dlls-are-not-released-when-compiling?wa=wsignin1.0

2
Michael

Ich würde vorschlagen, Process Explorer herunterzuladen, um herauszufinden, welcher Prozess die Datei sperrt. Es kann gefunden werden bei:

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

2
Hans Olsson

Dies wird häufig durch Avast verursacht. 

Ich kann meine Projekte normalerweise trotzdem in Release ausführen, aber wenn ich Debugging mache, würde das ziemlich regelmäßig scheitern. 

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

1
James Pusateri

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 wurde.

Nicht sicher, warum DEBUGGING Zugriff auf den Veröffentlichungsordner erfordert, aber das Schließen des Befehlsfensters löste das Problem für mich. 

1
Bassie

Das Umbenennen der EXE- und PUB-Datei hat für mich funktioniert, aber wirklich langweilig. Ich habe auch das Problem, dass ich während einer Debug-Sitzung keine Bearbeitung durchführen konnte. Schließlich bin ich auf die Seite Erweiterte Sicherheitseinstellungen gegangen:

https://msdn.Microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HTPROC%3a11310%22%29; % 2cVERSION% 3dV4.0% 22% 29 & rd = true

Ich hebe die Auswahl auf und wähle das Kontrollkästchen "ClickOnce-Sicherheitseinstellungen aktivieren" erneut aus. Seit einigen Tagen ist es problemlos ...

1
Yee

Wenn keine der oben genannten Methoden funktioniert und Sie eine Konsolenanwendung entwickeln:

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

1
Greg

Als ich mit einem ähnlichen Problem konfrontiert wurde, schien das einzige, was zu funktionieren schien:

  • Klicken Sie mit der rechten Maustaste auf das Projekt, gehen Sie zu Einstellungen, und stellen Sie sicher, dass sowohl der Debug- als auch der Release-Build auf die gleichen Einstellungen abzielen, oder haben Sie die Einstellungen, die die Anwendung laden oder speichern soll.
  • Löschen des Ordners C:\Users (YourUserAccount)\AppData\Local (YourAppName).
  • Sicherstellen, dass keine Dateien, die ich dort hatte, als "blockiert" betrachtet wurden. Wenn Sie mit der rechten Maustaste auf die enthaltenen Dateien meines Projekts klicken, wurde mir klar, dass ein Symbol blockiert wurde und als schlecht angesehen wurde, da es aus dem Internet heruntergeladen wurde. Ich musste auf die Schaltfläche "Blockierung aufheben" klicken (in diesem Beispiel sollten Sie Folgendes überprüfen: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Diese Datei stammt von einem anderen Computer und möglicherweise nicht gesperrt sein, um diesen Computer zu schützen. ").
0
Alexandru

Eine Sache, die mir wirklich geholfen hat, war das Hinzufügen der ".exe" im Debug-Ordner zu den Ausschlüssen meines Anti-Virus.

0

Keine der anderen Antworten funktionierte für mich, aber das Schließen aller geöffneten Registerkarten in Visual Studio scheint das Problem gelöst zu haben.

0
Ian Mercer

Ich habe mehrere Lösungen ausprobiert, die Sie zur Verfügung gestellt haben, aber gelegentlich erhalte ich immer noch diesen Fehler. Ich bin sicher, dass mein Prozess nicht ausgeführt wird, und wenn ich versuche, die ausführbare Datei mit Internet Explorer zu löschen, wird sie aus der Dateiliste entfernt, aber dann drücke ich F5 und voila, die Datei ist wieder da. Es wurde überhaupt nicht gelöscht. 

Wenn ich jedoch die Datei über den TotalCommander lösche, wird die Exe-Datei tatsächlich gelöscht und das Projekt kann erfolgreich erstellt werden.

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

0
Gico

Bei Windows-Diensten, die WCF verwenden, wurde der WFC-Host-Prozess beendet, und es funktionierte. Ich hasse es, wenn dies passiert, und es geschieht gelegentlich zufällig.

0
ShaunnyBwoy

Mache 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" in meinem Windows-Dienst (den ich normalerweise von einer Konsole aus testen) ausgeführt.

Dies sperrte einige meiner DLLs im Ordner bin des Windows-Dienstprojekts. Wenn ich eine Neuerstellung durchführte, bekam ich die Ausnahme in diesem Problem.

Ich habe den Windows-Dienst angehalten, neu aufgebaut und es war erfolgreich.

Überprüfen Sie den Windows-Task-Manager für Ihre Anwendung, bevor Sie weitere Schritte in diesem Problem durchführen.

Wenn Sie also Schritte hören, denken Sie, Pferde nicht Zebras! (von einem medizinischen Studentenfreund)

0
GregJF

Für den Fall, dass jemand beim Versuch, einen Unit-Test zu debuggen oder einen Unit-Test auszuführen, auf dieses Problem stößt, musste ich die folgenden zwei Prozesse beenden, damit die Datei freigegeben werden konnte:

 processes to kill.

0
Haggis777

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

Nach langen Nachforschungen stellte sich heraus, dass ich in einer meiner Dateien eine unvollständige Pragma-Warnanweisung hatte, die den Erfolg der Kompilierung nicht verhinderte, aber VS irgendwie verwirrte, weil die Dateien gesperrt waren.

In meinem Fall hatte ich oben in der Datei Folgendes:

#pragma warning(

Das ist es. Ich vermute, ich habe vor einiger Zeit versucht, etwas zu tun, wurde abgelenkt und beendete den Prozess nie, aber die VS-Warnungen bezüglich dieser bestimmten Linie gingen im Shuffle verloren. Irgendwann bemerkte ich die Warnung, entfernte die Leitung und arbeitete seitdem jedes Mal neu.

0
Chris

Ich hatte das gleiche Problem. Es sagte, konnte nicht von bin\debug nach obj kopieren .....

Wenn ich ein Webprojekt baue, fand ich, dass meine DLL alle im Ordner bin und nicht in bin\debug. Während des Veröffentlichen 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 die gesamte DLL als bin\debug\mylibrary.dll erwähnt wurde. Ich habe alles\debug aus dem Pfad entfernt und erneut veröffentlicht. Diesmal konnte vs alle dll im bin-Ordner finden und erfolgreich veröffentlichen.

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

Ich verbrachte mehr als 5 Stunden damit, dieses Problem zu beheben und fand schließlich eine Lösung für mich.

Dies ist das richtige Antwort.

0
nccsbim071

[Gelöst] Exe-Datei kann nicht aus obj\debug nach bin\debug kopiert werden:

Ich gehe davon aus, dass Sie diese Fehlermeldung erhalten, während Sie versucht haben, zwei Fenster nacheinander auszuführen, z. B. zuerst ein Formular zu laden, dann verschwindet es manchmal automatisch und das zweite Formular wird auf den Bildschirm geladen.

Grundsätzlich müssen Sie Ihr erstes Formular, das im Hintergrund ausgeführt wird, und den Hauptgrund für diesen Fehler schließen.

Um das erste Formular zu schließen, müssen Sie diese beiden Codezeilen im zweiten Formularladeereignishandler hinzufügen.

        Form1 form = new Form1();
        form.Close();

Dies löst den Fehler perfekt.

0
Sabir Al Fateh

Durch das erneute Aktivieren des Application Experience -Dienstes von Windows wurden diese Probleme für mich behoben.

Siehe die folgenden Links:

Ich hatte das Problem bei der Verwendung von Visual Studio 2008, 2010 und 2013 mit Windows 7 64-Bit.

0
Wollmich

Ich habe mit VS2013 festgestellt, dass ich diesen Fehler regelmäßig bekomme. Etwas, das einigermaßen gut funktioniert, ist die Durchführung einer Rebuild-Lösung, bevor die Anwendung ausgeführt wird. Ich habe festgestellt, dass das Ausführen eines CLEAN manchmal funktioniert, aber die Rebuild-Lösung scheint konstanter zu sein.

0
mattpm

Dies hilft mir, nachdem ich das schreibgeschützte Flag aus dem bin-Verzeichnis entfernt habe. http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name

0
Suhan
  1. Legen Sie ein anderes Projekt als Start fest
  2. Erstellen Sie das Projekt (das nicht problematische Projekt wird angezeigt)
  3. Wechseln Sie in den problematischen Ordner bin\debug
  4. Umbenennen von myservice.vshost.exe in myservice.exe
0
Peter PitLock

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

Das Problem war eigentlich darauf zurückzuführen, dass der Build fehlschlug und nicht der richtige Fehler ausgegeben wurde .. 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 ich den Bereich von "a" nach außerhalb der Funktion geändert oder "a" nach Task.Factory.StartNew(); nicht verwendet hatte, konnte ich erneut bauen.

Dies ist bei der Verwendung von VS2012 Update 4 unter Windows7x64 SP1 der Fall.

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 es wurde nicht gefunden.

0
T.Coutlakis