Visual Studio build gagal: tidak dapat menyalin file-exe dari obj \ debug ke bin \ debug

Pembaruan: Proyek sampel yang mereproduksi bug ini dapat ditemukan di sini di Microsoft Connect . Saya juga telah menguji dan memverifikasi bahwa solusi yang diberikan dalam jawaban yang diterima di bawah ini berfungsi pada proyek sampel itu. Jika solusi ini tidak berhasil untuk Anda, Anda mungkin memiliki masalah yang berbeda (yang termasuk dalam pertanyaan terpisah).

Ini adalah pertanyaan yang diajukan sebelumnya, baik di sini di Stack Overflow dan tempat-tempat lain, tetapi tidak ada saran yang saya temukan sejauh ini yang membantu saya, jadi saya hanya perlu mencoba mengajukan pertanyaan baru.

Skenario: Saya memiliki aplikasi Windows Forms yang sederhana (C #, .NET 4.0, Visual Studio 2010). Ini memiliki beberapa bentuk dasar yang sebagian besar bentuk lain dari, menggunakan Kerangka Entitas (dan kelas POCO) untuk akses database. Tidak ada yang mewah, tidak ada multi-threading atau apapun.

Masalah: Semua baik-baik saja untuk sementara waktu. Kemudian, tiba-tiba, Visual Studio gagal membangun ketika saya akan meluncurkan aplikasi. Saya mendapat peringatan "Tidak dapat menghapus file '... bin \ Debug \ [ProjectName] .exe'. Akses ke path '... bin \ Debug \ [ProjectName] .exe' ditolak." dan kesalahan "Tidak dapat menyalin file 'obj \ x86 \ Debug \ [ProjectName] .exe' ke 'bin \ Debug \ [ProjectName] .exe'. Proses tidak dapat mengakses file 'bin \ Debug \ [ProjectName] .exe 'Karena sedang digunakan oleh proses lain. " (Saya mendapatkan peringatan dan kesalahan saat menjalankan Rebuild, tetapi hanya kesalahan saat menjalankan Build - tidakkah itu relevan?)

Saya mengerti betul apa yang dikatakan pesan peringatan dan kesalahan: Visual Studio jelas mencoba menimpa file-exe sementara itu waktu yang sama memiliki kunci di atasnya untuk beberapa alasan. Namun, ini tidak membantu saya menemukan solusi untuk masalah ini ... Satu-satunya hal yang saya temukan berfungsi adalah mematikan Visual Studio dan memulainya lagi. Membangun dan meluncurkan kemudian berfungsi, sampai saya membuat perubahan dalam beberapa bentuk, maka saya memiliki masalah yang sama lagi dan harus memulai kembali ... Cukup frustasi!

Seperti yang saya sebutkan di atas, ini tampaknya menjadi masalah yang diketahui, jadi ada banyak solusi yang disarankan. Saya hanya akan daftar apa yang sudah saya coba di sini, sehingga orang tahu apa yang harus dilewati:

• Membuat solusi bersih baru dan hanya menyalin file dari solusi lama.

• Menambahkan hal berikut ke yang berikut ke acara pra-bangun proyek:

  if exist "$(TargetPath).locked" del "$(TargetPath).locked"
     if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
  

• Menambahkan berikut ini ke properti proyek (file .csproj):

  <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Namun, tidak ada yang bekerja untuk saya, jadi Anda mungkin bisa melihat mengapa saya mulai merasa sedikit frustrasi. Saya tidak tahu harus mencari ke mana lagi, jadi saya berharap ada yang punya sesuatu untuk diberikan kepada saya! Apakah ini bug di VS, dan jika demikian apakah ada patch? Atau apakah saya melakukan sesuatu yang salah, apakah saya memiliki referensi melingkar atau serupa, dan jika demikian bagaimana saya bisa mengetahuinya?

Setiap saran sangat dihargai :)

Pembaruan: Seperti yang disebutkan dalam komentar di bawah, saya juga telah memeriksa menggunakan Process Explorer yang sebenarnya adalah Visual Studio yang mengunci file.

