🐁 🏳️‍🌈 👩🏻‍🚒 .NET डायनेमिक, यूनिटी और रनटाइमबाइंडर बग ♦️ 👩🏾‍🔬 🍉

प्रागितिहास

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

सभी कार्यस्थानों पर दिखाई देने वाली त्रुटि, जहां प्रोग्राम का नया संस्करण स्थापित किया गया था, इस तरह देखा गया:

System.IndexOutOfRangeException: Index was outside the bounds of the array
at Microsoft.CSharp.RuntimeBinder.ExpressionTreeCallRewriter.GetMethodInfoFromExpr(EXPRMETHODINFO methinfo)
...

और, जैसा कि बाद में पता चला, वह कोड की एक बहुत ही सहज कृति में दिखाई दी:

 public void FillFrom(dynamic launch) { Log.ShowLog(launch.Id); }

इस तथ्य के कारण कि कंप्यूटर पर क्लाइंट्स के पास Windows XP है, हम .NET फ्रेमवर्क 4.0 संस्करण का उपयोग करने में सीमित हैं, क्योंकि XP पर दिए गए संस्करण को अब वितरित नहीं किया जा सकता है। इसलिए, हमारी परियोजना का लक्ष्य फ्रेमवर्क के इस विशेष संस्करण का उपयोग करना है, इस तथ्य के बावजूद कि वीएस 2012 और फ्रेमवर्क 4.5 लंबे समय तक हमारे कंप्यूटर पर स्थापित किए गए हैं। इसने हमारे साथ त्रुटि की कमी को प्रभावित किया। इसलिए, मुझे यह पता लगाना था कि इस त्रुटि का कारण क्या था और हम इससे कैसे निपट सकते हैं।

समस्या का सार

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

समस्या का कारण

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

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

थोड़ी गहराई में जाने पर, यह पता चला कि रंटाइमबाइंडर एक उपयुक्त विधि खोजने के लिए एक पंक्ति में सब कुछ नहीं लेता है, लेकिन केवल कुछ विधियाँ जो एक निश्चित फ़िल्टर की क्रिया के अंतर्गत आती हैं:

बाइंडिंगफ्लैग। इनस्टेंस | BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic

इस प्रकार, यह स्पष्ट हो गया कि आधार वर्ग के तरीके किसी भी आवश्यक खोज में किसी भी तरह से भाग नहीं लेते हैं।

आगे की खुदाई, यह स्पष्ट हो गया कि बेस क्लास से "साधारण" विधि के टोकन के साथ टोकन विधि संयोग नहीं है, लेकिन आधार वर्ग में परिभाषित संपत्ति के एक्सेसर के साथ। यही है, ShowLog पद्धति का टोकन, get_IsNotifying विधि के टोकन के साथ मेल खाता है। लेकिन यह एक्सेसर पहले से ही उपरोक्त फ़िल्टर को पूरी तरह से पारित कर चुका है।

ऐसा लगता था कि उत्तर आखिरकार मिल गया था और परीक्षण के मामले को थोड़ा ठीक कर दिया गया था - आधार वर्ग में एक संपत्ति दिखाई दी, गेट_ विधि टोकन ... जो शोलेग टोकन के साथ मेल खाता था। लेकिन, सभी प्रयासों के बावजूद, परीक्षण के मामले में त्रुटियों के बिना काम किया। यद्यपि बेस क्लास से get_ और set_ विधियों ने फ़िल्टर पास किया, वे सभी चयनित विधियों की सूची के अंत में थे, जिनमें से शुरुआत में सही ShowLog विधि थी, जिसे सफलतापूर्वक RuntimeBinder द्वारा निर्धारित किया गया था।

एकता की भूमिका

लेकिन ऐसा कुछ भी नहीं है कि विषय के शीर्षक में एकता नाम हो। यह निर्भरता इंजेक्शन है , जो Microsoft से एक कंटेनर है, जिसे हम परियोजना में उपयोग करते हैं।
जैसा कि यह निकला, प्रहार विधि का उपयोग करते हुए, उनकी भागीदारी ने किसी तरह इस समस्या की उपस्थिति को प्रभावित किया। मुझे यह देखना था कि कंटेनर को कितना असामान्य बनाता है। थोड़ा अध्ययन करने के बाद, यह स्पष्ट हो गया कि उनके काम का सार यह है: एक विशिष्ट प्रकार का उदाहरण बनाने के लिए, वह एक विशेष विधि उत्पन्न करता है।
इस विधि का कोड कई पूर्वनिर्धारित रणनीतियों के साथ आबाद है। हमारे मामले में, ये तीन रणनीतियाँ थीं:

एक रणनीति जो कंस्ट्रक्टर इंजेक्शन के लिए एक वर्ग के सभी कंस्ट्रक्टरों के माध्यम से चली गई
एक रणनीति जो संपत्ति के इंजेक्शन के लिए एक वर्ग के सभी गुणों से गुजरती थी
एक रणनीति जो विधि इंजेक्शन के लिए सभी वर्ग विधियों के माध्यम से चली गई

वे वास्तव में इस क्रम में किए गए थे। जैसा कि यह निकला, यह इस गणना के क्रम में था कि पहेली का आखिरी टुकड़ा छिपा हुआ था।

यदि आप बस किसी प्रकार का एक उदाहरण बनाते हैं, और फिर इस प्रकार के सभी तरीकों को सूचीबद्ध करते हैं, तो, सबसे पहले, सामान्य तरीके जाएंगे, और उसके बाद ही गुणों और घटनाओं के एक्सेसर्स। लेकिन, यदि इस प्रकार की किसी वस्तु की पहली रचना से पहले हम सूची देते हैं, उदाहरण के लिए, सभी गुण, तो वे जिस तक पहुँचते हैं, वह सूची के शीर्ष पर जाएगा।

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

 typeof(Log).GetEvents(); typeof(Log).GetProperties(); new Log();

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

