ปล่อยการสร้างไฟล์. pdb ทำไม


264

เหตุใด Visual Studio 2005 จึงสร้าง.pdbไฟล์เมื่อคอมไพล์ในรีลีส? ฉันจะไม่แก้ไขข้อบกพร่องของบิลด์ออกดังนั้นทำไมจึงสร้างขึ้น


18
เหตุใดจึงสร้าง pdb ใน realease ดังนั้นเมื่อรายงานข้อขัดข้องมาจากไวลด์คุณมีข้อมูลที่จะทำการดีบัก ค่าอื่นคือลูกค้าสามารถดีบักได้เมื่อผู้เขียนดั้งเดิมไม่ทำ
Ian Boyd

@IanBoyd: ประโยคที่สองของความคิดเห็นนั้นบอกเป็นนัยว่าคุณปรับใช้ PDB นี่คือกรณีส่วนใหญ่ที่ไม่พึงประสงค์
IIsspectable

3
@ ตรวจสอบหรือเป็นที่ต้องการ
Ian Boyd

@IanBoyd: กรณีส่วนใหญ่ไม่รวมถึงการปรับใช้ระบบปฏิบัติการ นอกจากนี้ PDB เหล่านั้นไม่มีสัญลักษณ์ส่วนตัวซึ่งจะรวมอยู่ในค่าเริ่มต้นเมื่อคุณสร้าง PDB
IIsspectable

@Ispectable ในทางกลับกันการปล่อย PBDs เป็นสิ่งที่ต้องการ โดยหลักการแล้วใช่ทุกคนจะเขียนโค้ดที่คอมไพล์ให้ IL เพื่อให้เราสามารถรับข้อมูลสัญลักษณ์ได้ แต่คอมไพเลอร์โค้ดเนทีฟยังคงไม่มีวิธีที่ง่ายในการรองรับการดีบักในฟิลด์
Ian Boyd

คำตอบ:


416

เนื่องจากไม่มีไฟล์ PDB จึงเป็นไปไม่ได้ที่จะทำการดีบักบิลด์ "Release" ด้วยสิ่งอื่นนอกจากการดีบักระดับที่อยู่ การปรับให้เหมาะสมทำตัวเลขในรหัสของคุณจริง ๆ ทำให้ยากแก่การค้นหาผู้กระทำผิดหากมีบางอย่างผิดปกติ (พูดว่ามีข้อยกเว้นเกิดขึ้น) แม้การตั้งค่าเบรกพอยต์นั้นยากมากเพราะบรรทัดของซอร์สโค้ดไม่สามารถจับคู่แบบหนึ่งต่อหนึ่งกับ (หรือแม้กระทั่งในลำดับเดียวกับ) รหัสแอสเซมบลีที่สร้างขึ้น ไฟล์ PDB ช่วยให้คุณและดีบักเกอร์ทำงานได้ดีขึ้นอย่างมาก