Ini akan terdengar bodoh, tapi saya mencoba semua solusi ini, menjalankan VS2010 pada Windows 7. Tidak satu pun dari mereka yang bekerja kecuali mengganti nama dan membangun, yang SANGAT membosankan untuk sedikitnya. Akhirnya, saya melacak pelakunya, dan saya merasa sulit untuk percaya. Tapi saya menggunakan kode berikut di AssemblyInfo.cs ...

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

Ini cukup umum, tetapi untuk beberapa alasan, mengubah versi ke 2.0.0.0 membuat semuanya berfungsi kembali. Saya tidak tahu apakah itu Windows 7 hal yang spesifik (saya hanya menggunakannya selama 3-4 minggu), atau apakah itu acak, atau apa, tetapi memperbaikinya untuk saya. Saya menduga bahwa VS menjaga setiap file yang dihasilkannya, sehingga ia akan tahu bagaimana cara meningkatkan sesuatu? Saya benar-benar tidak yakin dan belum pernah melihat ini terjadi sebelumnya. Tetapi jika orang lain di luar sana juga mencabut rambut mereka, cobalah.

Karena saya belum mendapatkan umpan balik tentang masalah ini, saya pikir saya hanya akan membagikan apa yang akhirnya menjadi solusi saya:

Seperti yang disarankan oleh Barry dalam komentar pada posting asli, secara manual mengganti nama '... bin \ Debug [ProjectName] .exe' ke sesuatu yang lain (mis. '[ProjectName] 1.exe' ) adalah salah satu solusi (I ' m namun tidak diizinkan untuk menghapus file sendiri, dan saya harus mengatakan saya merasa agak aneh karena orang akan percaya bahwa kunci yang sama mencegah penghapusan juga akan mencegah penggantian nama ...). Ini bukan solusi yang baik, tetapi cepat masuk akal (setidaknya setelah Anda melakukannya beberapa kali, hampir menjadi rutin), dan setidaknya jauh lebih cepat daripada memulai kembali Visual Studio yang merupakan apa yang saya lakukan di awal.

Jika seseorang bertanya-tanya, saya juga bisa menambahkan bahwa saya hanya melihat masalah ini secara semi-acak. Ini biasanya terjadi setelah saya melakukan beberapa perubahan dalam mode desain formulir (tetapi tidak selalu). Biasanya tidak terjadi jika saya hanya mengubah kode logika bisnis atau kode terkait non-visual (tapi kadang-kadang tidak ...). Frustasi memang, tetapi setidaknya saya memiliki retasan yang berfungsi untuk saya - semoga saja proyek saya berikutnya tidak menghadapi masalah ini juga ...

@Barry: jika Anda ingin mendapat pujian atas komentar Anda, jangan ragu untuk mempostingnya sebagai jawaban dan saya akan memastikan untuk menerimanya :)

Saya menemukan satu solusi sederhana, cukup nonaktifkan Windows Indexing Services untuk folder proyek dan subfolder

Saya memiliki masalah yang sama (MSB3021) dengan proyek WPF di VS2008 (pada Windows 7 x32). Masalahnya muncul jika saya mencoba menjalankan kembali aplikasi terlalu cepat setelah dijalankan sebelumnya. Setelah beberapa menit file-exe dibuka dengan sendirinya dan saya dapat menjalankan kembali aplikasi. Tapi jeda yang begitu lama membuatku marah. Satu-satunya hal yang sangat membantu saya adalah menjalankan VS sebagai Administrator.

Ketika saya menemukan masalah ini berkaitan dengan fakta bahwa proyek yang saya coba bangun ditetapkan sebagai proyek Startup dalam solusi membuat .exe di folder obj terkunci (juga muncul di task manager Anda,) klik kanan proyek lain dalam solusi Anda dan pilih setel proyek startup. Ini akan melepaskan kunci, menghapusnya dari task manager dan harus membiarkan Anda membangun.

