Kesalahan: Tidak dapat mengakses file bin / Debug /… karena sedang digunakan oleh proses lain

Ketika saya men-debug proyek saya, saya mendapatkan kesalahan berikut:

"Tidak dapat menyalin file" obj \ Debug \ My Dream.exe "ke" bin \ Debug \ My Dream.exe ". Proses tidak dapat mengakses file 'bin \ Debug \ My Dream.exe' karena sedang digunakan oleh orang lain proses."

Menggunakan Process Explorer, saya melihat bahwa MyApplication.exe keluar tetapi proses Sistem masih menggunakannya meskipun saya menghentikan debug sebelumnya. Setiap kali saya mengubah kode saya dan memulai debug, itu akan terjadi. Jika saya menyalin proyek ke USB dan debug, itu berjalan OK.

Mengapa? Bagaimana cara memperbaiki kesalahan ini?

Saya menggunakan Window 7 Professional. Dengan Xp saya tidak pernah mendapatkan kesalahan ini.

Ugh, ini masalah lama, sesuatu yang masih muncul di Visual Studio sesekali. Itu menggigit saya beberapa kali dan saya kehilangan waktu berjam-jam untuk memulai kembali dan bertarung dengan VS. Saya yakin sudah dibahas di sini di SO lebih dari sekali. Ini juga telah dibicarakan di forum MSDN. Tidak ada solusi sebenarnya, tetapi ada beberapa solusi. Mulailah meneliti di sini .

Apa yang terjadi adalah VS memperoleh kunci pada file dan kemudian tidak melepaskannya. Ironisnya, kunci itu mencegah VS itu sendiri dari menghapus file sehingga dapat membuatnya kembali ketika Anda membangun kembali aplikasi. Satu-satunya solusi yang jelas adalah menutup dan memulai ulang VS sehingga akan melepaskan kunci pada file.

Solusi asli saya adalah membuka folder bin / Debug dan mengganti nama file yang dapat dieksekusi. Anda tidak dapat menghapusnya jika terkunci, tetapi Anda dapat mengganti namanya. Jadi Anda bisa menambahkan angka di akhir atau sesuatu, yang memungkinkan Anda tetap bekerja tanpa harus menutup semua jendela Anda dan menunggu VS dimulai ulang. Beberapa orang bahkan telah mengotomatiskan ini menggunakan acara pra-bangun untuk menambahkan string acak ke akhir nama file keluaran lama. Ya, ini adalah peretasan raksasa , tetapi masalah ini menjadi sangat membuat frustrasi dan melemahkan sehingga Anda akan melakukan apa saja.

Saya kemudian mengetahui, setelah sedikit lebih bereksperimen, bahwa masalahnya tampaknya hanya muncul ketika Anda membangun proyek dengan salah satu perancang terbuka. Jadi, solusi yang telah bekerja untuk saya dalam jangka panjang dan mencegah saya untuk berurusan dengan salah satu kesalahan konyol itu lagi adalah memastikan bahwa saya selalu menutup semua jendela desainer sebelum membangun proyek WinForms. Ya, ini juga agak merepotkan, tapi pasti mengalahkan celananya harus restart VS dua kali satu jam atau lebih.

Saya berasumsi ini juga berlaku untuk WPF, meskipun saya tidak menggunakannya dan secara pribadi belum mengalami masalah di sana.

Saya juga belum mencoba mereproduksinya di VS 2012 RC. Saya tidak tahu apakah sudah diperbaiki di sana atau belum. Tapi pengalaman saya sejauh ini adalah bahwa itu masih bisa muncul bahkan setelah Microsoft mengklaim telah memperbaikinya. Masih ada di VS 2010 SP1. Saya tidak mengatakan programmer mereka idiot yang tidak tahu apa yang mereka lakukan, tentunya. Menurut saya hanya ada beberapa penyebab bug dan / atau sangat sulit untuk mereproduksi secara andal di laboratorium. Itulah alasan yang sama saya tidak secara pribadi mengajukan laporan bug apa pun padanya (meskipun saya telah memberi +1 pada orang lain), karena sepertinya saya tidak dapat mereproduksinya dengan andal, seperti Manusia Salju yang Menjijikkan.

