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


193

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.


4
Sudahkah Anda memeriksa apakah aplikasi Anda ditutup dengan benar? Apakah task manager menunjukkan kepada Anda [ProjectName] .exe dalam daftar proses?
miensol

2
Saya pernah mengalami ini sebelumnya dan saya hanya mengganti nama file menjadi .old dll dan menjalankan ulang build. Saya tahu bukan perbaikan yang tepat, tetapi itu berhasil bagi saya.
codingbadger

@miensol: Ya, sepertinya menutup dengan benar. Saya mendapatkan "Program '[1848] [ProjectName] .vshost.exe: Managed (v4.0.30319)' telah keluar dengan kode 0 (0x0)." @ Larry: mengganti nama file-exe di bin \ Debug berfungsi, tetapi seperti yang Anda katakan itu bukan solusi dan akan sangat mengganggu harus dilakukan setiap waktu. Sedikit lebih baik daripada memulai kembali Visual Studio ...
Julian

2
@Naliluj: Saya menemukan artikel ini dari sebuah forum Microsoft yang menjelaskan bahwa itu bisa terkait dengan file sumber. Jika Anda menggunakan file resx ini bisa memberikan petunjuk.
Patrick

1
Untuk anak cucu, saya memiliki masalah ini dan diselesaikan dengan menambahkan elemen <GenerateResourceNeverLockTypeAssemblies> true </GenerateResourceNeverLockTypeAssemblies> ke file csproj saya.
ThisIsTheDave

Jawaban:


117

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.


12
Itu adalah salah satu ide gila, saya akan memberikan Anda;) Yang lebih gila lagi, apakah itu benar-benar berfungsi! Saya telah menguji ini beberapa kali sekarang, dan saya dapat mengonfirmasi bahwa ketika menggunakan versi perakitan seperti "2.0. *" Saya mendapatkan kesalahan, tetapi ketika saya menggunakan "2.0.0" itu berfungsi sebagai pesona! Saya mengimbau lebih banyak orang untuk menguji ini, dan jika Anda berhasil, silakan pilih jawaban ini, karena ini adalah sesuatu yang perlu diketahui! Semoga Microsoft mengerti hal ini ... Terima kasih drharris :)
Julian

2
ini tidak berhasil untuk saya, ketika saya memulai kembali VS saya tidak mendapatkan kesalahan untuk suatu saat. Setiap kali saya mendapatkan kesalahan ini, saya harus memulai ulang VS 2010
Sharique

6
fyi ... ini tidak berhasil untukku. Pengaturan saya selalu: [assembly: AssemblyVersion ("1.0.0.0")] [assembly: AssemblyFileVersion ("1.0.0.0")]
tbone

4
Jika saat ini Anda memiliki [assembly: AssemblyVersion ("1.0.0.0")], gantikan dengan [assembly: AssemblyVersion ("2.0.0.0")] (yaitu '2' alih-alih '1'). Ini berhasil untuk saya. Meskipun saya belum memeriksanya, mungkin saja dengan mengubah versi menjadi apa pun selain apa yang Anda miliki sekarang dapat memperbaiki masalah ini.
Frederick The Fool

1
Bekerja untuk dll juga! VS mengatakan tidak dapat menyalin dll dan setelah mengubah KEDUA [assembly: AssemblyVersion] dan [assembly: AssemblyFileVersion ()] dari 1.0. * Ke 2.0.0.0, berhasil.
AZ.

14

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 memilih ini karena ini adalah apa yang saya lakukan di masa lalu. Saya setuju, ini solusi kotor tapi berhasil. VS memiliki masalah ini untuk beberapa iterasi. Saya memuat proyek saya dari dir jaringan juga. Sudah sepenuhnya dipercaya, tapi itu tidak masalah. Tidak masalah apakah itu pemetaan drive atau UNC. Ya, MS benar-benar harus memperbaiki yang ini. Mereka memiliki bug yang ditutup untuk itu mengatakan tidak dapat mereproduksi. Kuno!
Josh Robinson

14

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


2
Ini juga bekerja untuk saya. Saya tidak yakin bahwa saya mengerti mengapa, karena proses explorer menunjukkan devenv.exe memegang pegangan penguncian. Namun demikian, mematikan pengindeksan memperbaiki masalah.
Fopedush

1
@Fopedush Saya mengalami masalah ini dengan solusi yang sama, meskipun saya tidak melihat pertanyaan ini pada saat itu. Jawaban ini memiliki beberapa penjelasan mengapa ini membantu.
Darren Hale

1
Yang ini melakukannya untuk saya.
Martin Capodici

12

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.


1
Saya menemukan laporan bug terbaru tentang masalah ini: connect.microsoft.com/VisualStudio/feedback/details/558848/... Laporan bug itu memberikan contoh proyek yang dapat mereproduksi bug. Solusi yang disarankan oleh drharris juga bekerja di sana (lihat solusi yang diposting di tautan di atas untuk solusi langkah-demi-langkah untuk proyek sampel).
Julian

