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

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.

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 eine einfache Lösung gefunden: Deaktivieren Sie einfach die Windows-Indizierungsdienste für den Projektordner und die Unterordner

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.

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.

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.

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

Deaktivieren Sie "Visual Studio-Hosting-Prozess aktivieren".

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

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

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.

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

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.

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.

Dies wurde mehrfach auf Connect, der Community-Website zur Fehlerberichterstattung von Microsoft, abgelegt. Zu Ihrer Information, ich glaube, dieser Fehler hat Visual Studio seit 2003 heimgesucht 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

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)

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 .

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.

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.

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

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.

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:

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.

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.

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.

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. ").

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.

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 .

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.