रिलीज उत्पन्न .pdb फ़ाइलें, क्यों?

Question

विजुअल स्टूडियो 2005 रिलीज में संकलित करते समय .pdb फ़ाइलों को क्यों उत्पन्न करता है? मैं रिलीज बिल्ड डिबगिंग नहीं करूँगा, तो वे क्यों उत्पन्न हुए हैं?

Answer 1

क्योंकि पीडीबी फाइलों के बिना, पता-स्तर डिबगिंग के अलावा किसी अन्य चीज़ द्वारा "रिलीज" निर्माण को डीबग करना असंभव होगा। अनुकूलन वास्तव में आपके कोड पर एक संख्या करते हैं, अगर कुछ गलत हो जाता है तो अपराधी को ढूंढना बहुत मुश्किल हो जाता है (कहें, एक अपवाद फेंक दिया गया है)। ब्रेकपॉइंट्स को सेट करना भी बेहद मुश्किल है, क्योंकि स्रोत कोड की रेखाएं जेनरेट किए गए असेंबली कोड के साथ एक-एक-एक (या उसी क्रम में भी) से मेल नहीं खाती हैं। पीडीबी फाइलें आपको और डिबगर आउट करने में मदद करती हैं, जिससे पोस्ट-मॉर्टम डिबगिंग काफी आसान हो जाती है।

आप यह मुद्दा बनाते हैं कि यदि आपका सॉफ़्टवेयर रिलीज के लिए तैयार है, तो आपको तब तक अपनी सभी डिबगिंग करना चाहिए था। हालांकि यह निश्चित रूप से सच है, वहाँ महत्वपूर्ण बिंदुओं की एक जोड़ी को ध्यान में रखा जाना चाहिए:

1. आप चाहिए भी परीक्षण और डिबग आपके आवेदन (इससे पहले कि आप इसे जारी) "रिलीज" निर्माण का उपयोग कर। ऐसा इसलिए है क्योंकि ऑप्टिमाइज़ेशन चालू करना (वे "डीबग" कॉन्फ़िगरेशन के तहत डिफ़ॉल्ट रूप से अक्षम होते हैं) कभी-कभी सूक्ष्म बग दिखाई दे सकते हैं जिन्हें आप अन्यथा पकड़ नहीं पाएंगे। जब आप यह डिबगिंग कर रहे हों, तो आप पीडीबी प्रतीकों को चाहेंगे।

2. ग्राहक अक्सर किनारे के मामलों और बग की रिपोर्ट करते हैं जो केवल "आदर्श" स्थितियों के तहत फसल पैदा करते हैं। ये ऐसी चीजें हैं जो प्रयोगशाला में पुन: पेश करने के लिए लगभग असंभव हैं क्योंकि वे उस उपयोगकर्ता की मशीन की कुछ अजीब विन्यास पर भरोसा करते हैं। यदि वे विशेष रूप से सहायक ग्राहक हैं, तो वे उस अपवाद की रिपोर्ट करेंगे जो फेंक दिया गया था और आपको एक स्टैक ट्रेस प्रदान करता था। या वे आपको अपने मशीन को दूरस्थ रूप से डीबग करने के लिए अपनी मशीन उधार लेने देंगे। इनमें से किसी भी मामले में, आप पीडीबी फाइलों को आपकी सहायता करने के लिए चाहते हैं।

3. प्रोफाइलिंग हमेशा ऑप्टिमाइज़ेशन सक्षम के साथ "रिलीज" बिल्ड पर किया जाना चाहिए। और एक बार फिर, पीडीबी फाइलें काम में आती हैं, क्योंकि वे वास्तव में लिखे गए स्रोत कोड पर मैप किए जाने के लिए असेंबली निर्देशों को प्रोफाइल करने की अनुमति देते हैं।

आप वापस जाएँ और PDB फ़ाइलों संकलन के बाद उत्पन्न नहीं कर सकते। ^* यदि आप निर्माण के दौरान उन्हें नहीं बनाते हैं, तो आप अपना मौका खो चुके हैं। यह उन्हें बनाने के लिए कुछ भी चोट नहीं पहुंचाता है। यदि आप उन्हें वितरित नहीं करना चाहते हैं, तो आप उन्हें अपनी बाइनरी से छोड़ सकते हैं। लेकिन अगर आप बाद में फैसला करते हैं कि आप उन्हें चाहते हैं, तो आप भाग्य से बाहर हैं।हमेशा उन्हें उत्पन्न करने और एक प्रतिलिपि संग्रहित करने के लिए बेहतर, बस आपको उनकी आवश्यकता होने पर।

