विजुअल स्टूडियो डिजाइनर त्रुटियों को डीबग करने का अच्छा तरीका

Question

क्या विजुअल स्टूडियो डिज़ाइनर में त्रुटियों को डीबग करने का कोई अच्छा तरीका है?

हमारी परियोजना में हमारे पास कई उपयोगकर्ता नियंत्रण और कई जटिल रूप हैं। जटिल लोगों के लिए, डिजाइनर अक्सर विभिन्न अपवाद फेंकता है जो बहुत मदद नहीं करता है, और मैं सोच रहा था कि क्या गलत हो गया है यह जानने का कोई अच्छा तरीका है।

भाषा सी # है, और हम हर एक अलग है और वे कभी कभी अस्पष्ट हो सकता है दृश्य स्टूडियो 2005

Answer 1

Debugging Design-Time Controls (एमएसडीएन) देखें।

Answer 2

उपयोग कर रहे हैं। पहले चरण के रूप में, मैं निम्नलिखित कार्य करता हूं:

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

Answer 3

मैंने यह कई बार किया है और यह है एक असली दर्द

सबसे पहले मैं डिजाइनर द्वारा प्रदान किए गए स्टैक ट्रेस का पालन करने का प्रयास करने का सुझाव देता हूं, हालांकि मुझे लगता है कि अक्सर आंतरिक रूप से आंतरिक सामानों का एक गुच्छा सूचीबद्ध करता है जो अधिक उपयोग नहीं करते हैं।

यदि यह काम नहीं करता है तो वहां से अपवाद संकलित करने और निर्धारित करने का प्रयास करें। आप वास्तव में अंधे उड़ रहे हैं जो समस्या है। फिर आप कोड को चलाने का प्रयास कर सकते हैं और देख सकते हैं कि जब आप इसे चलाते हैं तो अपवाद उठाया जाता है, जिससे आपको कुछ और जानकारी मिलनी चाहिए।

एक अंतिम गैस दृष्टिकोण दृष्टिकोण से सभी गैर-जेनरेट किए गए कोड को हटाने और त्रुटि को निर्धारित करने के लिए धीरे-धीरे इसे फिर से पेश करना हो सकता है।

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

मूल रूप से जहां तक ​​मैं कह सकता हूं कि समस्या के आसपास कोई वास्तविक तरीका नहीं है, इसे थोड़ा सा स्लोग करने के अलावा!

Answer 4

मैं वीएस का दूसरा उदाहरण चलाकर कुछ नियंत्रण डिजाइनर मुद्दों को डीबग करने में सक्षम हूं, फिर अपने पहले वीएस इंस्टेंस से "डीबग -> प्रक्रिया से जुड़ा" करें और "डेवेनव" चुनें।

पहला वीएस उदाहरण वह जगह है जहां आप अपने ब्रेकपॉइंट्स सेट करेंगे। "डिजाइनर" कोड चलाने के लिए डिज़ाइनर को लोड करने के लिए दूसरा उदाहरण उपयोग करें।

Answer 5

आप वीएस का दूसरा उदाहरण चला सकते हैं और इसे वीएस (Ctrl + Alt + P) के पहले उदाहरण में संलग्न कर सकते हैं। पहले उदाहरण में ब्रेकपॉइंट्स सेट करें, दूसरे उदाहरण में डिजाइनर चलाएं, और ब्रेकपॉइंट आग लगेगा। आप कोड के माध्यम से कदम उठा सकते हैं, लेकिन संपादन-और-जारी काम नहीं करेगा।

काम करने के लिए संपादन और जारी रखने के लिए, आपको कमांड लाइन तर्क समाधान फ़ाइल नाम के साथ वीएस चलाने के लिए लाइब्रेरी के डीबग विकल्पों को नियंत्रित करने के लिए सेट करें।फिर आप ब्रेकपॉइंट्स सेट कर सकते हैं और F5 दबा सकते हैं। यह उपयोगकर्ता कोड की तरह डीबग होगा! एक साइड नोट के रूप में, आप यह वीएस और ऑफिस एड-इन्स भी कर सकते हैं।

Answer 6

मुझे पता चला कि कभी-कभी ब्रेकपॉइंट्स क्यों नहीं मारा जाता है। प्रक्रिया संवाद में संलग्न करें, "संलग्न करें:" प्रकार "चयन करें ..." 'डी होना चाहिए।

एक बार जब मैं "प्रबंधित 4.0, 4.5" में बदल गया, तो WinRT एप्लिकेशन के लिए ब्रेकपॉइंट्स मारा गया। स्रोत: Designer Debugging in WinRT।

Answer 7

यह 2005 में दर्द रहा है और अभी भी 2015 में है। ब्रेकपॉइंट्स अक्सर हिट नहीं होते हैं, शायद विधानसभाओं की छाया प्रतिलिपि या डिजाइनर (?) द्वारा कुछ की वजह से। सबसे अच्छा आप कर सकते हैं Debugger.Break() पर कॉल शुरू करके मैन्युअल रूप से तोड़ना है। आप इसे संकलक के रूप में सशर्त में लपेट सकते हैं:

#if DEBUG 
    System.Diagnostics.Debugger.Break(); 
#endif 
int line_to = break; // <- if a simple breakpoint here does not suffice