Lepaskan menghasilkan file .pdb, mengapa?

Mengapa Visual Studio 2005 menghasilkan .pdbfile saat kompilasi dalam rilis? Saya tidak akan men-debug build rilis, jadi mengapa itu dibuat?

Karena tanpa file PDB, tidak mungkin untuk men-debug membangun "Rilis" oleh apa pun selain debug tingkat alamat. Optimalisasi benar-benar melakukan angka pada kode Anda, sehingga sangat sulit untuk menemukan pelakunya jika terjadi kesalahan (katakanlah, pengecualian dilemparkan). Bahkan pengaturan breakpoint sangat sulit, karena garis kode sumber tidak dapat dicocokkan satu-ke-satu dengan (atau bahkan dalam urutan yang sama) kode perakitan yang dihasilkan. File PDB membantu Anda dan debugger keluar, membuat debugging post-mortem secara signifikan lebih mudah.

Anda menyatakan bahwa jika perangkat lunak Anda siap dirilis, Anda harus sudah melakukan semua proses debug pada saat itu. Meskipun itu benar, ada beberapa poin penting yang perlu diingat:

1. Anda juga harus menguji dan men-debug aplikasi Anda (sebelum Anda melepaskannya) menggunakan build "Release". Itu karena mengaktifkan optimisasi (dinonaktifkan secara default di bawah konfigurasi "Debug") kadang-kadang dapat menyebabkan bug halus muncul yang Anda tidak akan tangkap. Saat Anda melakukan debugging ini, Anda akan menginginkan simbol PDB.

2. Pelanggan sering melaporkan kasus tepi dan bug yang hanya muncul dalam kondisi "ideal". Ini adalah hal-hal yang hampir mustahil untuk direproduksi di lab karena mereka bergantung pada beberapa konfigurasi aneh dari mesin pengguna itu. Jika mereka pelanggan yang sangat membantu, mereka akan melaporkan pengecualian yang dilemparkan dan memberi Anda jejak tumpukan. Atau mereka bahkan akan membiarkan Anda meminjam mesin mereka untuk men-debug perangkat lunak Anda dari jarak jauh. Dalam salah satu kasus tersebut, Anda ingin file PDB membantu Anda.

3. Pembuatan profil harus selalu dilakukan di "Rilis" build dengan optimisasi diaktifkan. Dan sekali lagi, file PDB sangat berguna, karena memungkinkan instruksi perakitan diprofilkan untuk dipetakan kembali ke kode sumber yang sebenarnya Anda tulis.

Anda tidak dapat kembali dan menghasilkan file PDB setelah kompilasi. ^* Jika Anda tidak membuatnya selama pembangunan, Anda kehilangan kesempatan. Tidak ada ruginya membuat itu. Jika Anda tidak ingin mendistribusikannya, Anda bisa menghilangkannya dari binari Anda. Tetapi jika Anda kemudian memutuskan untuk menginginkannya, Anda kurang beruntung. Lebih baik untuk selalu menghasilkan dan mengarsipkan salinan, kalau-kalau Anda membutuhkannya.

Jika Anda benar-benar ingin mematikannya, itu selalu merupakan pilihan. Di jendela Properti proyek Anda, setel opsi "Info Debug" ke "tidak ada" untuk konfigurasi apa pun yang ingin Anda ubah.

Apakah dicatat, bagaimanapun, bahwa "Debug" dan "Release" konfigurasi lakukan oleh pengaturan penggunaan default yang berbeda untuk memancarkan informasi debug. Anda ingin mempertahankan pengaturan ini. Opsi "Info Debug" diatur ke "penuh" untuk build Debug, yang berarti bahwa selain file PDB, informasi simbol debugging disematkan ke dalam perakitan. Anda juga mendapatkan simbol yang mendukung fitur keren seperti edit-dan-lanjutkan. Dalam mode Rilis, opsi "pdb-only" dipilih, yang, seperti kedengarannya, hanya menyertakan file PDB, tanpa memengaruhi konten rakitan. Jadi itu tidak sesederhana hanya ada atau tidak adanya file PDB di /bindirektori Anda . Tetapi dengan asumsi Anda menggunakan opsi "pdb-only", file PDB '

