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 der untenstehenden 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 zu einer separaten Frage gehört).


Dies ist eine Frage, die schon mal hier auf Stack Overflow und anderen Stellen gestellt wurde, 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 hat ein paar Basisformen, von denen die meisten anderen Formen erben, es verwendet Entity Framework (und POCO-classn) für den databasezugriff. Nichts Besonderes, kein Multi-Threading oder so.

Problem: Für eine Weile war alles in Ordnung. Visual Studio konnte dann nicht vollständig erstellt werden, als ich die Anwendung starten wollte. Ich habe die Warnung “Datei konnte nicht gelöscht werden … bin \ Debug \ [ProjectName] .exe ‘. Der Zugriff auf den Pfad’ … bin \ Debug \ [ProjectName] .exe ‘wird verweigert.” und der Fehler “Datei ‘obj \ x86 \ Debug \ [Projektname] .exe’ konnte nicht in ‘bin \ Debug \ [Projektname] .exe’ kopiert werden. Der process kann nicht auf die Datei ‘bin \ Debug \ [Projektname] .exe zugreifen “Weil es von einem anderen process verwendet wird.” (Ich bekomme sowohl die Warnung und den Fehler beim Ausführen von Rebuild, aber nur den Fehler beim Ausführen von Build – glaube nicht, dass das relevant ist?)

Ich verstehe ganz gut, was die Warnung und Fehlermeldung sagt: Visual Studio versucht offensichtlich, die Exe-Datei zu überschreiben, während es aus irgendeinem Grund die gleiche Zeit eine Sperre hat. Das hilft mir jedoch nicht, eine Lösung für das Problem zu finden … Das Einzige, was ich gefunden habe, ist, Visual Studio herunterzufahren und neu zu starten. Bauen und Starten funktioniert dann, bis ich einige der 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 vorgeschlagene Lösungen. Ich werde nur aufführen, was ich hier schon 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 Folgendes zum Pre-Build-Ereignis des Projekts hinzu:

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

     true 

Allerdings hat keiner von ihnen für mich funktioniert, also können Sie wahrscheinlich sehen, warum ich ein bisschen frustriert werde. Ich weiß nicht, wo ich sonst noch hinschauen soll, also hoffe ich, dass jemand mir 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 Rundschreiben oder ähnliches, und wenn ja, wie könnte ich es herausfinden?

Irgendwelche Vorschläge werden sehr geschätzt 🙂

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.

Das klingt blöd, aber ich habe alle diese Lösungen ausprobiert, mit VS2010 unter Windows 7. Keiner von ihnen funktionierte, außer der Umbenennung und dem Aufbau, was SEHR mühsam war. Schließlich habe ich den Schuldigen ausfindig gemacht, und ich kann es kaum 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 die Änderung der Version 2.0.0.0 die Arbeit wieder aufgenommen. Ich weiß nicht, ob es ein Windows 7-spezifisches Ding ist (ich benutze es nur für 3-4 Wochen), oder wenn es zufällig ist, oder was, aber es hat es für mich repariert. Ich nehme an, dass VS jede erzeugte Datei im Griff hatte, also wissen würde, wie man Dinge inkrementiert? Ich bin mir wirklich nicht sicher und habe das noch nie zuvor gesehen. Aber wenn jemand da draußen auch ihre Haare auszieht, versuchen Sie es.

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

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