คุณระบุว่าหากซอฟต์แวร์ของคุณพร้อมสำหรับการเปิดตัวคุณควรทำการดีบักทั้งหมดแล้ว แม้ว่าจะเป็นเรื่องจริง แต่ก็มีประเด็นสำคัญสองประการที่ควรคำนึงถึง:

  1. คุณควรยังการทดสอบและการแก้ปัญหาการสมัครของคุณ (ก่อนที่คุณจะปล่อยมัน) โดยใช้ "ปล่อย" สร้าง นั่นเป็นเพราะการเปิดใช้งานการปรับให้เหมาะสม (โดยค่าเริ่มต้นถูกปิดใช้งานภายใต้การกำหนดค่า "ดีบั๊ก") ในบางครั้งอาจทำให้เกิดข้อบกพร่องเล็กน้อยเพื่อให้ปรากฏว่าคุณไม่จับ เมื่อคุณทำการแก้ไขข้อบกพร่องนี้คุณจะต้องการสัญลักษณ์ PDB

  2. ลูกค้ามักรายงานกรณีและข้อผิดพลาดที่เกิดขึ้นภายใต้เงื่อนไข "อุดมคติ" เท่านั้น สิ่งเหล่านี้เป็นสิ่งที่แทบจะเป็นไปไม่ได้ในการทำซ้ำในห้องปฏิบัติการเพราะพวกเขาต้องพึ่งพาการกำหนดค่าที่แปลกประหลาดของเครื่องของผู้ใช้คนนั้น หากพวกเขาเป็นลูกค้าที่มีประโยชน์โดยเฉพาะพวกเขาจะรายงานข้อยกเว้นที่ถูกโยนและให้การติดตามสแต็กแก่คุณ หรือพวกเขาจะให้คุณยืมเครื่องเพื่อดีบักซอฟต์แวร์ของคุณจากระยะไกล ในกรณีใดกรณีหนึ่งคุณจะต้องการให้ไฟล์ PDB ช่วยเหลือคุณ

  3. โปรไฟล์ควรเสมอทำได้ใน "ปล่อย" สร้างด้วยการเพิ่มประสิทธิภาพการเปิดใช้งาน และอีกครั้งไฟล์ PDB มีประโยชน์เพราะอนุญาตให้ทำคำสั่งแอสเซมบลีที่ถูกแมปกลับไปยังซอร์สโค้ดที่คุณเขียนจริง

คุณไม่สามารถย้อนกลับและสร้างไฟล์ PDB ได้ หลังจากคอมไพล์แล้ว *หากคุณไม่ได้สร้างมันในระหว่างการสร้างคุณเสียโอกาส ไม่สร้างความเสียหายอะไรเลย หากคุณไม่ต้องการกระจายพวกเขาคุณสามารถละเว้นพวกเขาจากไบนารีของคุณ แต่ถ้าคุณตัดสินใจในภายหลังว่าคุณต้องการพวกเขาคุณจะโชคดี ดีกว่าที่จะสร้างและเก็บสำเนาไว้เสมอในกรณีที่คุณต้องการ

หากคุณต้องการปิดพวกเขาจริงๆนั่นเป็นตัวเลือกเสมอ ในหน้าต่างคุณสมบัติของโครงการของคุณตั้งค่าตัวเลือก "Debug Info" เป็น "none" สำหรับการกำหนดค่าใด ๆ ที่คุณต้องการเปลี่ยน

อย่างไรก็ตามโปรดทราบว่าการกำหนดค่า "Debug" และ "Release" ทำโดยค่าเริ่มต้นใช้การตั้งค่าที่แตกต่างกันสำหรับการเปล่งข้อมูลการดีบัก คุณจะต้องการรักษาการตั้งค่านี้ ตัวเลือก "ข้อมูลการดีบัก" ถูกตั้งค่าเป็น "เต็ม" สำหรับการสร้างการดีบักซึ่งหมายความว่านอกเหนือจากไฟล์ PDB ข้อมูลสัญลักษณ์การดีบักจะถูกฝังลงในแอสเซมบลี นอกจากนี้คุณยังได้รับสัญลักษณ์ที่สนับสนุนคุณสมบัติเจ๋ง ๆ เช่นแก้ไขและดำเนินการต่อ ในโหมด Release ตัวเลือก "pdb-only" จะถูกเลือกซึ่งเสียงจะรวมเฉพาะไฟล์ PDB เท่านั้นโดยไม่มีผลกับเนื้อหาของชุดประกอบ ดังนั้นจึงไม่ใช่เรื่องง่ายเพียงแค่มีหรือไม่มีไฟล์ PDB ใน/binไดเรกทอรีของคุณ แต่สมมติว่าคุณใช้ตัวเลือก "pdb-only" ไฟล์ PDB '