_{^* Seperti yang ditunjukkan Marc Sherman dalam komentar , selama kode sumber Anda tidak berubah (atau Anda dapat mengambil kode asli dari sistem kontrol versi), Anda dapat membangunnya kembali dan menghasilkan file PDB yang cocok. Setidaknya, biasanya. Ini berfungsi dengan baik sebagian besar waktu, tetapi kompiler tidak dijamin untuk menghasilkan biner identik setiap kali Anda mengkompilasi kode yang sama , sehingga mungkin ada perbedaan yang halus. Lebih buruk lagi, jika Anda telah melakukan peningkatan pada rantai alat Anda untuk sementara waktu (seperti menerapkan paket layanan untuk Visual Studio), PDB bahkan cenderung tidak cocok. Untuk menjamin generasi ex postfacto yang andalFile PDB, Anda perlu mengarsipkan tidak hanya kode sumber di sistem kontrol versi Anda, tetapi juga binari untuk seluruh rantai alat bangun Anda untuk memastikan bahwa Anda dapat membuat ulang konfigurasi lingkungan bangunan Anda dengan tepat. Tak perlu dikatakan bahwa lebih mudah untuk hanya membuat dan mengarsipkan file PDB.}

PDB dapat dihasilkan untuk Releasemaupun untuk Debug. Ini diatur pada (dalam VS2010 tetapi dalam VS2005 harus serupa):

Project → Properties → Build → Advanced → Info Debug

Ubah saja menjadi None.

Tanpa file .pdb, hampir mustahil untuk menelusuri kode produksi; Anda harus bergantung pada alat lain yang bisa memakan biaya dan waktu. Saya mengerti Anda dapat menggunakan tracing atau windbg misalnya tetapi itu benar-benar tergantung pada apa yang ingin Anda capai. Dalam skenario tertentu Anda hanya ingin melangkah melalui kode jarak jauh (tidak ada kesalahan atau pengecualian) menggunakan data produksi untuk mengamati perilaku tertentu, dan ini adalah di mana file .pdb berguna. Tanpa mereka menjalankan debugger pada kode itu tidak mungkin.

Mengapa Anda begitu yakin Anda tidak akan men-debug rilis build? Kadang-kadang (semoga jarang tetapi terjadi) Anda mungkin mendapatkan laporan cacat dari pelanggan yang tidak dapat direproduksi dalam versi debug karena beberapa alasan (timing berbeda, perilaku berbeda kecil atau apa pun). Jika masalah itu tampaknya dapat direproduksi dalam rilis rilis Anda akan senang memiliki pdb yang cocok.

Anda juga dapat menggunakan crash dumps untuk men-debug perangkat lunak Anda. Pelanggan mengirimkannya kepada Anda dan kemudian Anda dapat menggunakannya untuk mengidentifikasi versi yang tepat dari sumber Anda - dan Visual Studio bahkan akan menarik set yang tepat dari simbol debugging (dan sumber jika Anda mengatur dengan benar) menggunakan crash dump. Lihat dokumentasi Microsoft di Toko Simbol .

File .PDB adalah nama pendek dari "Program Database". Ini berisi informasi tentang titik debug untuk debugger dan sumber daya yang digunakan atau referensi. Ini dihasilkan ketika kita membangun sebagai mode debug. Ini memungkinkan aplikasi untuk melakukan debug saat runtime.

Ukurannya adalah peningkatan file .PDB dalam mode debug. Ini digunakan ketika kami menguji aplikasi kami.

Artikel bagus dari file pdb.

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P

Dalam solusi multi-proyek, Anda biasanya ingin memiliki satu konfigurasi yang tidak menghasilkan file PDB atau XML sama sekali. Alih-alih mengubah Debug Infoproperti setiap proyek none, saya pikir akan lebih bijaksana untuk menambahkan acara pasca-pembangunan yang hanya berfungsi dalam konfigurasi tertentu.

Sayangnya, Visual Studio tidak memungkinkan Anda untuk menentukan acara pasca-pembangunan yang berbeda untuk konfigurasi yang berbeda. Jadi saya memutuskan untuk melakukan ini secara manual, dengan mengedit csprojfile proyek startup dan menambahkan yang berikut (bukan PostBuildEventtag yang ada ):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

Sayangnya, ini akan membuat kotak teks event post build kosong dan memasukkan apa pun di dalamnya dapat memiliki hasil yang tidak terduga.

File simbol debug ( .pdb) dan XML doc ( .xml) merupakan persentase besar dari ukuran total dan tidak boleh menjadi bagian dari paket penerapan reguler. Tetapi harus dimungkinkan untuk mengaksesnya jika dibutuhkan.

Satu pendekatan yang mungkin: pada akhir proses pembuatan TFS, pindahkan ke artifak yang terpisah.

Sebenarnya tanpa file PDB dan informasi simbolik yang mereka miliki tidak mungkin membuat laporan kerusakan yang berhasil (file dump memori) dan Microsoft tidak akan memiliki gambaran lengkap apa yang menyebabkan masalah.

Dan memiliki PDB meningkatkan pelaporan kerusakan.