Lepaskan menghasilkan file .pdb, mengapa?


264

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


18
Mengapa menghasilkan pdb di realease? Jadi, ketika laporan kerusakan datang dari alam, Anda memiliki informasi untuk debug itu. Nilai lainnya adalah bahwa pelanggan dapat men-debug-nya ketika penulis asli tidak mau.
Ian Boyd

@IanBoyd: Kalimat kedua dari komentar itu menyiratkan, bahwa Anda menggunakan PDB. Ini adalah sebagian besar kasus yang tidak diinginkan.
IInspectable

3
@IInspectable Atau diinginkan
Ian Boyd

@IanBoyd: Sebagian besar kasus tidak termasuk penyebaran OS. Selain itu, PDB tersebut tidak mengandung simbol pribadi, yang disertakan secara default, saat Anda menghasilkan PDB.
IInspectable

@IInspectable Di sisi lain, melepaskan PBDs adalah diinginkan. Idealnya, ya, semua orang akan menulis kode yang dikompilasi ke IL, sehingga kita bisa mendapatkan informasi simbol sendiri. Tetapi kompiler kode asli masih tidak memiliki cara mudah untuk mendukung debugging di lapangan.
Ian Boyd

Jawaban:


416

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.


19
"Anda tidak dapat membuat file PDB setelah kompilasi." - Jika kode sumber Anda tidak berubah maka Anda dapat membangun kembali untuk menghasilkan PDB yang dapat digunakan setelah fakta. Secara default, windbg tidak akan memuat PDB ini, tetapi Anda dapat memaksanya memuat dengan menentukan opsi / i seperti ini .reload /i foo.dll. Itu akan memuat foo.pdb bahkan jika foo.pdb dibuat setelah melepaskan foo.dll.
Marc Sherman

Saya perhatikan bahwa setiap kompilasi baru memiliki hash digest yang berbeda, sehingga ada sedikit perbedaan dengan setiap build bahkan di lingkungan yang sama. Bisakah alamat untuk PDB tidak berubah dengan varians, maka kebutuhan untuk menjaga PDB dari pembangunan itu? Hanya menempatkan ini sebagai ide karena saya tidak benar-benar mengerti bagaimana PDB bekerja atau mengapa hash berubah di antara build.
thebunnyrules

1
@the Dalam catatan kaki, saya menautkan ke sebuah artikel yang menjelaskan bahwa "kompiler C # oleh desain tidak pernah menghasilkan biner yang sama dua kali. Kompiler C # menanamkan GUID yang baru dibuat di setiap perakitan, setiap kali Anda menjalankannya, sehingga memastikan bahwa tidak ada dua rakitan selalu sedikit-untuk-identik. " Itu menjelaskan mengapa ia memiliki hash yang berbeda, dan karena itu file PDB berbeda. Ini dapat diperbaiki dengan hex editor, tetapi tidak ramah pengguna. Dan juga di luar ruang lingkup jawaban ini.
Cody Grey

3
Ada fitur baru di Roslyn yang disebut build deterministic. "Bendera / deterministik menyebabkan kompiler memancarkan EXE / DLL yang sama persis, byte untuk byte, ketika diberi input yang sama." Apa artinya ini adalah proyek yang awalnya dikompilasi dengan flag ini, dapat dikompilasi ulang ke biner yang sama persis, selama kode yang Anda kompilasi sama. Penjelasan yang lebih panjang dapat ditemukan di Deterministic builds di Roslyn
K Smith

92

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.


2
Tetapi mengapa Anda melakukan itu? Jika perangkat lunak Anda siap untuk dirilis, maka Anda seharusnya sudah melakukan semua debugging pada saat itu
m.edmondson

4
Karena Anda dapat men-debug masalah produksi. Suatu ketika kami harus melakukannya.
Aliostad