चौखटे में अंतर

समस्या केवल उन मशीनों पर क्यों दिखाई दी जहां 4 फ्रेमवर्क था, लेकिन दूसरों पर नहीं, इस तथ्य के बावजूद कि परियोजना 4 फ्रेमवर्क के लिए लक्षित है? जैसा कि यह निकला, 4.5 संस्करण में Microsoft.CSharp.dll संस्करण के संस्करण 4 से फ्रेमवर्क के संस्करण 4 में भिन्न होता है, भले ही थोड़ा: संस्करण 4 में यह संस्करण संख्या 4.0.30319.1 है , और संस्करण 4.5 यह संस्करण 4.0-30319.17929 है , जिसमें वे स्पष्ट रूप से ठीक करने में कामयाब रहे। कुछ त्रुटियां।

यदि आप समस्याग्रस्त विधि के कोड को देखते हैं, तो यह काफी बदल गया है, यह था:

 MethodInfo[] methods = type.GetMethods(BindingFlags.Instance ...); for (int i = 0; i < methods.Length; i++) { if (methods[i].MetadataToken == methodInfo.MetadataToken) ...

यह था:

 MethodInfo[] methods = type.GetMethods(BindingFlags.Instance...); for (int i = 0; i < methods.Length; i++) { if (methods[i].MetadataToken == methodInfo.MetadataToken && !(methods[i].Module != methodInfo.Module)) ...

तो, दोहरे नकार के साथ, यह बग 4.5 ढांचे में तय किया गया था।

त्रुटि के परिणाम

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

यह पता चला है कि यदि RuntimeBinder गलत विधि चुनता है तो निम्न त्रुटियाँ हो सकती हैं:

यदि कम मापदंडों वाला एक तरीका चुना जाता है, तो एक IndexOutOfRangeException त्रुटि होती है
यदि समान संख्या में मापदंडों के साथ एक विधि का चयन किया जाता है, जिसके प्रकार पूरी तरह से अपेक्षित लोगों के साथ मेल खाते हैं, तो गलत विधि को बस कहा जाएगा, और यदि विधि कुछ वापस आती है, तो गलत विधि का परिणाम वापस आ जाएगा।
यदि बड़ी संख्या में मापदंडों के साथ एक विधि का चयन किया जाता है, और अपेक्षित मापदंडों के प्रकार पूरी तरह से अपेक्षित लोगों के साथ मेल खाते हैं, तो गलत विधि को बुलाया जाएगा और एक ArgumentException त्रुटि उत्पन्न होगी: कॉल करने के लिए आपूर्ति की गई गलत संख्या तर्क पद्धति

इसके साथ कैसे रहना है?

Connect.microsoft.com पर यह समस्या दर्ज की गई थी, और जो लिखा गया था उसे देखते हुए, 4 फ्रेमवर्क के लिए कोई फिक्स नहीं है और एक भी नहीं होगा। सबसे अधिक संभावना है, इस समस्या का अधिकांश हिस्सा कभी नहीं हो सकता है ऐसा होने के लिए, परिस्थितियों के एक बड़े समूह की आवश्यकता है।

लेकिन, यदि समस्या अभी भी हुई है, तो इस प्रश्न का उत्तर अस्पष्ट है और कई दृष्टिकोण हो सकते हैं। उदाहरण के लिए, शुरू में सभी विधानसभाओं के सभी प्रकारों के सभी तरीकों पर जाने के लिए, ताकि वे सही क्रम में सूचीबद्ध हों, हालांकि यह अजीब है।

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

दूसरे शब्दों में, आप उपयोगकर्ताओं को केवल फ्रेमवर्क संस्करण 4.5 में सेट करके त्रुटियों से बच सकते हैं। यदि यह संभव नहीं है (जैसा कि हमारे मामले में है), आपको या तो गतिशील का उपयोग नहीं करना होगा, या सावधानी के साथ इसका उपयोग करना होगा।

टेस्ट केस

त्रुटि को देखने के लिए, यह कोड .NET फ्रेमवर्क संस्करण 4.0 स्थापित कंप्यूटर के साथ चलाया जाना चाहिए।
इसके विपरीत, सब कुछ ऊपर फ्रेम संस्करण वाले कंप्यूटरों पर काम करना चाहिए।

विधानसभा ए:
A.cs

 public class A { public void MethodForTokenOffset() {} public event EventHandler Event { add { Console.WriteLine("Event, add");} remove {} } public object this[long id] { get { Console.WriteLine("Indexator, get {0}", id); return new { Name = "ThisIsSomeObject" }; } set { Console.WriteLine("Indexator, set {0}", id); } } }

AssemblyB
Program.cs

 class Program { static void Main() { typeof(B).GetEvents(); typeof(B).GetProperties(); new B(); Console.ReadLine(); } }

B.cs

 public class B : A { public B() { try { dynamic obj = new { Handler = new EventHandler((s, e) => Console.WriteLine("EventHandler")), Id = 1L }; MethodForEvent(obj.Handler); var result = MethodForIndexator(obj.Id); Console.WriteLine("Method result, {0}", result); MethodForProperty(obj.Id); } catch (Exception e) { Console.WriteLine(e); } } public void MethodForEvent(EventHandler handler) { Console.WriteLine("MethodForEvent, {0}", handler); } public void StubMethodForOffset() { } public long MethodForIndexator(long id) { Console.WriteLine("MethodForIndexator, {0}", id); return 0; } public void MethodForProperty(long id) { Console.WriteLine("MethodForProperty, {0}", id); } }

.NET डायनेमिक, यूनिटी और रनटाइमबाइंडर बग