_{<kata-kata kasar akhir yang tidak ditujukan kepada siapa pun secara khusus>}

Saya pernah mengalami kesalahan ini sebelumnya, bahkan di Visual Studio 2008. Itu kembali dan lebih umum di Visual Studio 2012.

Inilah yang saya lakukan.

Tempelkan ini di acara pra-bangun proyek yang merepotkan:

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

Komputer (klik kanan) -> kelola -> Layanan & Aplikasi -> layanan -> Aktifkan pengalaman Aplikasi

Bekerja untuk saya!

Saya mengalami masalah yang sama di Visual Studio 2013. Saya tidak yakin apa yang menyebabkan ini untuk proyek saya, tetapi saya dapat memperbaikinya dengan membersihkan solusi dan membangunnya kembali.

1. Bangun> Solusi Bersih
2. Build> Rebuild Solution

Setidaknya dalam kasus saya, saya telah memperhatikan bahwa visual studio 2012 membuat setidaknya dua proses hantu msbuild.exe, yang tidak binasa setelah dibangun. Zombie-zombie ini tampaknya menyebabkan kunci file muncul.

Membunuh msbuild.exe's adalah solusi satu kali, itu perlu dilakukan per build.

Tetapi kemudian saya menemukan bahwa saya dapat menonaktifkan pembangunan paralel sekali dan untuk selamanya - masuk ke Alat> Opsi> Proyek dan Solusi> Bangun dan Jalankan> "jumlah maksimum pembangunan proyek paralel" - secara default nilainya 8, saya sudah beralih ke 1. Bekerja seperti pesona.

Tentu saja pembuatannya sedikit lebih lambat sekarang, tetapi lebih baik aman daripada menyesal. Setidaknya untuk proyek kecil khusus ini saya tidak membutuhkan lebih dari satu utas pembuatan.

Saya mengerti ini adalah pertanyaan lama. Sayangnya saya menghadapi masalah yang sama dengan .net core 2.0aplikasi saya di visual studio 2017. Jadi, saya berpikir untuk membagikan solusi yang berhasil untuk saya. Sebelum solusi ini saya telah mencoba langkah-langkah di bawah ini.

1. Studio visual yang dimulai ulang
2. Tutup semua aplikasi
3. Bersihkan solusi saya dan bangun kembali

Tak satu pun dari langkah-langkah di atas tidak memperbaiki masalah.

Dan kemudian saya membuka proses saya Task Managerdan yang dipilih dotnetdan kemudian mengklik tombol Akhiri tugas. Kemudian saya membuka Visual Studio saya dan semuanya berfungsi dengan baik.

Lihat jawaban saya di sini jika Anda mengalami masalah ini saat menjalankan pengujian unit. Jawaban disalin di bawah:

Berdasarkan jawaban Sébastien, saya menambahkan langkah pra-bangun ke proyek pengujian saya untuk secara otomatis mematikan semua vstest.*file yang dapat dieksekusi yang masih berjalan. Perintah pra-bangun berikut berfungsi untuk saya:

taskkill /f /im vstest.*
exit 0

The exit 0perintah pada akhir untuk mencegah kegagalan membangun ketika tidak ada vstest.*executable berjalan.

Baru-baru ini saya mengalami masalah dengan Visual Studio 2012 dengan deskripsi kesalahan yang sama: "Proses tidak dapat mengakses file karena sedang digunakan oleh proses lain ..."

Untuk mengatasinya pertama-tama Anda perlu memahami aplikasi yang masih menggunakannya. Saya telah mematikan semua proses seperti "MSBuild" dan "MSBuild host". Tapi ini belum cukup. Jika Anda telah menginstal "Kontrak Kode" dan dihidupkan maka DLL Anda kadang-kadang diperlukan untuk memeriksa dan menutup operasi ini.

Jadi, Anda perlu menghentikan semua proses "CCCheck.exe" dan itu saja.

Terakhir, untuk memahami bahwa proses menggunakan DLL Anda, Anda selalu dapat mencoba menghapus folder "obj" di Manajer File Anda dan operasi ini akan gagal, Anda mungkin melihat "Jendela Pesan" dengan deskripsi operasi gantung. Selain itu, sebagai varian, Anda dapat mencoba menggunakan aplikasi "Sys Internals Suite".