*ตามที่Marc Sherman ให้ความเห็นตราบใดที่ซอร์สโค้ดของคุณยังไม่เปลี่ยนแปลง (หรือคุณสามารถดึงรหัสต้นฉบับจากระบบควบคุมเวอร์ชัน) คุณสามารถสร้างมันขึ้นมาใหม่และสร้างไฟล์ PDB ที่ตรงกัน อย่างน้อยก็มักจะ วิธีนี้ใช้ได้ผลเกือบตลอดเวลา แต่คอมไพเลอร์ไม่รับประกันว่าจะสร้างไบนารีที่เหมือนกันในแต่ละครั้งที่คุณรวบรวมรหัสเดียวกันดังนั้นอาจมีความแตกต่างเล็กน้อย ถ้าคุณทำการอัปเกรดเป็น toolchain ของคุณในระหว่างนี้ (เช่นการใช้เซอร์วิสแพ็คสำหรับ Visual Studio) PDB นั้นมีโอกาสที่จะตรงกันน้อยลง เพื่อรับประกันรุ่นที่เชื่อถือได้ของอดีต postfactoไฟล์ PDB คุณจะต้องเก็บถาวรไม่เพียง แต่ซอร์สโค้ดในระบบควบคุมเวอร์ชันของคุณ แต่ยังเป็นไบนารีสำหรับ toolchain ทั้งบิลด์ของคุณเพื่อให้แน่ใจว่าคุณสามารถสร้างการกำหนดค่าสภาพแวดล้อมการสร้างของคุณได้อย่างแม่นยำ มันไปโดยไม่บอกว่ามันง่ายกว่าที่จะเพียงแค่สร้างและเก็บไฟล์ PDB


19
"คุณไม่สามารถสร้างไฟล์ PDB หลังจากคอมไพล์" - หากซอร์สโค้ดของคุณไม่เปลี่ยนแปลงคุณสามารถสร้างใหม่เพื่อสร้าง PDB ที่ใช้งานได้หลังจากข้อเท็จจริง โดยค่าเริ่มต้น WinDbg จะไม่โหลด PDB นี้ แต่คุณสามารถบังคับให้โหลดโดยการระบุตัวเลือก / .reload /i foo.dllฉันเช่นนี้ นั่นจะโหลด foo.pdb แม้ว่า foo.pdb จะถูกสร้างขึ้นหลังจากปล่อย foo.dll
Marc Sherman

ฉันสังเกตเห็นว่าการคอมไพล์ใหม่แต่ละรายการมีแฮชย่อยที่แตกต่างกันดังนั้นจึงมีความแตกต่างเล็กน้อยในแต่ละบิลด์แม้ในสภาพแวดล้อมเดียวกัน ที่อยู่สำหรับ PDB ไม่สามารถเปลี่ยนแปลงได้ด้วยความแปรปรวนดังนั้นจึงจำเป็นที่จะต้องป้องกันไม่ให้ PDB จากโครงสร้างนั้นได้หรือไม่ เพียงแค่นำความคิดนี้ออกมาเพราะฉันไม่เข้าใจว่า PDB ทำงานอย่างไรหรือทำไมแฮชเปลี่ยนไประหว่างการสร้าง
thebunnyrules

1
@ ในเชิงอรรถฉันเชื่อมโยงไปยังบทความที่อธิบายว่า"คอมไพเลอร์ C # โดยการออกแบบไม่เคยสร้างไบนารีเดียวกันสองครั้งคอมไพเลอร์ C # ฝัง GUID ที่สร้างขึ้นใหม่ในทุก ๆ แอสเซมบลีทุกครั้งที่คุณเรียกใช้ เหมือนกันนิดหน่อย " นั่นอธิบายว่าทำไมมันจึงมีแฮชต่างกันดังนั้นจึงเป็นไฟล์ PDB อื่น สิ่งนี้สามารถแก้ไขได้ด้วยตัวแก้ไข hex แต่ไม่เป็นมิตรกับผู้ใช้ และยังอยู่นอกขอบเขตของคำตอบนี้
Cody Gray

3
มีคุณสมบัติใหม่ใน Roslyn เรียกว่าการสร้างที่กำหนดขึ้น "การตั้งค่าสถานะ / deterministic ทำให้คอมไพเลอร์ปล่อย EXE / DLL ที่แน่นอนไบต์สำหรับไบต์เมื่อได้รับอินพุตเดียวกัน" สิ่งนี้หมายความว่าโครงการที่คอมไพล์แล้วด้วยแฟล็กนี้สามารถคอมไพล์ซ้ำกับไบนารีที่แน่นอนได้ตราบใดที่โค้ดที่คุณคอมไพล์เหมือนกัน คำอธิบายเพิ่มเติมสามารถพบได้ที่งานสร้าง
K Smith