21
Keuntungan dari menuju PDBs untuk kode produksi adalah .NET akan menggunakan file-file ini ketika melempar pengecualian. Ini menghasilkan jejak tumpukan dengan nama file dan nomor baris, yang seringkali sangat berguna!
Steven

6
@ m.edmondson: Ya, itu benar. Anda masih akan diberi tahu seperti apa pengecualian itu (seperti FileNotFoundException), tetapi Anda tidak akan dapat melihat jejak tumpukan. Itu membuatnya sangat sulit untuk dijabarkan dengan tepat baris kode mana yang menyebabkan pengecualian dibuang.
Cody Gray

2
@ m.edmondson Hanya untuk menambahkan jika Anda mencari alat untuk secara jarak jauh men-debug salah satu masalah di kotak produksi Anda maka windows SDK dilengkapi dengan alat yang sangat terkenal bernama WinDbg yang mendukung debugging jarak jauh. Silakan lihat tautan yang disebutkan di bawah ini. Semoga ini membantu! msdn.microsoft.com/en-in/library/windows/hardware/…
RBT

8

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.


7

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.


5
@ m.edmondson Dapatkan akses ke mesin jarak jauh menggunakan RDP, Webex, dll. dan instal windbg di sana. Atur jalur simbol Anda dan bam, Anda emas!
Marc Sherman

Tautan ke panduan yang lebih rinci akan lebih membantu. How-to-line satu baris ini dapat membuat orang (seperti saya) berada di jalur yang salah. Kebanyakan .NET devs tidak akan tahu apa-apa tentang Windbg misalnya.
nuzzolilo

1
@ m.edmondson - Beberapa edisi Visual Studio memiliki kemampuan untuk melakukan debugging jarak jauh. Dari menu debug Anda "lampirkan ke proses" pada mesin jarak jauh.
Matius

Apakah ide yang bagus untuk men-debug jarak jauh instance aplikasi produksi? Tidakkah itu akan menghentikan eksekusi paralel thread dan memaksanya untuk berjalan secara serial saat debugging?
Kaveh Hadjari

4

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 .


2

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


1
"Tidak perlu file ini saat dirilis atau disebarkan" kecuali ketika seseorang mengalami kerusakan dalam versi yang dirilis, dan laporan kerusakan yang Anda dapatkan dari mereka tidak mengandung jejak stack yang dapat digunakan ... maka Anda akan berharap Anda memasukkannya setelah semua.
Nyerguds

Tidak benar. Tanpa file .pdb Anda akan mendapatkan stacktrace penuh, tetapi tanpa nama file sumber. Anda dapat memulihkannya sendiri setelah menerima laporan kerusakan. Jika Anda peduli tentang hak intelektual Anda dan mengaburkan sumber, Anda harus menyimpan file .pdb tetapi tidak untuk menyebarkannya.
TOP KEK

1

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.


4
Ini akan menghapus SEMUA *.xmlfile, hati-hati dengan itu.
Mariusz Jamro

0

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.


-1

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.


Tapi apa sebenarnya yang akan hilang tanpa file .pdb?
TOP KEK

Anda tidak dapat membuat file PDB setelah kompilasi. Jadi setiap versi perangkat lunak major.minor [.build [.revision]] harus disimpan di Microsoft untuk memahami dengan baik apa yang terjadi, tetapi ini tidak semua.
prosti

Kompiler tidak dijamin untuk menghasilkan binari identik setiap kali Anda mengkompilasi kode yang sama.
prosti

Pertanyaannya adalah apa yang akan hilang dalam laporan kerusakan dan bagaimana pelaporan kerusakan akan terpengaruh. File .NET pdb hanya berisi nama variabel pribadi dan nama file sumber. Segala sesuatu yang lain (nama metode, tanda tangan dll) akan berada di stacktrace dari info metadata.
TOP KEK

Tidak ada file PDB juga berisi data non pribadi: github.com/microsoft/microsoft-pdb .
prosti
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.