Bekerja untuk saya. Manajer Tugas -> Nama proyek -> Tugas akhir. (Saya memiliki 3 proses yang sama dengan nama proyek saya);

VS 2013; Menangkan 8;

Pastikan bahwa proses aplikasi sebelumnya (misalnya, memulai tanpa opsi debugging) benar-benar dihentikan. Saya sedang mengerjakan aplikasi WPF, memulai tanpa debugging dan meminimalkannya ketika saya terus mendapatkan kesalahan. Setelah menutup aplikasi VS perilaku kembali normal.

Saya telah diganggu oleh masalah ini di Visual Studio 2017. Ini dimulai sekitar dua atau tiga minggu yang lalu, dan telah sangat menggerogoti produktivitas saya. Bersihkan dan Rebulid belum berfungsi; bahkan me-restart mesin saya tidak berhasil.

Salah satu cara untuk mengatasi masalah ini adalah dengan membersihkan rakitan yang melanggar, dan membangun (bukan membangun kembali) proyek yang ingin Anda jalankan segera setelahnya. Ini bekerja sekitar 30% dari waktu.

Namun, mungkin solusi paling andal yang saya temukan adalah membuka Developer Command Prompt, dan menggunakannya msbuildsecara langsung. Saya telah melakukan ini selama tiga hari terakhir, dan sejauh ini masalahnya belum pernah terjadi.

Dalam kasus saya adalah bahwa saya telah mengaktifkan "Show All Files". Visual Studio 2017

Lari taskmanager.
Temukan netcoredan hapus.
Anda kemudian dapat menghapus file secara manual atau dengan menjalankan Clean.

Ini murni spekulasi, dan bukan jawaban.

Namun, saya mengalami masalah ini cukup lama.

Saya datang setelah beberapa waktu untuk mencurigai interaksi antara VS dan tindakan pencegahan AV saya.

Setelah beberapa kali bermain, tampaknya itu mungkin hilang ketika saya memodifikasi antivirus saya sehingga semuanya ada di bawah

C: \ Users [nama pengguna] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

folder tidak termasuk dalam perlindungan real-time.

Sepertinya build benar-benar menulis DLL di sini terlebih dahulu, lalu menyalinnya ke lokasi build terakhir.

Mungkin sudah terlambat. Tapi, saya mengalami masalah serupa dan dalam kasus saya proyek tersebut memiliki referensi sendiri. Karenanya, menghapusnya dari Referensi bekerja seperti pesona !!!

Saya telah menemukan cara tercepat tanpa menutup formulir atau memulai ulang VisualStudio adalah pergi ke halaman kompilasi proyek dan klik tombol "Advanced Compile Options ...". Kemudian buat perubahan apa pun ke salah satu opsi (misalnya, mengubah Hasilkan Info Debug dari Penuh ke hanya pdb), lalu klik OK. Ini berfungsi setiap saat dan harus dilakukan sampai MS memperbaiki bug ini (saya tidak pernah mengalami masalah ini sampai saya beralih dari VS2012 ke VS2013)

Catatan lain, jika Anda tidak dapat membersihkan proyek atau solusi, itu tidak akan dibangun. File pasti dikunci oleh VS (bukan masalah antivirus, setidaknya tidak dalam kasus saya)

Saya mencoba semua saran ini serta saran lain yang ditemukan di tempat lain dan satu-satunya hal yang berhasil untuk saya adalah memulai ulang komputer saya. Kemudian saya melakukan solusi bersih diikuti dengan membangun kembali. Saya menggunakan Visual Studio 2013 untuk referensi.

Saya telah mengalami masalah yang sama ini, dan yang saya temukan adalah sebenarnya menjalankan aplikasi bentuk Windows mulitple di latar belakang. Itu terjadi ketika aplikasi Anda memiliki dua formulir dan Anda menutup formulir ke - 2 yang bukan formulir utama Anda sehingga aplikasi tidak akan keluar sepenuhnya.

Saya biasanya menjalankan aplikasi saya

