“Breakpoint saat ini tidak akan dipukul. Kode sumber berbeda dari versi aslinya. " Apa artinya ini?

514

Ketika debugging di Visual Studio, kadang-kadang saya menambahkan breakpoint tetapi itu kosong dan VS mengatakan "Breakpoint saat ini tidak akan terkena. Kode sumber berbeda dari versi aslinya." Jelas ini mencegah saya untuk dapat melakukan debug.

Apa sih pesannya? Apa versi aslinya? Jika saya baru saja membuka solusi dan tidak membuat perubahan apa pun pada kode, bagaimana mungkin ada 'versi asli'?

.net  visual-studio  debugging 
— David
sumber
36
kompilasi ulang / bangun proyek sebelum menambahkan break-point
— lexu
Apakah Anda membuka proyek yang ditulis dalam versi lain dari studio visual?
— Mahesh Velaga
2
Ini adalah proyek situs web. Seharusnya tidak perlu membangunnya secara eksplisit. Ini harus dikompilasi saat digunakan. Saya curiga VS tidak bisa membangun situs web, tetapi tidak mengatakannya kepada saya! Mahesh - tidak, semua versi VS yang sama
— David
Dalam kasus saya .. Saya memiliki rilis berbeda dari kode yang sama (misalnya test.cs pada versi Live dan versi devolopment .. ketika saya membuka versi devolopment dan meletakkan breakpoint pada test.cs mendapat kesalahan yang sama tetapi saya tahu bahwa saya meletakkan tes breakpoint kelas .cs yang terkait dengan versi live sln tidak devolopment jadi periksa cs telah membangun solusi)
— dankyy1
5
Menghapus direktori bin dan obj daripada membangun kembali bekerja untuk saya.
— Aycan Yaşıt

Jawaban:

277

Seperti dikatakan, "kode sumber berbeda dari versi aslinya".

Klik kanan pada folder proyek di dalam solusi explorer dan pilih untuk Clean. Bangun versi baru proyek dan breakpoint akan bekerja lagi!

— Veedrac
sumber
120
Menggunakan bersih tidak selalu berhasil. Saya harus menghapus semua yang ada di folder bin saya secara manual untuk membuatnya berfungsi kembali.
— Carra
3
Saya keliru memiliki referensi ke DLL di folder bin saya. Memperbaiki jalur referensi tetap.
— Brad Urani
39
Bagi saya, bahkan menghapus folder bin dan obj tidak berfungsi. Saya harus me-restart Visual Studio juga.
— d512
1
Menghabiskan sepanjang hari untuk menemukan solusinya. Terima kasih banyak untuk memberikan solusi.
— Balapan
8
Saya telah menutup VS, menghapus semua folder bin dan obj, membangun kembali semuanya, mengecek konfigurasi build yang sudah diperiksa, build berhasil. Tidak ada dadu. Hal-hal sederhana seharusnya tidak serumit ini. >: |
— snarf
129

Jika Anda telah menghapus centang proyek DLL dalam konfigurasi build Debug , kode baru Anda tidak akan pernah dibuat!

Pergi ke Build --> Configuration Manager ...(di VS2010) dan periksa apakah proyek dengan kode yang Anda coba debug diperiksa untuk konfigurasi pembangunan saat ini.

