जब रिलीज डीएलएस काम नहीं करते हैं लेकिन डीबग डीएलएस

Question

हमारे ग्राहकों में से एक को हमारे विशाल वितरित सिस्टम को तैनात करने के बाद हमें एक अनपेक्षित त्रुटि का अनुभव होता है। जांच के दौरान हम असेंबली को एक ऐसे त्रुटि के साथ बदलते हैं जहां हमने कुछ डायग्नोस्टिक कोड जोड़ा है। डीएल हम उपयोग डीबग मोड में बनाया गया है। और अचानक यह सब काम करता है!

रिलीज संस्करण (डायग्नोस्टिक कोड के साथ) डीबग डीएल को बदलने से यह फिर से दुर्घटनाग्रस्त हो जाता है।

हमारे कोड में कोई प्रीकंपलर निर्देश, सशर्त डीबग विशेषताएँ आदि नहीं हैं। समस्या दो अलग-अलग स्थापना साइटों में पाई गई है, जबकि यह कई और में ठीक काम करता है।

(परियोजना C# और VB.NET का एक मिश्रण है, troublesom विधानसभा VB.NET .., यह है कि अगर किसी भी फर्क नहीं पड़ता)

तो सवाल यह है: आप स्थितियों में क्या करना चाहिए इस तरह? और सामान्य कारण क्या हो सकता है? इस मुद्दे को डीबग करने पर कोई सलाह स्वागत है।

Answer 1

कारणों के लिए ... अच्छा, लक्षण का कुछ संकेत मदद करेगा। एक संभावना यह है कि आपके पास Debug.WriteLine जैसी विधि के लिए कोड है जिसके दुष्प्रभाव हैं (यानी यह काम करता है)। [Conditional(...)] के साथ चिह्नित विधियों पर कॉल संकलित नहीं किए जाते हैं जब तक कि आपके पास सही प्रतीकों को परिभाषित न किया गया हो - इसलिए [Conditional("DEBUG")] चिह्नित कुछ भी चुपचाप गिरा दिया जाएगा।

यह एक कंपाइलर बग भी हो सकता है, लेकिन यह थोड़ा असंभव है (लेकिन असंभव नहीं है)।

लक्षण क्या है? यह कैसे टूटता है?

ऊपर का एक उदाहरण के रूप में:

static string Bar { get; set; } 
    static void Main() 
    { 
     Bar = "I'm broken"; 
     Debug.WriteLine(Foo()); 
     Console.WriteLine(Bar); 
    } 
    // note Foo only called in DEBUG builds 
    static string Foo() 
    { 
     Bar = "I'm working"; 
     return "mwahahah"; 
    } 

डिबग मोड में संकलित यह प्रिंट "मैं काम कर रहा हूँ"; रिलीज मोड में संकलित यह प्रिंट करता है "मैं टूटा हुआ हूं"। क्या यह समान लगता है? जांचें कि आप किसी भी डीबग विधियों को सीधे पर कॉल नहीं कर रहे हैं जिनके दुष्प्रभाव हैं। ज्यादातर मामलों में, आप संकेत द्वारा ठीक कर सकते हैं:

string foo = Foo(); 
Debug.WriteLine(foo); 

अब इसे किसी भी मोड में बुलाया जाता है।

Answer 2

आप बिल्ड सेटिंग्स में ऑप्टिमाइज़ कोड को आजमा सकते हैं और बंद कर सकते हैं। आपको जो वास्तविक त्रुटि मिल रही है वह क्या है।

एक और चीज जो आप कर सकते हैं रिलीज मोड में संकलित है लेकिन #Debug सशर्त सक्षम करें। यदि आप डायग्नोस्टिक्स.डिबग का उपयोग करते हैं और वहां कोड आपके एप्लिकेशन को प्रभावित करता है तो यह केस को संभालेगा।

Answer 3

Debug.Assert(ImportantMethod()); 

Answer 4

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

Answer 5

क्या आपने डीबग फ़ाइलों को शामिल करने का प्रयास किया है?(पीडीबीएस)

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

Answer 6

मैंने समय देखा है जो डीबग और रिलीज बिल्ड के बीच मुद्दों का कारण बनता है। आम तौर पर डिबग बिल्ड रिलीज बिल्ड की तुलना में धीमी गति से चलता है। आप अपने कोड के समय महत्वपूर्ण अनुभाग की जांच करना चाह सकते हैं।

Answer 7

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

Answer 8

मुझे एक ही समस्या थी। मेरी स्थिति इस तरह: मैंने कक्षा पुस्तकालय ए में कुछ प्रतिबिंब कार्यों को परिभाषित किया। फिर मैंने एक WPF उपयोगकर्ता नियंत्रण लाइब्रेरी बी परिभाषित किया, जो लाइब्रेरी ए से फ़ंक्शंस का उपयोग करता है। फिर मैंने एक एप्लिकेशन को कोड किया जो लाइब्रेरी बी और फ़ंक्शन से उपयोगकर्ता नियंत्रण का उपयोग करता है पुस्तकालय ए में। जब मैंने लाइब्रेरी बी के डीबग संस्करण का उपयोग किया, तो यह ठीक काम करता है। लेकिन जब मैंने पुस्तकालय बी के रिलीज संस्करण का उपयोग किया, तो प्रतिबिंब कार्यों का काम नहीं हुआ। मैंने पुस्तकालय ए में अन्य कार्यों को भी परिभाषित किया। ऐसा लगता है कि केवल प्रतिबिंब कार्य ही परेशानी पैदा कर रहे हैं। मैं कारण समझ नहीं सकता। अंत में, मैंने छोड़ दिया और लाइब्रेरी ए से लाइब्रेरी बी में प्रतिबिंब कार्यों को स्थानांतरित कर दिया। और यह काम किया।

Answer 9

मुझे एक बिंदु पर एक समस्या थी जिसमें फाइनलाइज़र अपेक्षा से जल्द ही बंद हो गए थे, क्योंकि मैंने अंतिम रूप से कचरा कलेक्टर के बीच इंटरप्ले को पूरी तरह से समझ नहीं पाया था, और जब स्थानीय वस्तु को एकत्रित माना जाता है (संकेत: यह नहीं है ब्लॉक की घुंघराले ब्रेस बंद)। यदि आपका कोड फ़ाइनलाइज़र का उपयोग करता है, तो आप जीसी.किपलाइव() में देखना चाहेंगे। निम्नलिखित ब्लॉक में:

void MyFunction() 
{ 
    Foo f = new Foo(); 
    SomeFunction(f.SomeProp); 
} 

f से पहले SomeFunction() भी चलाता है को अंतिम रूप देने के लिए पात्र बन जाता है! यदि फाइनलर कुछ भी SomeProp हाथों को निपटाने जैसा कुछ करता है, तो आप परेशानी में पड़ सकते हैं। SomeFunction पर कॉल के बाद GC.KeepAlive(f) पर कॉल जोड़ना सुनिश्चित करता है कि fKeepAlive() पर कॉल के बाद तक अंतिम रूप देने के लिए योग्य नहीं है।

संपादित करें: इसके बाद, मैं यह इंगित करना भूल गया कि रिलीज मोड में चलने पर यह समस्या अधिक स्पष्ट थी। मुझे नहीं पता कि डीबग बिल्ड डीबगर के लाभ के लिए समारोह के अंत में स्थानीय लोगों के लिए निहित KeepAlives रखता है, या यदि कचरा संग्रह केवल कम आक्रामक है, या क्या, लेकिन रिलीज मोड ने मेरे मामले में इस समस्या को बहुत बढ़ा दिया है।

Answer 10

क्या आपने अपनी समस्या हल की है?
मुझे आपके जैसा ही समस्या है।
यदि मैं डीबग में डीएल संकलित करता हूं, तो सभी ठीक काम करते हैं।
यदि मैं रिलीज में संकलित करता हूं तो मुझे एक शून्य संदर्भ अपवाद मिलता है।
लेकिन अगर मैं कुछ तरीकों फोन में ऊपर की तरह कुछ लाइनें शामिल हैं, अपवाद भी रिलीज़ मोड में चला गया है:
System.Diagnostics.EventLog.WriteEntry ("blablabla", "blablabla")

आशा है कि तुम्हारी सहायता करता है।

Answer 11

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

Answer 12

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

Answer 13

मेरे मामले में यह था कि मेरी डीएलएल उपभोक्ता परियोजना (वीएस में) में x64 कॉन्फ़िगरेशन था, लेकिन समाधान किसी भी CPU में था। किसी कारण से एप्लिकेशन चलाने पर यह मेरे x64 DLL के साथ हुक नहीं था। मैंने एप्लिकेशन को x64 स्पष्ट रूप से प्लेटफ़ॉर्म पर कॉन्फ़िगर किया और सबकुछ ठीक से काम करता था।