Saya mencoba semua saran lain dalam jawaban di sini, tidak ada yang berhasil. Akhirnya saya menggunakan Monitor Proses untuk menemukan bahwa .exe saya yang VS2010 gagal untuk dibangun dikunci oleh proses Sistem (PID = 4). Mencari SO untuk situasi yang melibatkan ini menghasilkan jawaban ini .

Ringkasnya: jika Anda menonaktifkan layanan Pengalaman Aplikasi (seperti yang saya lakukan), aktifkan kembali dan mulai saja. Dua tahun kejengkelan berakhir.

Saya juga mempunyai masalah yang sangat mirip dengan ini dan menemukan alasan dalam kasus saya adalah bahwa saya telah membuat folder bin \ debug tersedia sebagai folder bersama di bawah VMware dan VMware, Explorer di bawah tamu VM, atau mungkin bahkan anti-virus Program di bawah tamu (meskipun saya tidak berpikir saya punya satu diinstal) memegang pegangan ke file (s).

Nonaktifkan "Aktifkan proses hosting Visual Studio"

Saya sarankan unduh Process Exploreruntuk mencari tahu proses apa yang mengunci file. Itu dapat ditemukan di:

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

Menggunakan Visual Studio saya tidak pernah bisa menghasilkan proyek sederhana untuk mereproduksi kesalahan.

Solusi saya adalah menonaktifkan proses Visual Studio Hosting.

Bagi yang berminat, saya telah melampirkan jejak pegangan untuk pegangan yang menyinggung:

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

JIKA MASALAH ANDA BELUM DIPENUHI:

Kesalahan Visual studio adalah:

"Proses tidak dapat mengakses file 'bin \ Debug ** app.exe **' karena sedang digunakan oleh proses lain."

Jadi, buka task manager windows (Ctrl + Shift + Esc), cari nama aplikasi Anda dan paksakan untuk menutupnya dengan Endprocces.

Berikut kemungkinan lain:

Setelah menerima kesalahan ini di vs2012 / win7, saya pergi dan mencoba menghapus file di direktori bin dan explorer menunjukkan bahwa file tersebut sedang digunakan oleh XAML UI Designer.

Saya menutup semua tab yang saya buka di VS, menutup VS, kemudian memastikan untuk membunuh semua proses MSBuild di taskmanager. Akhirnya, setelah restart VS saya bisa membangun solusinya.

dan kemungkinan penyebab lain:

Saya telah memperhatikan kemungkinan penyebab lain untuk masalah ini. Setelah melakukan beberapa kode refactoring, memindahkan proyek masuk dan keluar dari solusi, referensi proyek saya tidak lagi merujuk proyek dalam solusi seperti yang diharapkan.

Studio visual yang menyesatkan ini berpikir dapat membangun beberapa proyek secara bersamaan, sehingga menciptakan kunci file.

EDIT: Saya pernah mengalami hal ini pada beberapa kesempatan bahkan baru-baru ini dengan VS2012 dan itu memperbaikinya setelah saya mengatur urutan build ke dependensi yang benar, membunuh semua proses msbuild yang dibiarkan berjalan oleh VS, dan kemudian restart VS. Saya membunuh proses msbuild hanya untuk memastikan, tetapi menutup VS harus mematikannya juga.

Apa yang biasanya saya lakukan untuk menyebabkan ini adalah refactor proyek sehingga bergantung pada proyek lain dalam solusi yang tidak dirujuk pada build terakhir. Ini kadang-kadang tampaknya membingungkan VS dan itu tidak memperbarui urutan pembuatan.

Untuk memeriksa pesanan build: Klik kanan Solution di Solution Explorer dan pilih "Project Build Order ..." dan verifikasi bahwa dependensi dicatat dengan benar untuk setiap proyek.

Restart IIS- bisa menjadi proses yang dilampirkan ke debugger

Nonaktifkan antivirus dan coba. Saya juga menghadapi masalah itu ... tetapi dalam kasus saya antivirus memblokir aplikasi saya ketika saya menonaktifkan antivirus itu diselesaikan.

Saya menghadapi kesalahan yang sama.