— Oliver
sumber
Terima kasih atas sarannya Oliver. Itu pasti tidak terjadi di sini, saya akan melihat dengan cepat jika salah satu proyek saya tidak dibangun.
— David
3
Saya memiliki masalah yang persis sama, hanya saja tidak ada yang tidak diperiksa. itu hanya dibangun untuk x86 dalam dialog itu, sedangkan mesin lokal saya adalah x64! Jadi saya memilih Any CPUopsi dan itu berfungsi lagi.
— JP Hellemons
3
Menghapus proyek dari konfigurasi debug tanpa alasan yang valid harus menjadi dosa besar, karena konfigurasi itu mungkin digunakan oleh mesin build CI (saya tahu itu ada di sini), jadi pada akhirnya bisa lewat ketika itu harus gagal. Saya tahu itu bisa menjadi salah satu dari banyak langkah membangun tetapi masih ... @Saya harap anggota tim membelikan Anda beberapa biskuit! :)
— Fetchez la vache
Saya punya masalah ini ketika saya beralih ke build untuk x86, bukannya AnyCPU. Itu menghapus proyek yang sedang dibangun karena alasan yang tidak diketahui.
— Adam Pedley
Proyek ini terdaftar untuk Build in configuration manager jadi ini tidak membantu saya, saya takut :(
— Ortund
43

Bagi saya itu saat bekerja pada proyek WebSite. Setelah membersihkan folder temp ini saya mendapatkan kembali kesalahan kompiler yang tepat:

  • C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
  • C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Saya akhirnya menyelesaikan masalah ketika saya menemukan bahwa file kelas yang saya sengaja pindah ke subfolder, entah bagaimana muncul kembali di folder root. VS menggunakan yang satu itu sementara saya mengedit yang lain.

— AnthonyVO
sumber
2
Mengosongkan file sementara di direktori windows berhasil buat saya, tepuk tangan!
— ChrisFletcher
7
Saya hanya ingin menambahkan jawaban yang serupa - pastikan, bahwa tidak ada salinan lama dll proyek Anda ada di folder sementara yang digunakan ASP.NET, seperti C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ File ASP.NET Sementara - sebagaimana disebutkan - tetapi juga C: \ Windows \ Microsoft.NET \ Framework_64_ \ v4.0.30319 \ File ASP.NET Sementara . Saya menggunakan Semuanya untuk mencari salinan-salinan itu dengan cepat .
— Oliver
12
Hanya petunjuk singkat: mengetik %localappdata%di kotak pencarian akan membawa Anda langsung keC:\Documents and Settings\%username%\AppData\Local
— dav_i
1
Dapat mengkonfirmasi ini bekerja untuk saya di Visual Studio 2013 di proyek layanan web.
— Moeri
Melakukan semua ini tetapi tampaknya tidak membantu. Saya sangat senang melihat ini juga.
— Ortund
40

Apakah kamu pernah melakukan ini?

Apakah Anda ingin melanjutkan dan menjalankan build sukses terakhir?

Jika Anda mencentang kotak dan menekan "Ya", Anda akan berhasil menjalankan build terakhir meskipun proyek Anda tidak dikompilasi. Ini berarti bahwa setiap kali Anda menetapkan breakpoint, Anda akan mendapatkan kesalahan itu.

Coba ubah nilai ini:

  • Alat
    • Pilihan
      • Proyek dan Solusi
        • Bangun dan Lari
          • Saat Dijalankan, saat kesalahan membangun atau penyebaran terjadi: Jangan Luncurkan
— Codesleuth
sumber
Saya tidak berpikir saya telah melakukan itu. Terima kasih untuk tautannya. Itu memberi saya wawasan tentang apa artinya prompt itu!
— David
11
Visual Studio memiliki opsi ini selama beberapa dekade sekarang (setidaknya VS98 memilikinya). Saya tidak pernah mengerti mengapa ada orang yang ingin menjalankan bangunan sukses terakhir. Lagi pula, jika itu yang saya inginkan, saya akan meluncurkannya secara langsung, karena saya toh tidak bisa melakukan debug. Jangan Luncurkan akan menjadi standar yang lebih masuk akal.
— OregonGhost
6
Saya telah menggunakannya beberapa kali untuk menjalankan proyek (untuk alasan apa pun, seperti hanya untuk menunjukkan kepada orang lain) sementara saya masih di tengah penulisan kode yang tidak dapat dikompilasi. Terkadang itu berguna. Secara pribadi, saya membiarkannya dinonaktifkan.
— Codesleuth
3
Mungkin jika mereka harus menunjukkan atasan mereka ketika dia tiba-tiba datang. Mereka bisa menekan f5 dan menjadi seperti "Anda tahu, itu berhasil!"
— Gigala
33

Pergi ke

  • Alat
    • Pilihan
      • Debugging
        • Umum

Hapus tanda centang Memerlukan file sumber agar sama persis dengan versi aslinya

— Rachmad
sumber
17
@Rachmad Solusi ini berfungsi. Tapi sepertinya itu bukan solusi yang lengkap, karena itu berarti file sumber kami tidak sama persis dengan versi aslinya
— onmyway133
Inilah yang saya cari dengan @entropy benar. Meskipun ini memungkinkan breakpoint untuk diatur, faktanya adalah bahwa sumber yang digunakan tidak cocok dengan pdb yang digunakan. Solusi terbaik adalah memperbaikinya. Di saat-saat yang tidak dapat dilakukan, ini bekerja dengan baik.
— JamesG
Bahkan dengan ini tidak dicentang, eksekusi tidak mencapai titik breakpoint dan kesalahan berlanjut
— Ortund
12
Ini BUKAN solusi untuk masalah ini tetapi solusi. Jelas saya tidak ingin bekerja dengan file yang sudah ketinggalan zaman di debugger.
— Obi Wan
2
@ ObiWan Tidak jelas. Saya suka melakukan pengeditan kecil dan melanjutkan debug meskipun mengetahui sumber dan pembuatannya berbeda.
— Alan Baljeu
30

Pilih Debug di Konfigurasi Solusi , bukan Rilis

tangkapan layar menu

— AdiKonstantin
sumber
1
Ini masalah saya. Saya telah dikompilasi dalam mode debug, mengubah kode, lalu menjalankannya dalam mode rilis. Tidak heran debugger berpikir kode itu berbeda - simbol-simbol debug yang berbeda. Ketika saya menghapus folder bin seperti yang disarankan orang lain, saya mendapatkan kesalahan "tidak ada simbol yang dimuat untuk dokumen ini." Baru saat itulah saya membuat koneksi, dan membuat jalan saya untuk jawaban ini. Perlu lebih banyak suara!
— indot_brad
Dimungkinkan untuk proyek dinonaktifkan untuk membangun bahkan dalam konfigurasi membangun Debug. Diperlukan pemeriksaan konfigurasi build, flip-flopping antara konfigurasi Debug / Release tidak ada gunanya.
— Asad Saeeduddin
Ini juga untukku. mencoba membersihkan, membangun kembali solusi yang dirujuk lainnya tidak berhasil. Tidak menyadari solusinya menatap wajah saya
— Adam Hey
Inilah yang terjadi dengan saya - saya sedang membangun proyek saya dan mengganti dll saya berulang kali tetapi masalahnya tidak akan hilang. Saya menyadari kode sedang dibangun dalam mode Rilis sementara saya mengganti dll dari / bin / debug folder. Bodohnya aku.
— displayName
Saya ingin melampirkan ke proses yang dibangun dalam mode rilis. Beralih ke debug memecahkan masalah saya.
— Fivef
27

Perhatikan jendela "Output" di VS. Ini akan memberi tahu Anda apa majelis yang dimuat dan kapan. Anda mungkin melihat bahwa versi perakitan Anda yang lebih lama di suatu tempat di folder sedang dimuat.

Misalnya jika Anda memiliki banyak majelis dan saat ini Anda mencoba masuk ke salah satu majelis dukungan, CLR akan menangani penyelesaian majelis, yang dapat memuat file perakitan lain dari pada yang Anda rujuk dalam proyek.

— Tormod
sumber
1
Juga patut diingat, tapi saya tidak berpikir itu masalah di sini karena saya mencoba masuk ke proyek situs web, bukan perpustakaan kelas.
— David
24

Menutup Visual Studio dan membuka kembali solusinya dapat memperbaiki masalah, yaitu bug di dalam IDE itu sendiri (saya menjalankan VS2010).

Jika Anda memiliki lebih dari satu contoh menjalankan Visual Studio, Anda hanya perlu menutup contoh menjalankan solusi dengan masalah.

— Luke Whyte
sumber
4
Menutup Visual Studio juga berfungsi untuk saya. Juga, dengan tindakan Clean / Rebuild.
— danielB
3
Ini memperbaiki solusi di VS 2015
— TaintedLemon
3
Memperbaiki masalah pada VS 2017
— Daniel Fisher lennybacon
Memperbaiki masalah pada VS 2012
— seebiscuit
19

Cara baru untuk mendapatkan masalah ini telah muncul pada Visual Studio 2017 15.3.1 hingga 15.3.5. Jika Anda menggunakan EditorConfig , charset=utf8opsi menyebabkan gejala-gejala ini. Tim VS telah mereproduksi ini dan mengatakan mereka sedang mengerjakannya .

Jadi satu perbaikan adalah mengomentari charset=utf8baris Anda di file .editorconfig.

Sunting: Ini harus diperbaiki pada VS 15.5.

— John Hatton
sumber
Statusnya sekarang adalah "Fixed - pending release" pada dua hari yang lalu (9 Oktober 2017). Itu adalah kabar baik, karena UTF-8 adalah satu-satunya standar yang waras untuk penyandian teks hari ini. :-)
— rmunn
Saya juga memperhatikan bahwa penyebab utama dari masalah ini adalah perbaikan bug yang lain , di mana charset=utf8ditafsirkan sebagai "UTF-8 dengan BOM". Mengubah interpretasi itu menjadi "tanpa BOM" memecahkan beberapa file UTF-8 yang memiliki BOM di dalamnya. Jadi jika Anda mengalami masalah ini dan perbaikan Visual Studio belum dirilis, coba hapus BOM dari awal file teks Anda dan itu dapat memperbaiki masalah tersebut. (Komentar ini meminta referensi Zero Wing ... :-))
— rmunn
Ini juga masalah bagi saya. Saat ini, ini belum diperbaiki atau setidaknya dirilis atau bug diperkenalkan kembali (versi 15.4.2)
— avidenic
12