• melalui exe-nya atau
• berjalan tanpa debugging

Solusi adalah menutup contoh lain dari aplikasi formulir Windows . Ini adalah salah satu cara untuk selalu menutup instance aplikasi Anda.

Pra membangun perintah

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

Membantu

[Dipecahkan] Kesalahan: Tidak dapat mengakses file bin / Debug /… karena sedang digunakan oleh proses lain:

Saya mendekati bahwa Anda mendapatkan kesalahan ini saat Anda mencoba menjalankan dua bentuk jendela satu demi satu seperti pertama memuat formulir kemudian setelah itu kadang-kadang akan hilang secara otomatis dan formulir kedua dimuat ke layar.

Pada dasarnya, Anda harus menutup formulir pertama Anda yang berjalan di latar belakang dan alasan utama di balik kesalahan ini.

Untuk menutup formulir pertama, Anda harus menambahkan dua baris kode ini di penanganan peristiwa beban formulir kedua.

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

Ini akan menyelesaikan kesalahan dengan sempurna.

Salah satu solusi sederhana adalah Anda pergi ke folder bin \ Debug, hapus semua file di folder itu, lalu buat ulang. Jika tidak berhasil, tutup Visual Studio lalu masuk ke folder bin \ Debug menggunakan file explorer, di coner kiri, klik File> Open Command Prompt> Open Command Prompt as Administrator> Masukkan perintah ini "DEL / F / Q / A * "> lalu buat kembali

Saya menemukan jawaban Cody Gray sebagian membantu, karena itu mengarahkan saya ke sumber sebenarnya dari masalah saya yang mungkin juga dialami oleh beberapa dari Anda: eksekusi uji studio visual tetap terbuka secara default dan mempertahankan kunci pada file.

Untuk menghentikan perilaku yang sebagian besar tidak berguna tersebut, ikuti petunjuk dari https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0 -50727-1-rtmrel

Hapus centang menu Test -> Test Settings -> "Keep Test Execution Engine Running"

Masalah saya adalah dotnet terputus dan setiap kali VS mencoba membuat dll baru, atau mengakses yang lama, proses dotnet akan mengunci ke dll dan menghentikan studio visual untuk mengkloning dll. Solusi hanya untuk mengakhiri semua tugas dotnet di task manager (itu hanya akan benar-benar menghapus yang mati, jika Anda mencoba untuk mengakhirinya dan tidak mau ditutup, itu berarti berfungsi).

Tutup VisualStudio, ctrl-alt-delete, pilih Task Manager, temukan dan akhiri semua proses MSBuild - VisualStudio pada dasarnya memiliki bug yang cukup parah di mana ia kehilangan kendali atas debuggernya dan debugger mempertahankan kunci pada file .pdb di debug / bin map. Setelah Anda mengakhiri semua proses MSBuild (debugger), Hapus folder / debug / bin dan buka kembali solusi Anda di Visual Studio. Anda baik untuk pergi sekarang. Microsoft perlu memperbaiki omong kosong ini.

Saya telah membuka pertanyaan terpisah mengenai VS 2017 yang memiliki perilaku serupa setelah satu pembaruan. Masalahnya tampaknya dihasilkan oleh program antivirus.

Saya telah menambahkan folder bin ke daftar pengecualian antivirus, menghidupkan ulang mesin dan sekarang tampaknya berfungsi.

Saya memecahkan masalah ini ..

dekat debug Anda melihat menu drop-down dengan beberapa konfigurasi. Default ada CPU Apa Pun. Pilih x86 dan jalankan program itu akan bekerja. Jika x86 tidak ada, buka manajer konfigurasi dan tambahkan x86

Kludge lain, ugh, tapi itu mudah dan bekerja untuk saya di VS 2013. Klik pada proyek. Di panel properti harus ada entri bernama File Proyek dengan nilai

(nama proyek Anda) .vbproj

Ubah nama proyek - seperti menambahkan -01 di akhir. File .zip asli yang dikunci masih ada, tetapi tidak lagi direferensikan ... sehingga pekerjaan Anda dapat dilanjutkan. Lain kali komputer di-boot ulang, kunci itu menghilang dan Anda dapat menghapus file yang salah.