यदि आप वास्तव में उन्हें बंद करना चाहते हैं, तो यह हमेशा एक विकल्प होता है। अपनी प्रोजेक्ट की प्रॉपर्टी विंडो में, किसी भी कॉन्फ़िगरेशन के लिए "डीबग इन्फो" विकल्प को "none" पर सेट करें जिसे आप बदलना चाहते हैं।

नोट करें, हालांकि, "डीबग" और "रिलीज" कॉन्फ़िगरेशन डिफ़ॉल्ट रूप से डीबग जानकारी उत्सर्जित करने के लिए अलग-अलग सेटिंग्स का उपयोग करें। आप इस सेटिंग को रखना चाहते हैं। "डीबग जानकारी" विकल्प को डीबग बिल्ड के लिए "पूर्ण" पर सेट किया गया है, जिसका अर्थ है कि पीडीबी फ़ाइल के अतिरिक्त, डिबगिंग प्रतीक जानकारी असेंबली में एम्बेड की गई है। आपको ऐसे प्रतीक भी मिलते हैं जो संपादन और जारी रखने जैसी शानदार सुविधाओं का समर्थन करते हैं। रिलीज मोड में, "पीडीबी-ओनली" विकल्प चुना जाता है, जो इसे लगता है, जिसमें केवल पीडीबी फ़ाइल शामिल है, असेंबली की सामग्री को प्रभावित किए बिना। इसलिए यह आपकी /bin निर्देशिका में पीडीबी फ़ाइलों की उपस्थिति या अनुपस्थिति के रूप में काफी सरल नहीं है। लेकिन मानते हैं कि आप "पीडीबी-केवल" विकल्प का उपयोग करते हैं, पीडीबी फ़ाइल की उपस्थिति आपके कोड के रन-टाइम प्रदर्शन को प्रभावित नहीं करेगी।

_{^*Marc Sherman points out in a comment के रूप में, जब तक कि अपने स्रोत कोड नहीं बदला है (या आप एक संस्करण नियंत्रण प्रणाली से मूल कोड प्राप्त कर सकते हैं), तो आप इसे फिर से बनाने और मेल खाता हुआ PDB फ़ाइल उत्पन्न कर सकते हैं। कम से कम, आमतौर पर। यह ज्यादातर समय काम करता है, लेकिन the compiler is not guaranteed to generate identical binaries each time you compile the same code, इसलिए सूक्ष्म अंतर हो सकता है। इससे भी बदतर, अगर आपने इस दौरान अपने टूलचेन में कोई अपग्रेड किया है (जैसे विजुअल स्टूडियो के लिए सर्विस पैक लागू करना), पीडीबी की मिलान होने की संभावना कम है। पूर्व पोस्टफैक्टो पीडीबी फाइलों की विश्वसनीय पीढ़ी की गारंटी के लिए, आपको न केवल अपने संस्करण-नियंत्रण प्रणाली में स्रोत कोड संग्रहित करना होगा, बल्कि यह सुनिश्चित करने के लिए कि आप अपने संपूर्ण कॉन्फ़िगरेशन को फिर से बना सकते हैं, पर्यावरण का निर्माण यह कहने के बिना चला जाता है कि पीडीबी फाइलों को आसानी से बनाना और संग्रह करना बहुत आसान है।}

Answer 2

पीडीबी Release के साथ-साथ Debug के लिए जेनरेट किया जा सकता है। यह (VS2010 में लेकिन VS2005 में समान होना चाहिए) पर सेट है:

Project → Properties → Build → Advanced → Debug Info

बस None के लिए इसे बदल।

Answer 3

आप इतने यकीन क्यों हैं कि आप रिलीज बिल्ड को डीबग नहीं करेंगे? कभी-कभी (उम्मीद है कि शायद ही कभी होता है) आपको किसी ऐसे ग्राहक से दोष रिपोर्ट मिल सकती है जो किसी कारण से अलग-अलग संस्करण (अलग-अलग समय, छोटे व्यवहार या जो कुछ भी) के लिए डीबग संस्करण में पुन: उत्पन्न नहीं होती है। यदि रिलीज बिल्ड में यह समस्या पुन: उत्पन्न होती प्रतीत होती है तो आप मिलान करने वाले पीडीबी को लेकर खुश होंगे।