Saya memecahkan masalah dengan menghapus semua isi folder bin dari semua proyek / perpustakaan yang tergantung.

Kesalahan ini terutama terjadi karena perubahan versi.

Ini telah diajukan beberapa kali di Connect, situs pelaporan bug komunitas Microsoft. FYI, saya yakin bug ini telah menimpa Visual Studio sejak 2003 dan telah diperbaiki setelah RTM setiap kali. :( Salah satu referensi adalah sebagai berikut:

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

Lakukan hal-hal sederhana terlebih dahulu.

Pastikan bagian dari solusi Anda tidak terkunci oleh proses yang sedang berjalan.

Misalnya, saya menjalankan "InstallUtil 'pada layanan windows saya (yang biasanya saya uji unit dari konsol).

Ini mengunci beberapa dll saya di folder bin proyek layanan windows. Ketika saya melakukan pembangunan kembali, saya mendapat pengecualian dalam masalah ini.

Saya menghentikan layanan windows, dibangun kembali dan berhasil.

Periksa Windows Task Manager untuk Aplikasi Anda, sebelum melakukan langkah-langkah lanjutan dalam masalah ini.

Jadi, ketika Anda mendengar langkah kaki, anggaplah kuda bukan zebra! (dari teman mahasiswa kedokteran)

Saya memiliki masalah yang sama. Dikatakan tidak bisa menyalin dari bin \ debug ke obj .....

Ketika saya membangun proyek web saya menemukan dll saya semua di folder bin dan bukan di bin \ debug. Selama mempublikasikan vs sedang mencari file di bin \ debug. Jadi saya membuka file proyek web di editor dan mencari contoh bin \ debug dan saya menemukan semua dll disebut sebagai bin \ debug \ mylibrary.dll. Saya menghapus semua \ debug dari jalur dan diterbitkan lagi. Kali ini vs berhasil menemukan semua dll di folder bin dan mempublikasikan berhasil.

Saya tidak tahu bagaimana jalur ini diubah dalam file proyek web.

Saya menghabiskan lebih dari 5 jam men-debug ini dan akhirnya menemukan solusi sendiri.

Ini jawaban yang tepat .

Jika tidak ada di atas yang berfungsi, dan Anda sedang mengembangkan aplikasi konsol:

Coba ketikkan karakter apa saja ke dalam Program.cs, lalu hapus. Saya tidak tahu mengapa ini berhasil, tetapi tampaknya untuk menyelesaikan masalah 'Tidak dapat menyalin' setiap saat.

Ini agak umum disebabkan oleh Avast.

Saya biasanya dapat menjalankan proyek saya di Rilis terlepas, tetapi ketika berjalan di debug itu akan gagal secara teratur.

Saya hanya menambahkan pengecualian untuk folder proyek saya dan masalahnya sepertinya hilang. Saya menganggap ini mungkin juga disebabkan oleh perangkat lunak antivirus lain.

Mengganti nama file .exe dan .pub bekerja untuk saya, tetapi sangat membosankan. Saya juga menghadapi masalah yang tidak bisa saya lakukan pengeditan selama sesi debug. Akhirnya saya pergi ke Halaman Pengaturan Keamanan Lanjut, sesuai:

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%28TargetFrameworkMonikerTrack % 3dV4.0% 22% 29 & rd = benar

Saya membatalkan pilihan lalu memilih kembali kotak centang "Aktifkan pengaturan keamanan ClickOnce". Sudah bebas masalah selama beberapa hari sekarang ....

Bagi saya ini disebabkan oleh pembukaan command prompt di folder yang ditargetkan ( C:\users\username\source\repos\project\project\bin\debug\app.publish).

Tidak yakin mengapa DEBUGGING memerlukan akses ke folder publikasikan, tetapi menutup jendela perintah memecahkan masalah bagi saya.

Jika ada orang yang mengalami hal ini ketika mencoba men-debug Tes Unit atau Menjalankan uji unit, saya harus mematikan dua proses berikut agar dapat melepaskan file:

Saya mencoba beberapa solusi yang Anda berikan, tetapi kadang-kadang saya masih menerima kesalahan ini. Saya yakin bahwa proses saya tidak berjalan, dan ketika saya mencoba untuk menghapus file yang dapat dieksekusi dengan internet explorer dihapus dari daftar file, tetapi kemudian saya tekan F5 dan voila, file itu kembali. Itu belum dihapus sama sekali.

Tetapi jika saya menghapus file melalui TotalCommander, file exe sebenarnya dihapus dan saya berhasil membangun proyek.

Saya menggunakan windows 7 x64 dan total komandan 7.56a 32 bit.

Tidak ada jawaban lain yang berfungsi untuk saya tetapi menutup semua tab yang terbuka di Visual Studio tampaknya telah menyelesaikan masalah.

Saya tahu ini adalah pertanyaan yang sangat lama, tetapi saya baru-baru ini mengalami kesalahan "tidak dapat menyalin dari obj ke bin" di VS 2012. Setiap kali saya mencoba membangun kembali proyek tertentu, saya menerima pesan itu. Satu-satunya solusi adalah melakukan pembersihan sebelum setiap pembangunan kembali.

Setelah banyak menyelidiki, ternyata saya memiliki pernyataan peringatan pragma yang tidak lengkap di salah satu file saya yang tidak mencegah kompilasi untuk berhasil, tetapi entah bagaimana membingungkan VS agar file-file tersebut terkunci.

Dalam kasus saya, saya memiliki yang berikut di bagian atas file:

#pragma warning(

Itu dia. Saya kira saya mencoba melakukan sesuatu beberapa waktu lalu dan teralihkan dan tidak pernah menyelesaikan proses, tetapi peringatan VS tentang garis tertentu hilang dalam shuffle. Akhirnya saya memperhatikan peringatan itu, menghapus garis, dan membangun kembali pekerjaan setiap saat sejak itu.

Ketika saya menghadapi masalah yang sama, satu-satunya hal yang tampaknya berhasil adalah:

• Klik kanan proyek, pergi ke Pengaturan, dan pastikan bahwa Debug dan Rilis membangun target pengaturan yang sama, atau memiliki pengaturan di sana bahwa aplikasi mencoba memuat atau menyimpan.
• Menghapus folder C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
• Memastikan bahwa tidak ada file yang saya miliki di sana dianggap "Diblokir". Mengklik kanan file yang disertakan proyek saya, saya menyadari bahwa satu ikon sebenarnya diblokir dan dianggap buruk karena diunduh dari internet. Saya harus mengklik tombol Buka Blokir (misalnya, lihat ini: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "File ini berasal dari komputer lain dan mungkin diblokir untuk membantu lindungi komputer ini. ").

Untuk Layanan Windows menggunakan WCF, saya mengakhiri proses host WFC dan itu berhasil. Aku benci ketika ini terjadi, dan itu terjadi secara acak.

Solusi saya tidak ada hubungannya dengan versi, proses dikunci, restart, atau menghapus file.

Masalahnya sebenarnya karena build gagal, dan tidak memberikan kesalahan yang benar. Masalah sebenarnya adalah cacat desain:

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

Setelah mengubah ruang lingkup "a" ke luar fungsi, atau tidak menggunakan "a" setelah Task.Factory.StartNew();, saya bisa membangun lagi.

Ini terjadi ketika menggunakan Pembaruan 4 VS2012 pada Windows7x64 sp1.

Pesan eror:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (3390,5): kesalahan MSB3030: Tidak dapat menyalin file "obj \ x86 \ Debug \ xxx.exe" karena tidak ditemukan .

Saya telah menemukan dengan VS2013 saya mendapatkan kesalahan ini secara teratur. Sesuatu yang tampaknya bekerja dengan cukup baik adalah dengan menjalankan Solusi Rebuild sebelum mencoba menjalankan aplikasi. Saya menemukan bahwa melakukan CLEAN terkadang berhasil, tetapi Solusi Rebuild tampaknya bekerja lebih konsisten.