Wie von Barry in einem Kommentar zum ursprünglichen Beitrag vorgeschlagen, ist das manuelle Umbenennen von ‘… bin \ Debug [ProjectName] .exe’ in etwas anderes (zB ‘[ProjectName] 1.exe’ ) ein Workaround (I ‘ Es ist mir jedoch nicht erlaubt, die Datei selbst zu 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 ziemlich schnell (zumindest nachdem du es ein paar Mal gemacht hast, es wird fast zur Routine) und zumindest viel schneller als Visual Studio neu zu starten, was ich am Anfang gemacht habe.

Falls sich jemand wundert, könnte ich hinzufügen, dass ich dieses Problem nur halb zufällig sehe. Das passiert normalerweise, nachdem ich einige Änderungen im Designmodus eines Formulars vorgenommen habe (aber nicht immer). Es passiert normalerweise nicht, wenn ich nur Business-Logik-Code oder nicht-visuellen Code ändern (aber manchmal tut es …). Frustrierend in der Tat, aber zumindest habe ich einen Hack, der für mich funktioniert – lassen Sie uns nur hoffen, dass mein nächstes Projekt auch dieses Problem nicht hat …

@Barry: Wenn du deinen Kommentar würdigen möchtest, kannst du ihn als Antwort posten und ich werde ihn akzeptieren 🙂

Ich habe das gleiche Problem (MSB3021) mit WPF-Projekt in VS2008 (unter Windows 7 x32). Das Problem tritt auf, wenn ich versuche, die Anwendung nach dem vorherigen Lauf zu schnell erneut auszuführen. Nach ein paar Minuten kann exe-Datei von selbst entsperrt werden 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 zu betreiben.

Wenn ich auf dieses Problem gestoßen bin, hat es mit der Tatsache zu tun, dass das Projekt, das ich zu erstellen versuche, als Startup-Projekt in der Lösung gesetzt wird, wodurch die .exe im obj-Ordner gesperrt wird (sie erscheint auch in deinem Task-Manager). 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, sie wird aus dem Aufgabenmanager entfernt und sollte Sie bauen lassen.

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

Zusammengefasst: Wenn Sie den Application Experience-Dienst deaktiviert haben (wie ich es getan habe), aktivieren Sie ihn erneut und starten Sie ihn. Zwei Jahre Ärger haben geendet.

Ich hatte auch ein Problem sehr ähnlich und fand den Grund in meinem Fall war, dass ich den bin \ debug-Ordner als freigegebenen Ordner unter VMware und entweder VMware, Explorer unter dem VM-Gast oder vielleicht sogar ein Antivirus zur Verfügung gestellt hatte Programm unter dem Gast (obwohl ich glaube nicht, dass ich einen installiert hatte) hielt einen Griff zu den Dateien.

Deaktivieren Sie “Visual Studio-Hosting-process aktivieren” Projekt Debug Einstellungen

WENN IHR PROBLEM NOCH NICHT LÖSEN:

Visual Studios Fehler ist:

“Der process kann nicht auf die Datei ‘bin \ Debug ** app.exe **’ zugreifen, da sie von einem anderen process verwendet wird.”

Also, gehen Sie zum Task-Manager von Windows (Strg + Umschalt + Esc), finden Sie Ihren Anwendungsnamen und erzwingen Sie es von Endprocces zu schließen.

Mit Visual Studio konnte ich nie ein einfaches Projekt zur Reproduktion des Fehlers erstellen.

Meine Lösung war, den Visual Studio Hosting-process zu deaktivieren.

Für Interessierte habe ich eine Handle Trace für den betreffenden Griff angebracht:

 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 

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 gab an, dass die Datei vom XAML-UI-Designer verwendet wurde.

Ich schloss alle Tabs, die ich in VS geöffnet hatte, schloss VS und stellte dann sicher, dass alle MSBuild-processe 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 dem Code-Refactoring und dem Verschieben von Projekten in und aus einer Lösung verwiesen meine Projektreferenzen nicht mehr wie erwartet auf die Projekte in der Lösung.

Dies führt dazu, dass Visual Studio denkt, dass es einige Projekte gleichzeitig erstellen könnte, wodurch die Dateisperren erstellt werden.

EDIT: Ich hatte dieses passiert einige Male sogar vor kurzem mit VS2012 und es repariert es, sobald ich die Build-Reihenfolge auf die richtigen Abhängigkeiten festlegen, beenden Sie alle Msbuild-processe, die VS ausgeführt, und starten Sie VS neu. Ich töte die Msbuild-processe, um sicher zu sein, aber Schließen VS sollte sie auch töten.

In der Regel reformiere ich ein Projekt so, dass es auf ein anderes Projekt innerhalb der Lösung angewiesen ist, das beim letzten Build nicht referenziert wurde. Dies scheint VS manchmal zu verwirren und es aktualisiert die Build-Reihenfolge nicht.

So überprüfen Sie die Erstellungsreihenfolge: Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Projektmappe und wählen Sie “Projektauftragsreihenfolge …” aus, und vergewissern Sie sich, dass die Abhängigkeiten für jedes Projekt ordnungsgemäß notiert sind.

Neustart IIS – könnte ein process sein, der an den Debugger angehängt ist

Deaktivieren Sie Antivirus und versuchen Sie es. Ich war auch mit diesem Problem konfrontiert … aber in meinem Fall blockierte Antivirus meine Anwendung, wenn ich das Antivirenprogramm triggerse.

Ich hatte denselben Fehler.

Ich triggerse das Problem, indem ich den gesamten Inhalt der Bin- Ordner aller abhängigen Projekte / Bibliotheken löschte.

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

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

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

Dies wurde mehrfach auf Connect, der Community-Fehlermeldeseite von Microsoft, eingereicht. FYI, ich glaube, dass dieser Fehler Visual Studio seit 2003 betrifft und jedes Mal nach RTM behoben wurde. 🙁 Eine der Referenzen ist wie folgt:

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

Wenn keiner der obigen Schritte funktioniert und Sie eine Konsolenanwendung entwickeln:

Geben Sie ein beliebiges Zeichen in Program.cs ein und löschen Sie es anschließend. Ich habe keine Ahnung, warum das funktioniert, aber es scheint das Problem “Nicht kopieren” jedes Mal zu lösen.

Dies wird eher von Avast verursacht.

Ich kann meine Projekte in Release normalerweise unabhängig ausführen, aber wenn ich im Debugger laufe, würde es ziemlich regelmäßig scheitern.

Ich füge einfach einen Ausschluss für meinen Projektordner hinzu und das Problem scheint wegzugehen. Ich nehme an, dass dies auch durch andere Antivirensoftware verursacht werden kann.

Das Umbenennen der .exe und .pub Datei funktionierte für mich, aber wirklich mühsam. Ich habe auch das Problem, dass ich während einer Debug-Sitzung keine Bearbeitung vornehmen konnte. Schließlich ging ich auf die Einstellungsseite für die erweiterte Sicherheit:

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-%22.NETFRAMEWORK%2cVERSION % 3dV4.0% 22% 29 & rd = wahr

Ich entferne die Auswahl und wähle dann das Kontrollkästchen “ClickOnce-Sicherheitseinstellungen aktivieren” erneut aus. Es ist seit einigen Tagen problemfrei.

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

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

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 process nicht läuft, und wenn ich versuche, die ausführbare Datei mit Internet Explorer zu löschen, wird es 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 verwende Windows 7 x64 und insgesamt Commander 7.56a 32 Bit.

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

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 erlebt. Jedes Mal, wenn ich versuchte, ein bestimmtes Projekt neu aufzubauen, bekam ich die Nachricht. Die einzige Lösung war, vor jedem Umbau eine Reinigung durchzuführen.

Nach vielen Nachforschungen stellte sich heraus, dass ich eine unvollständige Pragmawarnung in einer meiner Dateien hatte, die die erfolgreiche Kompilierung nicht verhinderte, aber VS irgendwie dazu brachte, die Datei (en) gesperrt zu halten.

In meinem Fall hatte ich am Anfang der Datei Folgendes:

 #pragma warning( 

Das ist es. Ich schätze, ich habe vor einiger Zeit versucht, etwas zu tun, war abgelenkt und habe den process nie beendet, aber die VS-Warnungen über diese bestimmte Linie gingen verloren. Irgendwann habe ich die Warnung bemerkt, die Leitung entfernt und seitdem immer wieder aufgebaut.

Mach die einfachen Dinge zuerst.

Überprüfen Sie, ob ein Teil Ihrer Lösung nicht durch einen laufenden process gesperrt ist.

Zum Beispiel habe ich “InstallUtil” auf meinem Windows-Dienst ausgeführt (was ich normalerweise Unit-Test von einer Konsole aus).

Dadurch wurden einige meiner DLLs im Ordner “bin” des Windows-Dienstprojekts gesperrt. Als ich einen Neuaufbau gemacht habe, habe ich in dieser Ausgabe die Ausnahme gemacht.

Ich habe den Windows-Dienst gestoppt, neu aufgebaut und es ist gelungen.

Überprüfen Sie den Windows Task-Manager für Ihre Anwendung, bevor Sie einen der vorbereitenden Schritte in diesem Problem ausführen.

Wenn Sie also Schritte hören, denken Sie, Pferde sind keine Zebras! (von Medizinstudenten Freund)

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 Debug- als auch Release-Builds dieselben Einstellungen aufweisen oder dass die Einstellungen darin enthalten sind, die die Anwendung zu laden oder zu speichern versucht.
  • Löschen des Ordners C: \ Benutzer (YourUserAccount) \ AppData \ Local (YourAppName)
  • Stellen Sie sicher, dass keine Dateien, die ich dort hatte, als “Blocked” betrachtet wurden. Wenn ich mit der rechten Maustaste auf die Dateien meines Projekts klickte, merkte ich, dass ein Symbol tatsächlich blockiert und als schlecht angesehen wurde, weil es aus dem Internet heruntergeladen wurde. Ich musste auf die Schaltfläche “Entsperren” klicken (in diesem Beispiel: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png – “Diese Datei kam von einem anderen Computer und wurde möglicherweise blockiert, um zu helfen schütze diesen Computer. “).

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

Meine Lösung hat nichts mit Versionen zu tun, processe werden gesperrt, neu gestartet oder gelöscht.

Das Problem lag tatsächlich daran, dass der Build fehlgeschlagen ist und der richtige Fehler nicht angezeigt wurde. Das eigentliche Problem war ein Designerrors:

 // 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(); 

Nach dem Ändern des Bereichs von “a” nach außerhalb der function oder nicht mit “a” nach Task.Factory.StartNew(); Ich konnte wieder bauen.

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

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, weil sie nicht gefunden wurde .

Ich habe mit VS2013 diesen Fehler regelmäßig gefunden. Etwas, das einigermaßen gut zu funktionieren scheint, besteht darin, eine Rebuild-Lösung durchzuführen, bevor Sie versuchen, die Anwendung auszuführen. Ich fand, dass das Ausführen eines CLEAN manchmal funktioniert, aber die Rebuild Solution scheint konsistenter zu arbeiten.

Ich hatte dasselbe Problem. Es sagte, konnte nicht von bin \ debug zu obj ….. kopieren

Als ich Webprojekt baute, fand ich, dass meine DLL alle im Sortierfachordner und nicht im bin \ debug war. Während des Publizierens wurde nach Dateien in bin \ debug gesucht. 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. Dieses Mal war es möglich, alle dll in bin-Ordner zu finden und erfolgreich zu veröffentlichen.

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

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

Das ist die richtige Antwort .

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