Answer 4

.pdb फ़ाइलों के बिना यह उत्पादन कोड के माध्यम से कदम उठाने के लिए लगभग असंभव है; आपको अन्य उपकरणों पर भरोसा करना है जो महंगा और समय लेने वाला हो सकता है। मैं समझता हूं कि आप उदाहरण के लिए ट्रेसिंग या विंडबग का उपयोग कर सकते हैं लेकिन यह वास्तव में उस चीज़ पर निर्भर करता है जिसे आप प्राप्त करना चाहते हैं। कुछ परिदृश्यों में आप केवल विशेष व्यवहार का निरीक्षण करने के लिए उत्पादन डेटा का उपयोग कर दूरस्थ कोड (कोई त्रुटि या अपवाद) के माध्यम से कदम उठाना चाहते हैं, और यह वह जगह है जहां .pdb फ़ाइलें आसान होती हैं। उनके बिना उस कोड पर डीबगर चलाने के बिना असंभव है।

Answer 5

.PDB फ़ाइल "प्रोग्राम डेटाबेस" का संक्षिप्त नाम है। इसमें डीबगर और संसाधनों के लिए डीबग पॉइंट के बारे में जानकारी शामिल है जो उपयोग या संदर्भ हैं। जब हम डीबग मोड के रूप में निर्माण करते हैं तो इसका उत्पन्न होता है। यह रनटाइम पर डीबग करने के लिए आवेदन करने की अनुमति देता है।

डीबग मोड में पीडीबी फ़ाइल का आकार बढ़ रहा है। इसका उपयोग तब होता है जब हम अपने आवेदन का परीक्षण कर रहे हैं।

रिलीज या तैनाती के दौरान इस फ़ाइल की कोई आवश्यकता नहीं है। पीडीबी फ़ाइल का अच्छा लेख।

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

Answer 6

इसके अलावा, आप उपयोग कर सकते हैं दुर्घटना अपने सॉफ्टवेयर डिबग करने के लिए उदासीनता। ग्राहक इसे आपके पास भेजता है और फिर आप इसका उपयोग अपने स्रोत के सटीक संस्करण की पहचान के लिए कर सकते हैं - और विजुअल स्टूडियो भी क्रैश डंप का उपयोग करके डिबगिंग प्रतीकों (और स्रोत को सही तरीके से सेट अप किया गया है) का सही सेट खींच देगा। माइक्रोसॉफ्ट के documentation on Symbol Stores देखें।

Answer 7

एक बहु-परियोजना समाधान में, आप आमतौर पर एक कॉन्फ़िगरेशन चाहते हैं जो कोई पीडीबी या एक्सएमएल फाइलें उत्पन्न न करे।प्रत्येक परियोजना की Debug Info संपत्ति को none पर बदलने के बजाय, मैंने सोचा कि पोस्ट-बिल्ड ईवेंट जोड़ने के लिए यह अधिक उपयुक्त होगा जो केवल एक विशिष्ट कॉन्फ़िगरेशन में काम करता है।

दुर्भाग्यवश, विजुअल स्टूडियो आपको विभिन्न कॉन्फ़िगरेशन के लिए अलग-अलग पोस्ट-बिल्ड ईवेंट निर्दिष्ट करने की अनुमति नहीं देता है। तो मैं इस मैन्युअल रूप से करना का फैसला किया, संपादन स्टार्टअप परियोजना के csproj फ़ाइल और निम्न (के बजाय किसी भी मौजूदा PostBuildEvent टैग) जोड़कर:

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

दुर्भाग्य से, इस पोस्ट का निर्माण घटना पाठ बॉक्स खाली कर देगा और डाल इसमें कुछ भी अप्रत्याशित परिणाम हो सकता है।

Answer 8

डीबग प्रतीकों (.pdb) और एक्सएमएल दस्तावेज़ ( .xml) फ़ाइलें कुल आकार का एक बड़ा प्रतिशत बनाती हैं और नियमित तैनाती पैकेज का हिस्सा नहीं बननी चाहिए। लेकिन यदि आवश्यक हो तो उन्हें एक्सेस करना संभव होना चाहिए।

एक संभावित दृष्टिकोण: टीएफएस निर्माण प्रक्रिया के अंत में, उन्हें एक अलग आर्टिफैक्ट में ले जाएं।