2009-03-09 24 views
11

डिबगिंग मैं वर्तमान आवेदन की डिबग अंश कोशिश कर रहा हूँ मैं पर काम कर रहा हूँ चरों के मान देखने, लेकिन जब मैं कोशिश करते हैं और त्रुटि एक संपत्ति/चर के मूल्य की जाँच मैं प्राप्त करने में असमर्थ:जबकि

Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized.

यह केवल एक नियमित एएसपी.नेट परियोजना है। एप्लिकेशन के कुछ हिस्सों में मैं गुणों और चर को पूरी तरह से ठीक देख सकता हूं। मुझे पता नहीं चला है कि कोड के ब्लॉक के बारे में क्या अलग है जो मैं कर सकता हूं और चर के मानों को नहीं देख सकता।

उत्तर

10

समस्या एक एमएसडीएन ब्लॉग पर documented थी, क्योंकि कुछ स्थितियों में कुछ प्रकार की आकार सीमा, लिंक में अधिक जानकारी थी। मेरा मानना ​​है कि यह 256 बाइट्स था और/या एक समारोह में पारित तर्कों की संख्या का कुल आकार/गिनती थी। यह कहने के लिए खेद है कि एक त्वरित फिक्स प्रतीत नहीं होता है, लेकिन उम्मीद है कि एमएसडीएन ब्लॉग एंट्री आपको आपकी समस्या को हल करने के तरीके की पहचान करने में मदद करेगी।

+1

मुझे संदेह है कि इस त्रुटि के लिए 256 बाइट सीमा (या तर्कों की संख्या) सबसे आम कारण है। लिंक्ड आलेख में संदर्भित आलेख, [नियमों का नियम] (http://blogs.msdn.com/b/jmstall/archive/2005/11/15/funceval-rules.aspx) कई अन्य कारण बताता है हो सकता है। – kristianp

+0

यह वीएस -2008 आरटीएम में भी था, इसलिए एसपी 1 ने इसे ठीक कर दिया होगा। मुझे यह भी नहीं पता कि यह वीएस -2010 में भी मौजूद है। – CertifiedCrazy

+0

एफवाईआई, वीएस -2010 में एक ही समस्या मौजूद है। –

0

क्या आप रिलीज बिल्ड कर रहे हैं? कॉन्फ़िगरेशन को "डीबग" में बदलने का प्रयास करें और देखें कि यह बेहतर है या नहीं।

+0

नहीं, समाधान कॉन्फ़िगरेशन "डीबग" पर सेट किया गया है –

+0

सुनिश्चित करें कि समाधान "डीबग" कॉन्फ़िगरेशन का हिस्सा सभी परियोजनाएं इस तरह चिह्नित हैं। डीबग सिर्फ मोनिकर है, और यह संभव है कि * प्रोजेक्ट * समाधान "विस्तृत" डीबग कॉन्फ़िगरेशन के तहत "रिलीज़" पर सेट हो। भ्रामक? हाँ। –

+0

हालांकि मैं अपनी प्रत्येक परियोजनाओं में चला गया हूं। वे सभी "सक्रिय (डीबग)" पर सेट हैं, हालांकि मैंने उन्हें सभी को "डीबग" में बदल दिया है। अभी भी कोई भाग्य नहीं है। –

0

हमारे पास हमारे दो WinForm उपयोगकर्ता नियंत्रणों में एक ही समस्या है। दोनों स्थितियों में उपयोगकर्ता नियंत्रण में बहुत से व्यवसाय तर्क (2000 क्रमशः कोड की 2000 और 3000 लाइनें) होती हैं और कई काफी भारी वस्तुओं का उपयोग करती है (उनके पास 30+ गुण होते हैं जो पहली बार डेटाबेस से स्वचालित रूप से पॉप्युलेट हो जाते हैं जब गुणों में से एक पहुंचा जा सकता है)। जब आप (कुछ जटिल) सत्यापन और बचत विधियों के माध्यम से कदम उठाने का प्रयास करते हैं, तो ऑब्जेक्ट गुणों तक पहुंचने का प्रयास करते समय आपको यह वही संदेश मिलता है।

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

2

यह आलेख, Rules of Funceval ऐसा होने के कई कारण बताता है। यदि डिबगिंग चालू है और ऑप्टिमाइज़ेशन पहले ही बंद हो गया है, तो आप इस समस्या के बारे में और कुछ नहीं कर सकते हैं।

+0

अच्छा लेख, धन्यवाद! –