92

PDB สามารถสร้างขึ้นสำหรับการเช่นเดียวกับการRelease Debugตั้งไว้ที่ (ใน VS2010 แต่ใน VS2005 ต้องเหมือนกัน):

โครงการ→คุณสมบัติ→สร้าง→ขั้นสูง→ข้อมูลการดีบัก

Noneเพียงแค่เปลี่ยนไป


2
แต่ทำไมคุณถึงทำอย่างนั้น? หากซอฟต์แวร์ของคุณพร้อมสำหรับการเปิดตัวคุณควรทำการดีบักทั้งหมดแล้ว
m.edmondson

4
เนื่องจากคุณสามารถดีบักปัญหาการผลิตได้ เมื่อเราต้องทำมัน
Aliostad

21
ข้อได้เปรียบของการมุ่ง PDBs สำหรับรหัสการผลิตคือ. NET จะใช้ไฟล์เหล่านี้เมื่อส่งข้อยกเว้น มันสร้างร่องรอยสแต็คที่มีชื่อไฟล์และหมายเลขบรรทัดซึ่งมักจะมีประโยชน์มาก!
สตีเวน

6
@ m.edmondson: ใช่ถูกต้อง คุณจะยังคงได้รับแจ้งว่าข้อยกเว้นที่เกิดขึ้นคืออะไร (เช่นFileNotFoundException) แต่คุณจะไม่สามารถเห็นร่องรอยสแต็ก ซึ่งทำให้ยากมากที่จะปักหมุดลงบนบรรทัดของโค้ดที่ทำให้เกิดข้อยกเว้น
Cody Gray

2
@ m.edmondson เพียงเพิ่มถ้าคุณกำลังมองหาเครื่องมือในการแก้ปัญหาระยะไกลหนึ่งในปัญหาในกล่องการผลิตของคุณแล้ว windows SDK มาพร้อมกับเครื่องมือที่มีชื่อเสียงมากที่เรียกว่า WinDbg ซึ่งรองรับการดีบักระยะไกล โปรดดูลิงค์ที่กล่าวถึงด้านล่าง หวังว่านี่จะช่วยได้! msdn.microsoft.com/en-in/library/windows/hardware/?hl=th
RBT

8

หากไม่มีไฟล์. pdb จะเป็นไปไม่ได้ที่จะก้าวไปตามรหัสการผลิต คุณต้องพึ่งพาเครื่องมืออื่น ๆ ซึ่งอาจเสียค่าใช้จ่ายและใช้เวลานาน ฉันเข้าใจว่าคุณสามารถใช้การติดตามหรือ windbg ได้เช่นกัน แต่ขึ้นอยู่กับสิ่งที่คุณต้องการบรรลุ ในบางสถานการณ์คุณเพียงต้องการที่จะก้าวผ่านรหัสระยะไกล (ไม่มีข้อผิดพลาดหรือข้อยกเว้น) โดยใช้ข้อมูลการผลิตเพื่อสังเกตพฤติกรรมที่เฉพาะเจาะจงและนี่คือที่ไฟล์. pdb มีประโยชน์ หากไม่มีพวกเขาให้เรียกใช้ดีบักเกอร์ในรหัสนั้น


7

ทำไมคุณถึงแน่ใจว่าคุณจะไม่แก้ไขข้อบกพร่องในการสร้าง? บางครั้ง (หวังว่าจะเกิดขึ้น แต่ไม่ค่อยเกิดขึ้น) คุณอาจได้รับรายงานข้อบกพร่องจากลูกค้าที่ไม่สามารถทำซ้ำได้ในเวอร์ชันการดีบักด้วยเหตุผลบางประการ (การกำหนดเวลาที่แตกต่างกันพฤติกรรมที่แตกต่างกันเล็กน้อยหรืออะไรก็ตาม) หากปัญหานั้นดูเหมือนจะทำซ้ำได้ในบิลด์รีลีสคุณก็ยินดีที่จะมี pdb ที่ตรงกัน


