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


113

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.


1
win7 terkadang mengunci file yang sedang dilihat di explorer, jadi pastikan folder debug Anda tidak terbuka.
Necrolis

Saya pikir proses Sistem menggunakannya.
Trần Minh

1
Bisa berupa kunci, atau beberapa idiot yang ditambahkan / bin ke kontrol sumber, dan sekarang file dilindungi dari penulisan (klik kanan pada bin, hapus centang pada proteksi tulis).
Stefan Steiger

3
Ini lebih buruk di Visual Studio 2017 daripada sebelumnya.
Rob Lyndon

1
Dalam kasus saya MSBuild.exemenahan file, cukup akhiri proses di Task Manager
Pierre

Jawaban:


120

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>


1
Ini masih terjadi (bagi saya) di VS2013. Itu selalu file PDB untuk proyek WPF dalam solusi saya yang terkunci di direktori target. Menutup semua desainer tidak berhasil (boo!) Tetapi mengganti nama file berhasil (terima kasih, Cody!). Peretasan raksasa mengundang ...
Jon

2
Ini mulai terjadi pada saya sejak kemarin ketika saya mengupgrade ke vS 2013 ... ini tidak pernah terjadi pada saya sejak VS 2008 ... sangat menyedihkan.
SomeNickName

8
VS 2015, dan saya masih memiliki masalah.
Berin Loritsch

13
Ini terjadi di Visual Studio 17, dan memulai ulang Visual Studio tidak membantu.
Rob Lyndon

2
@jairhumberto tidak ada alasan untuk snark itu, komputer sudah cukup membuat frustrasi, tidak perlu menyampaikannya kepada orang lain .. tetapi ini berfungsi untuk saya untuk masalah khusus ini, mungkin Anda mengalami sesuatu yang berbeda! Lihat: stackoverflow.com/a/19649014/27494
ScottN

64

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"

1
Di mana saya dapat menemukan Pre-Buildacara itu di formulir windows saya ??
Unknownymous

2
@qwerty Itu ditemukan di properti proyek di bawah bagian Build Events atau jika Anda berada di proyek VB.net, di bawah bagian Compile, Anda akan melihat tombol Build Events.
ScottN

@ScottN: oh BTW, pre-buildkode ini juga merupakan obat untuk aplikasi yang diterapkan (melalui clickonce) ketika aplikasi saya berjalan maka terjadi bug / kesalahan kemudian pada pengelola tugas, saya akan mengakhiri tugas saya myApp.exetetapi tidak akan MENGAKHIRI TUGAS dan itu meminta ERROR ON ENDING TASK?
Unknownymous

@qwerty Tidak, ini tidak terkait dengan aplikasi yang diterapkan ClickOnce. Kesalahan ini hanya ketika Anda membangun aplikasi Anda selama pengembangan dan pengujian dan hanya di Visual Studio, bukan untuk aplikasi yang disebarkan yang berjalan pada sistem klien.
ScottN

Apa yang dimaksud .locked?
Shimmy Weitzhandler

22

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

Bekerja untuk saya!


2
Saya telah menonaktifkan layanan ini beberapa bulan yang lalu. Mengaktifkannya sekarang tampaknya menyelesaikan masalah di Visual Studio (tidak dapat menyalin karena file exe terkunci). Saya bertanya-tanya mengapa layanan ini perlu dijalankan, apa yang saya baca tentangnya tampaknya tidak terkait dengan apa pun yang relevan untuk kesalahan ini (mis. Blackviper.com/windows-services/application-experience ).
Andreas Jansson

10
Saya memiliki layanan ini berjalan tetapi masih mendapatkan masalah kunci.
antfx

1
+1 Wow, saya mencoba / semua yang saya temukan. Akhirnya tersandung ini untuk memperbaikinya. Punyaku juga dinonaktifkan. Tidak akan pernah mengira itu sebagai pelakunya!
John S.

Menjalankan Windows 7 SP1 dengan VS2010 SP1, mengaktifkan layanan "Pengalaman Aplikasi" segera membantu saya. Terima kasih banyak. Tetapi satu menit kemudian mematikannya tidak segera mereproduksi masalah.
Jimm Chen

7
layanan tidak ditemukan di windows 10
JerryGoyal

13

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

1
Jangan mencobanya pada proyek besar ... Pembuatan ulang penuh membutuhkan waktu sangat lama.
mBardos

7

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.


7

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.

masukkan deskripsi gambar di sini


2

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.


1

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


Setidaknya dalam kasus saya, saya telah memperhatikan bahwa studio visual sedang membuat proses hantu msbuild.exe, yang tidak binasa setelah dibangun. Zombie-zombie ini tampaknya menyebabkan kunci file muncul. Tapi tidak ada petunjuk bagaimana mengatasinya. Membunuh msbuild.exe's adalah solusi satu kali, itu perlu dilakukan per build.
TarmoPikaro

1

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

VS 2013; Menangkan 8;


1

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.


1

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.


1

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


1

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


0

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.


0

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


0

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)


0

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.


0

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.


0

Pra membangun perintah

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

Membantu


0

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


0

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


0

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"


0

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


0

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.


0

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.


0

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


-1

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.