Ini adalah satu-satunya solusi yang bekerja untuk saya juga. Terima kasih @Nailuj!
Pemain sayap

Ini jelas lebih mudah daripada memulai kembali VS.
Elvedin Hamzagic

1
"Halaman tidak ditemukan" untuk masalah koneksi, apakah mereka hanya menghapusnya karena malu = S Apakah pernah ada solusi / solusi yang diposting untuk ini?
Coops

9

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.


1
Ini bekerja setiap saat untuk saya. Tampaknya ini berkaitan dengan proses vshost yang dihasilkan dan mulai untuk layanan
jaywayco

8

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.


+1 Saya sebelumnya sudah mencoba yang lain (1. task manager, 2. proses explorer yaitu close handle yang mana windows tidak akan membiarkan saya melakukannya, 3. Menonaktifkan antivirus, 4. tidak termasuk APP_DATA / Lokal / Microsoft / Visual Studio dari layanan Windows Indexing. ) tetapi tip ini kembali: "Pengalaman Aplikasi" layanan adalah satu-satunya yang menyelamatkan saya membenturkan kepala ke dinding. Saya mengaktifkannya dan masalahnya hilang. Lucunya, setelah saya nonaktifkan lagi semuanya masih oke. Saya tidak punya masalah lagi. Tapi yang pasti ini satu-satunya yang mengurutkannya untuk saya.
Tomás

Bekerja untukku juga !!! Satu-satunya hal lain yang berfungsi juga adalah menghapus folder bin sebelum menjalankan aplikasi, tetapi Anda harus menghapus selalu sebelum dijalankan, sangat menjengkelkan.
E_Blue

6

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


Saya telah menginstal Avast dan pagi ini saya mendapat kesalahan MVC acak yang mengatakan bahwa dll saya punya virus di dalamnya. Setelah kesalahan, saya tidak bisa lagi membangun proyek MVC saya. Saya menambahkan pengecualian pada Avast File System Shield dan semuanya berfungsi kembali.
Dusty


4

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


Saya setuju - belum tentu VS yang mengunci file. Pemeriksa virus bisa bersalah karenanya. Coba matikan pemeriksa virus Anda untuk melihat apakah itu membantu.
Polyfun

Maaf, saya lupa menyebutkan bahwa saya sudah melakukan itu. Dan dikatakan itu adalah Visual Studio (devenv.exe) yang memiliki kunci pada file ([ProjectName] .vshost.exe). Jadi itu juga tidak banyak membantu saya.
Julian

@ShellShock: menonaktifkan anti virus saya (Avast) juga tidak membantu.
Julian

Bagi saya, menggunakan Sysinternals ProcessExplorer, saya bisa melihat pegangan untuk file itu, tetapi ketika saya mengkliknya, tidak ada aplikasi yang ditampilkan menahannya, dan ketika saya mencoba untuk menutup pegangan, saya mendapatkan "Proses pembukaan kesalahan: pegangannya adalah tidak valid. " kesalahan dalam ProcessExplorer. Namun kuncinya masih berlanjut.
tulang

4

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 Anda melihat di bagian paling atas dari pertanyaan, ada tautan ke Microsoft Connect dengan laporan bug dan proyek sampel yang mereproduksi kesalahan: connect.microsoft.com/VisualStudio/feedback/details/558848/…
Julian

Menonaktifkan proses hosting bekerja untuk saya. Ini terus bekerja setelah mengaktifkannya kembali juga. Saya menghabiskan 4 jam mencoba untuk memperbaiki masalah ini mencoba ratusan solusi. Ini adalah satu-satunya yang bahkan tampaknya bekerja.
Drew Chapin

4

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.


3

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.


Kami baru-baru ini mengalami ini pada proyek WinPhone 8. Entah kenapa, penyebabnya adalah menggunakan tipe Tuple. Menghapus kode yang menggunakan Tuple masalah hilang. Tambahkan kode kembali masalah yang dikembalikan.
Seamus

Saya memiliki masalah yang sama dengan VS2012, penutupan VS tidak melakukan trik - harus membunuh semua tugas msbuild.exe secara manual
mizzle

Saya menggunakan VS 2013 dan saya hanya bisa membunuh proses "XDesProc.exe * 32" (Microsoft Visual Studio XAML UI Designer) di task manager sebelum membangun masing-masing dan yang melakukan trik. Tidak perlu me-restart VS karena desainer XAML UI tampaknya memuat ulang setiap kali Anda membuka file * .xaml dalam tampilan desain.
Tim Sexton

3

Restart IIS- bisa menjadi proses yang dilampirkan ke debugger


3

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


3

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.



1

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)


1

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 .


1

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.


1

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.


1

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


1

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.


1

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:

proses untuk membunuh.


0

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.


0

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


0

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.


0

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

0

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


0

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 .


0

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.

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.