5
@ m.edmondson เข้าถึงเครื่องระยะไกลโดยใช้ RDP, Webex และติดตั้ง windbg ที่นั่น ตั้งค่าเส้นทางสัญลักษณ์ของคุณและแบมคุณเป็นทอง!
Marc Sherman

ลิงก์ไปยังคำแนะนำโดยละเอียดเพิ่มเติมจะมีประโยชน์มากกว่า วิธีการหนึ่งบรรทัดนี้อาจทำให้ผู้คน (เช่นตัวฉัน) หลงทางผิด .NET devs ส่วนใหญ่จะไม่รู้อะไรเกี่ยวกับ Windbg
nuzzolilo

1
@ m.edmondson - Visual Studio บางรุ่นมีความสามารถในการทำการดีบักแบบรีโมท จากเมนูแก้ไขข้อบกพร่องคุณ "แนบกับกระบวนการ" บนเครื่องระยะไกล
Matthew

เป็นความคิดที่ดีหรือไม่ที่จะดีบั๊กรีโมทจากอินสแตนซ์ของแอปพลิเคชั่นที่ใช้งานจริง? มันจะไม่หยุดการทำงานของเธรดแบบขนานและบังคับให้เธรดทำงานแบบอนุกรมในขณะที่ทำการดีบักหรือไม่
Kaveh Hadjari

4

นอกจากนี้คุณยังสามารถใช้ประโยชน์จากการถ่ายโอนข้อมูลผิดพลาดเพื่อดีบักซอฟต์แวร์ของคุณ ลูกค้าส่งให้คุณแล้วคุณสามารถใช้เพื่อระบุรุ่นที่แน่นอนของแหล่งที่มาของคุณ - และ Visual Studio จะดึงสัญลักษณ์การดีบักชุดที่ถูกต้อง (และแหล่งที่มาหากคุณตั้งค่าอย่างถูกต้อง) โดยใช้การถ่ายโอนข้อมูลความผิดพลาด ไมโครซอฟท์ดูเอกสารเกี่ยวกับร้านค้าสัญลักษณ์


2

ไฟล์. PDB เป็นชื่อย่อของ "ฐานข้อมูลโปรแกรม" มันมีข้อมูลเกี่ยวกับจุดแก้จุดบกพร่องสำหรับการดีบักและทรัพยากรที่ใช้หรือการอ้างอิง มันสร้างขึ้นเมื่อเราสร้างเป็นโหมดแก้ไขข้อบกพร่อง อนุญาตให้แอปพลิเคชันตรวจแก้จุดบกพร่องในขณะทำงาน

ขนาดเพิ่มขึ้นของไฟล์. PDB ในโหมดดีบัก มันถูกใช้เมื่อเราทดสอบใบสมัครของเรา

บทความดีดีของไฟล์ pdb

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


1
"ไม่จำเป็นต้องใช้ไฟล์นี้เมื่อวางจำหน่ายหรือปรับใช้" ยกเว้นเมื่อมีคนพบข้อขัดข้องในรุ่นที่วางจำหน่ายนั้นและรายงานข้อขัดข้องที่คุณได้รับจากไฟล์เหล่านั้นไม่มีการติดตามสแต็กที่ใช้งานได้ ... ทั้งหมด.
Nyerguds

ไม่จริง. หากไม่มีไฟล์. pdb คุณจะได้รับสแต็คเต็มรูปแบบ แต่ไม่มีชื่อไฟล์ต้นฉบับ คุณสามารถกู้คืนได้เองหลังจากได้รับรายงานข้อขัดข้อง หากคุณใส่ใจเกี่ยวกับสิทธิ์ในทรัพย์สินทางปัญญาและแหล่งที่ทำให้สับสนคุณต้องบันทึกไฟล์. pdb แต่ไม่ต้องปรับใช้
TOP KEK