Ini sering terjadi juga jika Anda menggunakan referensi file ke binari (alih-alih referensi proyek ke kode dalam proyek Anda), dan biner yang dikompilasi yang Anda referensi tidak sinkron dengan kode sumber yang sesuai pada mesin Anda. Ini bisa terjadi karena Anda mengunduh versi baru dari biner dari kontrol sumber tanpa kode sumber baru yang menyertainya, atau Anda memiliki beberapa versi biner di mesin Anda dan merujuk salinan lama, dll. Jika ini memang masalahnya, itu alasan yang baik untuk menggunakan referensi proyek sebanyak itu praktis.

— Stijn
sumber
Saya mengerti maksud Anda, dan itu perlu diingat untuk masa depan, tetapi sumber yang dimaksud di sini adalah proyek situs web, bukan perpustakaan kelas.
— David
Ini adalah masalah umum ketika mengambil kode warisan yang membuat saya menggaruk-garuk kepala saya bertanya-tanya yang jenius memutuskan untuk referensi dll dari proyek dalam solusi yang hanya pernah digunakan oleh proyek lain dalam solusi. desah
— Kell
10

Bagi saya, tidak ada item yang menyelesaikan masalah. Saya baru saja menambahkan baris kode baru di dalam fungsi itu, seperti:

int a=0;

dengan menambahkan itu, saya kira saya memicu studio visual untuk menambahkan fungsi ini ke versi aslinya

— Mehrdad Babaki
sumber
7

Ini dapat terjadi ketika waktu sistem berubah saat debugging atau di antara sesi debug, baik secara program, secara manual atau dengan program eksternal.

— Tomi
sumber
Saya tidak bisa memberi ini +1 dengan cukup. Saya baru-baru ini menginstal ulang Windows dan tidak melihat jam sistem saya mati. Benar saja, perubahan ini mengacaukan segalanya, dan membangun kembali seluruh solusi / proyek secara ajaib memperbaikinya.
— Kyle Baran
7

Ada pengaturan yang hampir tidak terlihat yang memperbaiki masalah ini untuk saya. Jika ada file sumber tertentu di mana breakpoint tidak mengenai, itu bisa didaftar di

  • Penjelajah solusi
    • klik kanan Solusi
      • Properti
        • Properti Umum
          • File Sumber Debug
            • "Jangan mencari file sumber ini".

Untuk beberapa alasan yang tidak diketahui oleh saya, VS 2013 memutuskan untuk menempatkan file sumber di sana, dan kemudian, saya tidak bisa menekan breakpoint dalam file itu lagi. Ini mungkin penyebab "kode sumber berbeda dari versi aslinya".

— JBSnorro
sumber
Saya menghadapi masalah yang sama persis. Jawaban Anda memang membantu saya! Terima kasih! +1
— jweyrich
5

Masalahnya adalah bahwa info debug Anda tidak sinkron dengan perakitan Anda. Solusinya sederhana:

  1. Buka folder bin Anda
  2. Hapus file .pdb
  3. Membangun kembali

Harus melakukan trik!

(Yang aneh adalah, membangun kembali tanpa membuang file .pdb tidak selalu berfungsi. Saya dapat melihat tanggal yang dimodifikasi diperbarui, tetapi masih di suatu tempat dalam rantai (VS2013 debugger, IIS, cache perakitan) perubahan ini tidak terdeteksi )

— FrankyHollywood
sumber
Build-> Clean Solution juga harus menyelesaikan menghapus file yang perlu dihapus.
— Dave
Setelah kehilangan banyak waktu karena masalah ini, solusi ini berhasil. Thx FrankyHollywood
— AD
4

Anda bisa mendapatkan pesan ini saat Anda menggunakan aktivator dan unit tempat Anda menetapkan breakpoint belum dimuat.

Breakpoint akan teratasi setelah aktivator memuat rakitan (dengan asumsi simbol rakitan dan debug diperbarui). Tempat yang baik untuk dilihat adalah jendela modul di menu debugging. Di sana Anda harus mencari majelis yang milik file Anda juga. Pertama periksa apakah rakitan sudah dimuat. Lalu, dari mana itu dimuat? Lalu, apakah file simbol dimuat. Lagi, dari mana file simbol diambil? Akhirnya periksa versi keduanya.