1

ในโซลูชันที่มีหลายโครงการคุณมักต้องการมีหนึ่งการกำหนดค่าที่สร้างไม่มีไฟล์ PDB หรือ XML เลย แทนที่จะเปลี่ยนDebug Infoคุณสมบัติของทุกโครงการเป็นnoneฉันคิดว่ามันจะเป็นการง่ายกว่าที่จะเพิ่มเหตุการณ์ post-build ที่ทำงานในการกำหนดค่าเฉพาะ

แต่น่าเสียดายที่ Visual Studio ไม่อนุญาตให้คุณระบุกิจกรรมหลังการสร้างที่แตกต่างกันสำหรับการกำหนดค่าที่แตกต่างกัน ดังนั้นฉันตัดสินใจที่จะทำด้วยตนเองโดยแก้ไขcsprojไฟล์ของโครงการเริ่มต้นและเพิ่มต่อไปนี้ (แทนPostBuildEventแท็กที่มีอยู่):

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

น่าเสียดายที่สิ่งนี้จะทำให้กล่องข้อความเหตุการณ์การสร้างโพสต์ว่างเปล่าและการวางสิ่งใดไว้ในนั้นอาจทำให้เกิดผลลัพธ์ที่ไม่สามารถคาดการณ์ได้


4
นี่จะเป็นการลบ*.xmlไฟล์ทั้งหมดระวังให้ดี
Mariusz Jamro

0

สัญลักษณ์การดีบัก ( .pdb) และ XML doc ( .xml) คิดเป็นเปอร์เซ็นต์ขนาดใหญ่ของขนาดทั้งหมดและไม่ควรเป็นส่วนหนึ่งของแพ็คเกจการปรับใช้ทั่วไป แต่ควรเข้าใช้งานได้ในกรณีที่จำเป็น

แนวทางหนึ่งที่เป็นไปได้: ในตอนท้ายของกระบวนการสร้าง TFS ให้ย้ายไปยังสิ่งประดิษฐ์แยกต่างหาก


-1

จริงๆแล้วหากไม่มีไฟล์ PDB และข้อมูลเชิงสัญลักษณ์พวกเขามีมันเป็นไปไม่ได้ที่จะสร้างรายงานข้อขัดข้องที่ประสบความสำเร็จ (ไฟล์ดัมพ์หน่วยความจำ) และ Microsoft จะไม่มีภาพรวมที่ทำให้เกิดปัญหา

ดังนั้นการมี PDB ช่วยปรับปรุงการรายงานข้อขัดข้อง


แต่สิ่งที่จะหายไปโดยไม่ต้องไฟล์. pdb?
TOP KEK

คุณไม่สามารถสร้างไฟล์ PDB หลังจากคอมไพล์ ดังนั้นซอฟต์แวร์รุ่นใหญ่ทุกรุ่นควรบันทึก [. build [.revision]] ไว้ที่ Microsoft เพื่อทำความเข้าใจกับสิ่งที่เกิดขึ้นอย่างถูกต้อง แต่นี่ไม่ใช่ทั้งหมด
prosti

คอมไพเลอร์ไม่รับประกันว่าจะสร้างไบนารีที่เหมือนกันทุกครั้งที่คุณรวบรวมรหัสเดียวกัน
prosti

คำถามคือสิ่งที่จะหายไปในรายงานข้อขัดข้องและวิธีการรายงานข้อขัดข้องที่จะได้รับผลกระทบ ไฟล์. pdb. NET ประกอบด้วยชื่อตัวแปรส่วนตัวและชื่อไฟล์ต้นฉบับเท่านั้น ทุกอย่างอื่น (ชื่อเมธอดลายเซ็นเป็นต้น) จะอยู่ในรูปแบบสแต็คจากข้อมูลเมตาดาต้า
TOP KEK

ไฟล์นอกจากนี้ยังมีข้อมูลส่วนตัวที่ไม่ใช่ไม่มี PDB: github.com/microsoft/microsoft-pdb
prosti
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.