— Stijn
sumber
4

Saya juga mengalami ini. Kondisi yang menyebabkan masalah saya:

  • Saya menjalankan contoh IIS7 lengkap secara lokal
  • Saya versi perangkat lunak saya ke proyek-proyek terpisah

Saya telah menyebabkan ini dengan membuka versi sebelumnya (VS diminta untuk bertanya apakah saya ingin menunjukkan contoh ini dalam debugging IIS, saya menjawab 'Ya'), kemudian membuka versi saat ini (sekali lagi menanggapi permintaan IIS dengan 'Ya' ), lalu mencoba melakukan debug di versi sebelumnya.

Untuk menyelesaikannya, saya hanya menutup dan membuka kembali versi sebelumnya dan yang dimaksudkan, sekali lagi menyatakannya sebagai sumber debug.

— baker.nole
sumber
3

Coba nonaktifkan dan atur ulang breakpoint saat menjalankan dalam mode debug alih-alih melakukannya sebelum meluncurkan mode debug.

— mikeTheLiar
sumber
3

Ini terjadi juga ketika men-debug proyek C ++ yang memuat modul yang telah diimplementasikan dengan beberapa bahasa CRL (Managed C ++, C # dll). Dalam situasi ini, pesan kesalahan memang menyesatkan.

Solusinya adalah dengan meletakkan properti konfigurasi dukungan Common language runtime (CLR) ke proyek startup dan kompilasi ulang itu.

— Stijn
sumber
3

Jika Anda memiliki lebih dari satu proyek dalam solusi Anda , maka pastikan bahwa proyek yang benar ditetapkan sebagai StartUp Project. Untuk menetapkan proyek tertentu sebagai Proyek Startup dari solusi Anda, Klik kanan proyek, pilih Set As StartUp Project.

Setelah saya mengatur Proyek StartUp saya dengan benar, break-point yang diinginkan tercapai oleh utas.

— nama tampilan
sumber
Layak juga dicatat bahwa jika breakpoint Anda berada dalam proyek yang BUKAN proyek startup Anda, dan itu TIDAK BISA dijadikan proyek startup Anda (karena misalnya Anda harus memiliki proyek yang berbeda menjadi yang startup) Anda dapat (setelah memulai yang utama) klik kanan dan pilih Debug >> Mulai Contoh Baru dari proyek yang memiliki breakpoint di mana Anda ingin menekan
— Caius Jard
3

Saya mengalami ini dalam membangun 32bit di vs2017.

Tidak ada solusi yang tepat untuk saya. Saya restart, saya membersihkan file IDE, membersihkan solusi yang dibangun, menarik dari git repo dan membangun kembali solusi tanpa hasil.

Saya menarik dependensi 64bit dari nuget dan segera setelah saya menggunakan perakitan, sumber tidak dibangun ke dalam executable akhir lagi dan bukannya sumber cache cache sedang dibangun.

Saya menghapus konfigurasi nuget, menghapus rujukan yang direferensikan, mengunduh sumber, membuat log4net secara manual, menandatanganinya, menambahkannya ke folder di proyek saya, menambahkan referensi ke sana, dan saya dapat men-debug lagi.

Ini menyebalkan, saya harap itu muncul dalam daftar jawaban untuk dilihat semua orang.

Sunting: Tidak ada kesalahan selama pembuatan meskipun memiliki opsi "prompt pada kesalahan membangun" dihidupkan dalam pengaturan IDE.

— nurettin
sumber
3

Bagi saya solusinya disembunyikan di Advanced Build Settingsproperti proyek: masukkan deskripsi gambar di sini

Untuk alasan yang tidak diketahui itu diatur ke none: mengaturnya untuk fullmenyebabkan breakpoint terkena.

Untuk sampai ke dialog ini, buka properti proyek, lalu pergi ke Build, lalu pilih Advanced...tombol di bagian bawah halaman.

— riqitang
sumber
3

Saya memiliki masalah yang sama di beberapa proyek dalam proyek arsitektur berlapis dan masalahnya adalah dalam konfigurasi kotak centang build untuk proyek yang dipilih belum diperiksa. jadi masalah itu diperbaiki untuk satu proyek.

Untuk satu lapisan lain ia memberikan masalah yang sama ini bahkan membangunnya memungkinkan dalam konfigurasi. Saya melakukan semua opsi lain seperti memulai kembali membersihkan proyek tetapi tidak ada yang membantu. Akhirnya saya menghapus centang pada kotak centang build untuk proyek tersebut dan membersihkan dan membangun kembali. lagi menandai kotak centang dan melakukan hal yang sama. kemudian masalah itu diperbaiki.

Semoga ini membantu..

— Priyankara
sumber
2

Dalam kasus saya, saya melampirkan proses yang sedang berjalan di VS 2012. Saat melampirkan, Anda diberikan opsi untuk melakukan debug dalam berbagai mode (asli, skrip, silverlight, managed 2.0, managed 4.0, etc). Secara default, debugger memilih mode secara otomatis. Namun Otomatis tidak selalu membuat pilihan yang benar. Jika proses Anda berisi beberapa jenis kode, pastikan debugger menggunakan yang benar.

— nada diam
sumber
Dalam kasus saya, saya melampirkan w3wp.exe ke debug. Kode NET tetapi untuk beberapa alasan itu melampirkan debugger Script yang tidak dapat melihat breakpoint C # saya. Mengubahnya menjadi .NET debugger memungkinkan breakpoint C # saya berfungsi.
— Oran Dennison
2

Dalam kasus saya, saya sedang mengembangkan aplikasi Windows CE, yang diuji terhadap emulator. Masalahnya adalah bahwa executable tidak dikerahkan ke emulator, sehingga .pdb (dalam lingkungan pengembangan) tidak sinkron dengan .exe (dalam emulator), karena .exe baru tidak pernah disalin ke emulator. Saya harus menghapus .exe di emulator untuk memaksa penerapan baru. Lalu berhasil.

— Julen
sumber
2

Apa yang berhasil bagi saya adalah mengubah platform solusi dari x86 ke CPU Apa pun. Setelah berganti ke Any, saya menetapkan berhenti alamat, menjalankan situs web, membuka halaman, mengklik tombol dan berhenti. Saya menutup situs, berubah kembali ke x86 dan berhasil melakukan urutan yang sama.

— John
sumber
2
Mungkin pilihan CPU tidak mempengaruhi masalah sama sekali dan itu hanya fakta bahwa itu memaksa membangun kembali?
— jwg
Ini akan menggunakan folder bin lain, mungkin ada dll lama di peta cpu Anda.
— Carra
Saya punya masalah ini saat platform aktif x86 (yang tidak pernah saya gunakan), beralih kembali ke Win32 memecahkan masalah. PC adalah yang dibagikan sehingga orang lain mengatur platform itu untuk alasan apa pun.
— Zac
2

Di bawah Windows 7, Visual Studio Express 2010, jika Anda telah mengaktifkan opsi Gunakan mode kompatibilitas untuk Windows XP SP3 , kesalahan ini dapat terjadi.

Saya menghapus centang pada opsi dan itu berhasil lagi. Klik kanan pada pintasan ke VS atau yang dapat dieksekusi, pilih properti dan kemudian kompatibilitas .

— Pete
sumber
1
Apa yang mungkin terjadi di sini adalah bahwa konfigurasi rilis Anda berubah dari x32 ke x64 ketika Anda menonaktifkan mode kompatibilitas, dan Anda mungkin tidak memiliki semua proyek Anda yang dipilih untuk dibangun di x32. Mengapa proyek tertentu dinonaktifkan untuk build di x32 adalah sesuatu yang harus Anda bicarakan dengan anggota tim Anda.
— Asad Saeeduddin
Persis itulah masalah saya. Terima kasih!
— Johan Holtby
2

Itu terjadi pada saya karena saya punya proyek lain dalam solusi yang tidak membangun. Setelah saya membongkar proyek-proyek yang bermasalah (klik kanan pada proyek di explorer solusi -> Bongkar Proyek), membangun kembali solusi dan berlari lagi - breakpoint terpukul!

— Sarah
sumber
2

Itu bahagia berada di Visual Studio 2017 setelah saya menambahkan file yang ada ke proyek. Ini bekerja untuk saya:

  1. tutup solusinya,
  2. pergi ke SolutionFolder\.vs\SolutionName\v15\sqlite3dan hapusstorage.ide
  3. buka solusinya lagi
— Laurian
sumber
Terima kasih atas solusi ini! Tidak ada yang sebelum bekerja, dan ini menyelamatkan hari saya :)
— StefanaB
2

Pastikan Anda tidak dalam Mode Rilis ketika Anda mencoba untuk debug.

— Masuk
sumber
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.