👩🏾‍🎨 👨🏿‍🎨 📻 .NET: निर्भरता उपचार 👩‍👩‍👧‍👧 🧤 👷

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

अब मैं JetBrains में काम करते हैं, JetBrains Rider प्रोजेक्ट में, और .NET कोर को राइडर माइग्रेट करने के काम में शामिल हूँ। पहले सर्किट में साझा बुनियादी ढांचे, क्लाउड-आधारित अनुप्रयोग होस्टिंग प्लेटफ़ॉर्म में लगे हुए थे।

Cutscene के तहत DotNext 2019 मास्को सम्मेलन से मेरी रिपोर्ट का प्रतिलेख है, जहां मैंने .NET में असेंबली के साथ काम करते समय कठिनाइयों के बारे में बात की और व्यावहारिक उदाहरणों के साथ दिखाया कि क्या होता है और इससे कैसे निपटना है।

सभी परियोजनाओं में जहां मैंने .NET डेवलपर के रूप में काम किया, मुझे निर्भरता और लोडिंग असेंबली के साथ विभिन्न समस्याओं से निपटना पड़ा। हम इस बारे में बात करेंगे

पोस्ट संरचना:

कुछ निर्भरता के मुद्दे क्या हैं?

जब उन्होंने 2000 के दशक की शुरुआत में .NET फ्रेमवर्क विकसित करना शुरू किया, तो डिपेंडेंसी नरक समस्या पहले से ही ज्ञात थी जब सभी पुस्तकालयों में डेवलपर्स ने परिवर्तनों को तोड़ने की अनुमति दी, और ये पुस्तकालय पहले से संकलित कोड के साथ उपयोग के लिए असंगत हो गए। ऐसी समस्या को कैसे हल करें? पहला उपाय स्पष्ट है। हमेशा पिछड़ी अनुकूलता बनाए रखें। बेशक, यह बहुत यथार्थवादी नहीं है, क्योंकि कोड में डालने के लिए परिवर्तन को तोड़ना बहुत आसान है। उदाहरण के लिए:

ब्रेकिंग परिवर्तन और .NET लाइब्रेरी

यह .NET के लिए विशिष्ट उदाहरण है। हमारे पास एक विधि है, और हमने इसके लिए एक डिफ़ॉल्ट मान के साथ एक पैरामीटर जोड़ने का फैसला किया। यदि हम इसे फिर से इकट्ठा करते हैं तो कोड संकलित करना जारी रखेगा, लेकिन बाइनरी यह दो पूरी तरह से अलग विधियां होंगी: एक विधि में शून्य तर्क हैं, दूसरी विधि में एक तर्क है। यदि निर्भरता के अंदर के डेवलपर ने इस तरह से पिछड़ी संगतता को तोड़ दिया, तो हम उस कोड का उपयोग नहीं कर पाएंगे जो पिछले संस्करण पर इस निर्भरता के साथ संकलित किया गया था।

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

संस्करण नरक एक निर्भरता का उपयोग करने में असमर्थता है जो बाइनरी संगत है, लेकिन एक ही समय में एक संस्करण है जो रनटाइम या किसी अन्य घटक को फिट नहीं करता है जो इन संस्करणों की जांच करता है। .NET में, संस्करण नरक की एक विशिष्ट अभिव्यक्ति FileLoadException है, हालांकि फ़ाइल डिस्क पर स्थित है, लेकिन किसी कारण से इसे रनटाइम के साथ लोड नहीं किया गया है।

.NET में, असेंबलियों के कई अलग-अलग संस्करण हैं - उन्होंने विभिन्न तरीकों से संस्करण नरक को ठीक करने की कोशिश की, और देखें कि क्या हुआ। हमारे पास एक पैकेज है System.Collections.Immutable। बहुत से लोग उसे जानते हैं। उसके पास नूगेट पैकेज का नवीनतम संस्करण 1.6.0 है। इसमें एक पुस्तकालय, संस्करण 1.2.4.0 के साथ एक विधानसभा शामिल है। आपने पाया है कि आपके पास बिल्ड लाइब्रेरी संस्करण 1.2.4.0 नहीं है। कैसे समझें कि यह 1.6.0 NuGet पैकेज में निहित है? यह आसान नहीं होगा। असेंबली वर्जन के अलावा, इस लाइब्रेरी में कई और वर्जन हैं। उदाहरण के लिए, असेंबली फ़ाइल संस्करण, असेंबली सूचना संस्करण। इस NuGet पैकेज में वास्तव में एक ही संस्करण (.NET मानक के विभिन्न संस्करणों के लिए) के साथ तीन अलग-अलग विधानसभाएं हैं।

.NET डॉक्यूमेंटेशन
मानक का निर्माण

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

यह सब क्यों जरूरी है? सबसे पहले, एक रैक पर कदम रखने से बचने के लिए। दूसरे, आप अपने पुस्तकालयों के उपयोगकर्ताओं के लिए जीवन को आसान बना सकते हैं क्योंकि आपके पुस्तकालय के साथ उन्हें निर्भरता की समस्या नहीं होगी, जिसका वे उपयोग कर रहे हैं। यह आपको .NET कोर में जटिल अनुप्रयोगों के प्रवास से निपटने में भी मदद करेगा। और यह सब बंद करने के लिए, आप एक एसआरई बन सकते हैं, यह एक वरिष्ठ (बाइंडिंग) रीडायरेक्ट इंजीनियर है, जिसमें टीम में हर कोई आता है और पूछता है कि कैसे एक और रीडायरेक्ट लिखना है।

सख्त विधानसभा लोड हो रहा है

सख्त असेंबली लोडिंग मुख्य समस्या है जो .NET फ्रेमवर्क पर डेवलपर्स को सामना करना पड़ रहा है। में व्यक्त किया गया है FileLoadException। सख्त असेंबली लोड करने के लिए आगे बढ़ने से पहले, मैं आपको कुछ बुनियादी चीजों की याद दिलाता हूं।

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

.NET में, एक असेंबली रिज़ॉल्यूशन प्रक्रिया है - यह तब होता है जब असेंबली की परिभाषा पहले से ही एक वास्तविक असेंबली में बदल जाती है, जो डिस्क पर होती है या मेमोरी में कहीं लोड होती है। असेंबली रिज़ॉल्यूशन दो बार किया जाता है: बिल्ड स्टेज पर, जब आपके पास * .csproj, और रनटाइम स्टेज में संदर्भ होते हैं, जब आपके पास असेंबली में संदर्भ होते हैं, और कुछ नियमों द्वारा वे असेंबलियों में बदल जाते हैं जिन्हें डाउनलोड किया जा सकता है।

// सरल नाम
MyAssembly, संस्करण = 6.0.0.0,
संस्कृति = तटस्थ, PublicKeyToken = null

// मजबूत नाम
Newtonsoft.Json, संस्करण = 6.0.0.0,
संस्कृति = तटस्थ, PublicKeyToken = 30K4fe6b2a6aeed // PublicKey

आइए समस्या पर चलते हैं। असेंबली का नाम दो मुख्य प्रकार हैं। पहली तरह की असेंबली का नाम सिंपल नेम है। उन्हें इस तथ्य से पहचानना आसान है कि उनके पास PublicKeyToken = null है। एक मजबूत नाम है, उन्हें इस तथ्य से पहचानना आसान है कि उनका PublicKeyToken अशक्त नहीं है, लेकिन कुछ मूल्य है।

एक उदाहरण लेते हैं। हमारे पास एक प्रोग्राम है जो लाइब्रेरी पर MyUtils उपयोगिताओं के साथ निर्भर करता है, और MyUtils का संस्करण 9.0.0.0 है। उसी कार्यक्रम में एक अन्य पुस्तकालय का लिंक है। यह लाइब्रेरी MyUtils का उपयोग करना चाहती है, लेकिन संस्करण 6.0.0.0। MyUtils संस्करण 9.0.0.0, और संस्करण 6.0.0.0 में PublicKeyToken = null है, अर्थात, उनका एक साधारण नाम है। कौन सा संस्करण द्विआधारी विरूपण साक्ष्य में गिर जाएगा, 6.0.0.0 या 9.0.0.0? 9 संस्करण। क्या MyLibrary MyUtils संस्करण 9.0.0.0 का उपयोग कर सकती है, जो बाइनरी विरूपण साक्ष्य में मिला है?

वास्तव में, यह हो सकता है, क्योंकि MyUtils का एक सरल नाम है और, तदनुसार, सख्त असेंबली लोडिंग इसके लिए मौजूद नहीं है।

एक और उदाहरण। MyUtils के बजाय, हमारे पास NuGet की एक पूरी लाइब्रेरी है, जिसका नाम स्ट्रॉन्ग है। नुगेट के अधिकांश पुस्तकालयों का एक मजबूत नाम है।

बिल्ड स्टेज पर, 9.0.0.0 संस्करण BIN से कॉपी किया जाता है, लेकिन रनटाइम में हमें प्रसिद्ध मिल जाता है FileLoadException। MyLibrary के लिए, जो संस्करण 6.0.0.0 से Newtonsoft.Json, संस्करण 9.0.0.0 का उपयोग करने में सक्षम होना चाहता है , के लिए आपको बाइंडिंग रीडायरेक्ट पर जाकर लिखना होगा App.config।

बाइंडिंग पुनर्निर्देश

पुनर्निर्देशित असेंबली संस्करण

यह बताता है कि इस तरह के नाम और इस तरह के publicKeyToken के साथ एक असेंबली को इस तरह के संस्करणों की एक रेंज से इस तरह के संस्करणों में पुनर्निर्देशित किया जाना चाहिए। यह एक बहुत ही सरल रिकॉर्ड है, लेकिन फिर भी यह यहां स्थित है App.config, लेकिन अन्य फाइलों में हो सकता है। machine.config.NET फ्रेमवर्क के अंदर एक फाइल होती है , रनटाइम के अंदर, जिसमें कुछ रीडायरेक्ट के मानक सेट को परिभाषित किया गया है, जो कि .NET फ्रेमवर्क के संस्करण से भिन्न हो सकता है। ऐसा हो सकता है कि 4.7.1 पर आपके लिए कुछ भी काम नहीं करता है, लेकिन 4.7.2 पर यह पहले से ही काम करता है, या इसके विपरीत। आपको यह ध्यान रखने की आवश्यकता है कि पुनर्निर्देशन न केवल आपके पास से आ सकता है .App.config, और इसे डीबग करते समय ध्यान में रखा जाना चाहिए।

हम रीडायरेक्ट के लेखन को सरल बनाते हैं

कोई भी अपने हाथों से बाइंडिंग रीडायरेक्ट लिखना नहीं चाहता है। चलो MSBuild को यह कार्य दें!

स्वचालित बाइंडिंग पुनर्निर्देशन को सक्षम और अक्षम

कैसे करें बाइंडिंग रीडायरेक्ट के साथ काम को सरल बनाने के लिए कुछ सुझाव। टिप एक: MSBuild में बाइंडिंग रीडायरेक्ट ऑटो-जेनरेशन सक्षम करें। में संपत्ति द्वारा चालू किया गया *.csproj। एक परियोजना का निर्माण करते समय, यह एक द्विआधारी विरूपण साक्ष्य में गिरेगा App.config, जो पुस्तकालयों के संस्करणों को पुनर्निर्देशित करता है जो समान कलाकृतियों में हैं। यह केवल रनिंग एप्लिकेशन, कंसोल एप्लिकेशन, WinExe के लिए काम करता है। पुस्तकालयों के लिए, यह काम नहीं करता है, क्योंकि पुस्तकालयों के लिएApp.configबहुधा यह केवल प्रासंगिक नहीं है, क्योंकि यह एक ऐसे अनुप्रयोग के लिए प्रासंगिक है, जो असेंबली को लॉन्च और लोड करता है। यदि आपने लाइब्रेरी के लिए एक कॉन्फिगरेशन बनाया है, तो एप्लिकेशन में कुछ निर्भरताएँ उन लोगों से भिन्न हो सकती हैं जो लाइब्रेरी का निर्माण करते समय थे, और यह पता चला है कि लाइब्रेरी के लिए कॉन्फिगरेशन का कोई मतलब नहीं है। फिर भी, कभी-कभी पुस्तकालयों के विन्यास के लिए अभी भी समझ में आता है।

स्थिति जब हम परीक्षण लिखते हैं। टेस्ट आमतौर पर क्लास लाइंस में पाए जाते हैं और उन्हें रीडायरेक्ट भी करना पड़ता है। टेस्ट फ्रेमवर्क यह पहचानने में सक्षम हैं कि परीक्षणों वाली लाइब्रेरी में एक dll-config है, और परीक्षणों से कोड के लिए उन रीडायरेक्ट्स का आदान-प्रदान करते हैं। आप इन रीडायरेक्ट को स्वचालित रूप से जनरेट कर सकते हैं। अगर हमारे पास एक पुराना प्रारूप है*.csproj, एसडीके-शैली नहीं, आप सरल तरीके से जा सकते हैं, आउटपुट टाइप को Exe में बदल सकते हैं और एक खाली प्रविष्टि बिंदु जोड़ सकते हैं, इससे MSBuild को पुनर्निर्देशन उत्पन्न करने के लिए मजबूर किया जाएगा। आप दूसरे तरीके से जा सकते हैं और हैक का उपयोग कर सकते हैं। आप एक और संपत्ति जोड़ सकते हैं *.csproj, जो MSBuild को इस आउटपुट टाइप के लिए विचार करता है कि आपको अभी भी बाइंडिंग पुनर्निर्देशन उत्पन्न करने की आवश्यकता है। यह विधि, हालांकि यह एक हैक की तरह दिखती है, आपको पुस्तकालयों के लिए रीडायरेक्ट उत्पन्न करने की अनुमति देगा जो Exe में फिर से नहीं किया जा सकता है, और अन्य प्रकार की परियोजनाओं (परीक्षणों को छोड़कर) के लिए। यदि आप आधुनिक Microsoft.NET.Test.Sdk का उपयोग करते हैं

, तो नए प्रारूप के लिए *.csprojरीडायरेक्ट स्वयं उत्पन्न हो जाएगा।

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

असेंबली रेफरेंस जनरेट बाइंडिंग रिडायरेक्ट को हल
करें

उन लोगों के लिए होमवर्क जो बेहतर तरीके से समझना चाहते हैं कि बंधन की पीढ़ी कैसे काम करती है: पता करें कि यह कैसे काम करता है, इसे कोड में देखें। .NET निर्देशिका पर जाएं, नाम संपत्ति के साथ हर जगह टकराएं, जिसका उपयोग पीढ़ी को सक्षम करने के लिए किया जाता है। यह आम तौर पर इस तरह का एक सामान्य दृष्टिकोण है, अगर MSBuild के लिए कुछ अजीब संपत्ति है, तो आप जा सकते हैं और इसके उपयोग का लाभ उठा सकते हैं। सौभाग्य से, संपत्ति आमतौर पर XML कॉन्फ़िगरेशन में उपयोग की जाती है, और आप आसानी से उनका उपयोग पा सकते हैं।

यदि आप जांचते हैं कि इन XML लक्ष्यों में क्या है, तो आप देखेंगे कि यह संपत्ति दो MSBuild कार्यों को ट्रिगर करती है। पहला कार्य कहा जाता है ResolveAssemblyReferences, और यह रीडायरेक्ट का एक सेट उत्पन्न करता है जो फ़ाइलों को लिखा जाता है। दूसरा कार्य GenerateBindingRedirectsपहले कार्य के परिणामों को लिखता हैApp.config। एक्सएमएल लॉजिक है जो पहले कार्य के संचालन को थोड़ा ठीक करता है और कुछ अनावश्यक रीडायरेक्ट्स को हटाता है, या नए जोड़ता है।

XML Configs के लिए वैकल्पिक

XML कॉन्फ़िगरेशन में रीडायरेक्ट रखना हमेशा सुविधाजनक नहीं होता है। हमारे पास ऐसी स्थिति हो सकती है जहां एप्लिकेशन प्लगइन डाउनलोड करता है, और यह प्लगइन अन्य पुस्तकालयों का उपयोग करता है जिनके लिए रीडायरेक्ट की आवश्यकता होती है। इस मामले में, हमें उन रीडायरेक्ट के सेट के बारे में पता नहीं हो सकता है जिनकी हमें आवश्यकता है, या हम XML उत्पन्न नहीं करना चाहते हैं। ऐसी स्थिति में, हम एक AppDomain बना सकते हैं और, जब यह बनाया जाता है, तब भी इसे उस स्थान पर स्थानांतरित कर देता है जहां आवश्यक पुनर्निर्देशन वाला XML स्थित है। रनटाइम में हम असेंबली लोडिंग त्रुटियों को भी ठीक से संभाल सकते हैं। Rantime .NET ऐसा अवसर देता है।

AppDomain.CurrentDomain.AssemblyResolve += (sender, eventArgs) => 
{ 
   var name = eventArgs.Name; 
   var requestingAssembly = eventArgs.RequestingAssembly; 
   
   return Assembly.LoadFrom(...); // PublicKeyToken should be equal
};

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

यह ईवेंट केवल एक एप्लिकेशन डोमेन पर लागू होता है। यदि हमारा प्लगइन अपने अंदर एक AppDomain बनाता है, तो रनटाइम में यह रीडायरेक्ट उनमें काम नहीं करेगा। आपको किसी भी तरह सभी AppDomain में इस ईवेंट को सब्सक्राइब करने की जरूरत है जो प्लगइन ने बनाया है। हम AppDomainManager का उपयोग करके ऐसा कर सकते हैं।

AppDomainManager एक अलग असेंबली है जिसमें एक वर्ग होता है जो एक विशिष्ट इंटरफ़ेस को लागू करता है, और इस इंटरफ़ेस के तरीकों में से एक आपको एप्लिकेशन में बनाए गए किसी भी नए AppDomain को इनिशियलाइज़ करने की अनुमति देगा। एक बार AppDomain बन जाने के बाद, यह विधि कहलाएगी। इसमें आप इस ईवेंट को सब्सक्राइब कर सकते हैं।

सख्त विधानसभा लोडिंग और .NET कोर

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

AppDomain.CurrentDomain.AssemblyResolve += (s, eventArgs) => 
{ 
     CheckForRecursion(); 
     var name = eventArgs.Name;
     var requestingAssembly = eventArgs.RequestingAssembly; 
    
     name.Version = new Version(0, 0); 
     
     return Assembly.Load(name); 
};

हमारे पास असेंबली का नाम है जिसने बूट नहीं किया, हम संस्करण को शून्य करते हैं और Assembly.Loadउसी संस्करण से कॉल करते हैं । यहाँ कोई पुनरावृत्ति नहीं होगी, क्योंकि मैंने पहले ही पुनरावर्तन की जाँच कर ली थी।

MyUtils संस्करण 0.0.2.0 को डाउनलोड करना आवश्यक था। बिन में, हमारे पास MyUtils संस्करण 0.0.1.0 है। हमने संस्करण 0.0.2.0 से संस्करण 0.0 तक पुनर्निर्देशित किया। संस्करण 0.0.1.0 हमारे साथ लोड नहीं होगा। हमारे लिए एक निकास बाहर उड़ जाएगा कि संस्करण 0.0.2 ^{16-1 के} साथ विधानसभा को लोड करना संभव नहीं था । 2 ^16-1 ।

new Version(0, 0) == new Version(0, 0, -1, -1) 

class Version { 
     readonly int _Build; 
     readonly int _Revision; 
     readonly int _Major; 
     readonly int _Minor; 
} 
(ushort) -1 == 65535

संस्करण वर्ग में, सभी घटक अनिवार्य नहीं होते हैं, और वैकल्पिक घटकों के बजाय -1 संग्रहीत होते हैं, लेकिन कहीं अंदर, एक अतिप्रवाह होता है, और बहुत 2 ^16-1 प्राप्त होते हैं । यदि दिलचस्पी है, तो आप वास्तव में यह खोजने की कोशिश कर सकते हैं कि अतिप्रवाह कहां होता है।

यदि आप प्रतिबिंब विधानसभाओं के साथ काम करते हैं और सभी प्रकार प्राप्त करना चाहते हैं, तो यह पता चल सकता है कि सभी प्रकार आपके गेटटेप्स विधि को प्राप्त नहीं कर सकते हैं। असेंबली में एक वर्ग होता है जो किसी अन्य वर्ग से विरासत में मिलता है जो भरी हुई विधानसभा में होता है।

static IEnumerable GetTypesSafe(this Assembly assembly) 
{ 
    try 
    { 
        return assembly.GetTypes(); 
    }
    catch (ReflectionTypeLoadException e) 
   { 
        return e.Types.Where(x => x != null); 
    } 
}

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

मजबूत नामकरण

स्ट्रांग-असेंबली असेंबलियों से

बात करते हैं कि स्ट्रिक्ट असेंबली लोडिंग किन कारणों से होती है, यह स्ट्रॉन्ग नाम है।
एसिमेट्रिक एनक्रिप्शन का उपयोग करके कुछ निजी कुंजी द्वारा असेंबली का नाम सशक्त हस्ताक्षर है। PublicKeyToken इस विधानसभा की सार्वजनिक कुंजी हैश है।

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

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

मजबूत नाम: विरासत?

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

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

एक पुस्तकालय है जिसे System.Reactive कहा जाता है। पहले, ये कई NuGet पैकेज थे, उनमें से एक Rx-Linq है। यह सिर्फ एक उदाहरण है, बाकी पैकेजों के लिए भी यही है। दूसरे संस्करण में, यह एक Microsoft कुंजी के साथ हस्ताक्षर किया गया था। तीसरे संस्करण में, वह github.com/dotnet प्रोजेक्ट में रिपॉजिटरी में चले गए और उनके पास .NET फाउंडेशन हस्ताक्षर होना शुरू हुआ। पुस्तकालय, वास्तव में, मजबूत नाम बदल गया है। NuGet पैकेज का नाम बदल दिया गया था, लेकिन असेंबली को पहले की तरह ही अंदर बुलाया जाता है। दूसरे संस्करण से तीसरे तक रीडायरेक्ट कैसे करें? यह पुनर्निर्देशित नहीं किया जा सकता है।

मजबूत नाम सत्यापन

कैसे करें: मजबूत नाम बाईपास सुविधा को अक्षम करें

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

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

कब फिल्म्सवॉर्म वर्जन बदलना है

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

उदाहरण के लिए, NuGet पैकेज Newtonsoft.Json, इसके कई संस्करण हैं: 12.0.1, 12.0.2, और इसी तरह - इन सभी पैकेजों में संस्करण 12.0.0.0 के साथ एक असेंबली है। सिफारिश यह है कि विधानसभा संस्करण को तब अपडेट किया जाना चाहिए जब NuGet पैकेज का एक प्रमुख संस्करण बदलता है।

जाँच - परिणाम

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

.NET मानक

हम .NET मानक को पास करते हैं। यह .NET फ्रेमवर्क में संस्करण नरक से बहुत निकट से संबंधित है। .NET मानक पुस्तकालयों को लिखने के लिए एक उपकरण है जो .NET प्लेटफ़ॉर्म के विभिन्न कार्यान्वयनों के साथ संगत है। कार्यान्वयन .NET फ्रेमवर्क, .NET कोर, मोनो, यूनिटी और ज़मारिन को संदर्भित करता है।

* प्रलेखन के लिए लिंक

यह रनटाइम के विभिन्न संस्करणों के विभिन्न संस्करणों के लिए .NET मानक समर्थन तालिका है। और यहां हम देख सकते हैं कि .NET फ्रेमवर्क किसी भी तरह से .NET मानक संस्करण 2.1 का समर्थन नहीं करता है। .NET फ्रेमवर्क की रिलीज़, जो .NET मानक 2.1 का समर्थन करेगी और बाद में, अभी तक नियोजित नहीं है। यदि आप एक पुस्तकालय विकसित कर रहे हैं और चाहते हैं कि यह .NET फ्रेमवर्क पर उपयोगकर्ताओं के लिए काम करे, तो आपके पास .NET मानक 2.0 के लिए एक लक्ष्य होना चाहिए। इस तथ्य के अलावा कि .NET फ्रेमवर्क .NET मानक के नवीनतम संस्करण का समर्थन नहीं करता है, आइए तारांकन पर ध्यान दें। .NET फ्रेमवर्क 4.6.1 .NET मानक 2.0 का समर्थन करता है, लेकिन तारांकन के साथ। प्रलेखन में सीधे एक ऐसा फुटनोट है, मुझे यह तालिका कहां से मिली।

एक उदाहरण परियोजना पर विचार करें। .NET फ्रेमवर्क पर एक आवेदन जिसमें .NET निर्भरता को लक्षित करने वाली एक निर्भरता है। कुछ इस तरह: ConsoleApp और ClassLibrary। लक्ष्य लाइब्रेरी .NET मानक। जब हम इस परियोजना को एक साथ रखेंगे, तो यह हमारे बिन में इस तरह होगा।

हमारे पास एक सौ DLL होंगे, जिनमें से केवल एक ही आवेदन से संबंधित है, बाकी सब कुछ .NET मानक का समर्थन करने के लिए आया है। तथ्य यह है कि .NET मानक 2.0 .NET फ्रेमवर्क 4.6.1 की तुलना में बाद में दिखाई दिया, लेकिन एक ही समय में वे एपीआई संगत बन गए, और डेवलपर्स ने .NET 2.0.1 में मानक 2.0 समर्थन जोड़ने का फैसला किया। हमने इसे मूल रूप से ( netstandard.dllरनटाइम में शामिल करने से) नहीं किया था, लेकिन इस तरह से .NET मानक *। Dll और अन्य सभी विधानसभा पहलुओं को सीधे BIN में रखा गया है।

यदि हम .NET फ्रेमवर्क के उस संस्करण की निर्भरता को देखते हैं जिसे हम लक्षित करते हैं और पुस्तकालयों की संख्या जो बिन में गिर गई है, तो हम देखेंगे कि 4.7.1 में उनमें से बहुत सारे नहीं हैं, और 4.7.2 के बाद से सभी अतिरिक्त पुस्तकालय नहीं हैं। वहां मूल रूप से मानक का समर्थन किया जाता है।

यह .NET डेवलपर्स में से एक से एक ट्वीट है, जो इस समस्या का वर्णन करता है और अगर हमारे पास .NET स्टैंडर्ड लाइब्रेरी है तो .NET फ्रेमवर्क संस्करण 4.7.2 का उपयोग करने की सिफारिश की जाती है। यहां संस्करण 2.0 के साथ भी नहीं, लेकिन संस्करण 1.5 के साथ।

जाँच - परिणाम

यदि संभव हो, तो अपनी परियोजना में लक्ष्य फ्रेमवर्क को कम से कम 4.7.1, अधिमानतः 4.7.2 तक बढ़ाएं। यदि आप लाइब्रेरी उपयोगकर्ताओं के लिए जीवन को आसान बनाने के लिए एक पुस्तकालय विकसित कर रहे हैं, तो .NET फ्रेमवर्क के लिए एक अलग लक्ष्य बनाएं, यह बड़ी संख्या में उन dll से बचाएगा जो किसी चीज के साथ संघर्ष कर सकते हैं।

.NET कोर

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

.NET कोर एप्लीकेशन

एक सामान्य .NET कोर एप्लीकेशन कैसा दिखता है? यह निर्भर करता है कि वास्तव में यह कैसे तैनात किया जाता है, आखिरकार यह क्या करने जा रहा है। हमारे पास कई परिदृश्य हो सकते हैं। पहला एक फ्रेमवर्क-निर्भर परिनियोजन है। यह .NET फ्रेमवर्क के समान है जब एप्लिकेशन कंप्यूटर पर रनटाइम प्री-इंस्टॉल का उपयोग करता है। यह एक स्व-परिनियोजित तैनाती हो सकती है, यह तब है जब एप्लिकेशन रनटाइम करता है। और एक एकल-फ़ाइल परिनियोजन हो सकता है, यह तब होता है जब हम एक एक्स-फ़ाइल प्राप्त करते हैं, लेकिन इस exe-फ़ाइल के अंदर .NET कोर के मामले में स्व-निहित अनुप्रयोग की एक कलाकृति होती है, यह एक स्व-निष्कर्षण संग्रह है।

हम केवल फ्रेमवर्क पर निर्भर तैनाती पर विचार करेंगे। हमारे पास एप्लिकेशन के साथ एक dll है, दो कॉन्फ़िगरेशन फाइलें हैं, जिनमें से पहली आवश्यकता है, यह runtimeconfig.jsonऔरdeps.json। .NET कोर 3.0 के साथ शुरू, एक exe फ़ाइल उत्पन्न होती है जिसे चलाने के लिए एप्लिकेशन को अधिक सुविधाजनक बनाने की आवश्यकता होती है, ताकि आपको .NET कमांड दर्ज करने की आवश्यकता न हो अगर हम विंडोज पर हैं। निर्भरताएँ इस विरूपण साक्ष्य में आती हैं। .NET कोर 3.0 से शुरू होकर, .NET कोर 2.1 में आपको किसी अन्य संपत्ति को प्रकाशित या उपयोग करने की आवश्यकता होती है *.csproj।

साझा रूपरेखाएँ, `.runtimeconfig.json`

.runtimeconfig.jsonइसमें रनटाइम सेटिंग शामिल है जिसे इसे चलाने के लिए आवश्यक है। यह इंगित करता है कि किस एप्लिकेशन के तहत साझा फ़्रेमवर्क लॉन्च किया जाएगा, और यह इस तरह दिखता है। हम इंगित करते हैं कि एप्लिकेशन "Microsoft.NETCore.App" संस्करण 3.0.0 के तहत चलेगा, अन्य साझा रूपरेखा हो सकती है। अन्य सेटिंग्स भी यहां हो सकती हैं। उदाहरण के लिए, आप सर्वर गारबेज कलेक्टर को सक्षम कर सकते हैं।

.runtimeconfig.jsonपरियोजना की विधानसभा के दौरान उत्पन्न। और अगर हम सर्वर जीसी को शामिल करना चाहते हैं, तो हमें किसी भी तरह इस फाइल को अग्रिम रूप से संशोधित करने की आवश्यकता है, इससे पहले कि हम परियोजना को इकट्ठा करते हैं, या इसे हाथ से जोड़ते हैं। आप यहां अपनी सेटिंग्स को इस तरह जोड़ सकते हैं। हम संपत्ति को या तो इसमें शामिल कर सकते हैं *.csproj, यदि ऐसी संपत्ति .NET डेवलपर्स द्वारा प्रदान की जाती है, या यदि संपत्ति प्रदान नहीं की जाती है, तो हम एक फाइल बना सकते हैं जिसे कहा जाता हैruntimeconfig.template.jsonऔर यहां आवश्यक सेटिंग्स लिखें। असेंबली के दौरान, इस टेम्पलेट में अन्य आवश्यक सेटिंग्स को जोड़ा जाएगा, उदाहरण के लिए, समान साझा फ़्रेमवर्क।

साझा रूपरेखा रनटाइम और लाइब्रेरी का एक सेट है। वास्तव में, .NET फ्रेमवर्क रनटाइम के रूप में एक ही बात, जो मशीन पर सिर्फ एक बार स्थापित की जाती थी और सभी के लिए एक संस्करण था। साझा किए गए फ़्रेमवर्क, और, एकल .NET फ्रेमवर्क रनटाइम के विपरीत, संस्करणित किया जा सकता है, विभिन्न एप्लिकेशन इंस्टॉल किए गए रनटाइम के विभिन्न संस्करणों का उपयोग कर सकते हैं। साथ ही शेयर्ड फ्रेमवर्क विरासत में मिल सकता है। साझा किए गए फ़्रेमवर्क को डिस्क पर ऐसे स्थानों में ही देखा जा सकता है, जैसा कि आमतौर पर सिस्टम पर स्थापित होता है।

कई मानक साझा किए गए फ्रेमवर्क हैं, उदाहरण के लिए, Microsoft.NETCore.App, जो नियमित कंसोल अनुप्रयोगों, AspNetCore.App, वेब अनुप्रयोगों के लिए, और WindowsDesktop.App, .NET Core 3 में नए साझा किए गए फ्रेमवर्क को चलाता है, जो दरवाजे अनुप्रयोगों को चलाता है। विंडोज फॉर्म और WPF पर। पिछले दो साझा ढांचे अनिवार्य रूप से कंसोल अनुप्रयोगों के लिए आवश्यक पहले एक को पूरक करते हैं, अर्थात, वे एक नया रनटाइम नहीं करते हैं, लेकिन बस आवश्यक पुस्तकालयों के साथ मौजूदा एक को पूरक करते हैं। यह वंशानुक्रम ऐसा लगता है कि साझा फ़्रेमवर्क निर्देशिकाओं runtimeconfig.jsonमें भी हैं, जिसमें आधार साझा फ़्रेमवर्क निर्दिष्ट है।

निर्भरता प्रकट ( .deps.json)

डिफ़ॉल्ट जांच - .NET कोर

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

Jetbrains सवार

राइडर एक .NET IDE है। हर कोई नहीं जानता कि राइडर एक आईडीई है जो इंटेलीज आईडीईए पर आधारित एक फ्रंटेंड है और जावा और कोटलिन में लिखा गया है, और एक बैकएंड है। बैकएंड अनिवार्य रूप से R # है, जो IntelliJ IDEA के साथ संवाद कर सकता है। यह बैकएंड अभी एक क्रॉस-प्लेटफॉर्म .NET अनुप्रयोग है।
यह कहां चलता है? विंडोज .NET फ्रेमवर्क का उपयोग करता है, जो उपयोगकर्ता के कंप्यूटर पर स्थापित है। अन्य सूचना प्रणालियों पर, लिनक्स और मैक पर, मोनो का उपयोग किया जाता है।

यह एक आदर्श समाधान नहीं है जब हर जगह अलग-अलग रनटाइम होते हैं, और मैं अगले राज्य में आना चाहता हूं ताकि राइडर .NET कोर पर चलता हो। प्रदर्शन में सुधार करने के लिए, क्योंकि .NET कोर में सभी नवीनतम सुविधाएँ इसके साथ जुड़ी हुई हैं। स्मृति की खपत को कम करने के लिए। अब एक समस्या है कि मोनो मेमोरी के साथ कैसे काम करता है।

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

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

ऐसी विशेषताएं जो राइडर को .NET कोर में ट्रांसलेट करना मुश्किल बनाती हैं

विजुअल स्टूडियो, भले ही इसमें आर # इंस्टॉल नहीं किया गया है, बड़े समाधानों पर आउट ऑफ मेमोरी से क्रैश हो जाता है, जिसके अंदर एसडीके-स्टाइल * .csproj के साथ प्रोजेक्ट हैं । SDK- शैली * .csproj एक पूर्ण .NET कोर रिलोकेशन की मुख्य स्थितियों में से एक है।

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

फेसला

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

आपको किस हैक्स में जाना है?

एक हैक: हम एक ऐसी विधि को कॉल करना चाहते हैं जो केवल फ्रेमवर्क में उपलब्ध है, उदाहरण के लिए, इस विधि की आवश्यकता आर # में है, लेकिन कोर पर नहीं। समस्या यह है कि अगर कोई विधि नहीं है, तो जेआईटी संकलन के दौरान इसे कॉल करने वाली विधि पहले गिर जाएगी MissingMethodException। यही है, एक विधि जो मौजूद नहीं है उसने उस पद्धति को बर्बाद कर दिया है जो इसे कॉल करता है।

static void Method() { 
  if (NetFramework) 
     CallNETFrameworkOnlyMethod();

  ... 
} 
[MethodImpl(MethodImplOptions.NoInlining)] 
static void CallNETFrameworkOnlyMethod() { 
  NETFrameworkOnlyMethod(); 
}

समाधान यहां है: हम असंगत तरीकों से अलग-अलग तरीकों से कॉल करते हैं। एक और समस्या है: इस तरह की विधि इनलाइन हो सकती है, इसलिए हम इसे एक विशेषता के साथ चिह्नित करते हैं NoInlining।

हैक नंबर दो: हमें सापेक्ष पथों में विधानसभाओं को लोड करने में सक्षम होना चाहिए। हमारे पास फ्रेमवर्क के लिए एक असेंबली है, .NET कोर के लिए एक विशेष संस्करण है। हम .NET कोर संस्करण को .NET कोर के लिए कैसे डाउनलोड करते हैं?

वे हमारी मदद करेंगे .deps.json। आइए .deps.jsonSystem.Diagnostics.PerformanceCounter लाइब्रेरी को देखें। ऐसा पुस्तकालय इसके संदर्भ में उल्लेखनीय है.deps.json। इसमें एक रनटाइम सेक्शन है, जिसमें लाइब्रेरी का एक संस्करण इसके सापेक्ष पथ के साथ इंगित किया गया है। यह लाइब्रेरी, असेंबली को सभी रनटाइम पर लोड किया जाएगा, और यह केवल निष्पादन को फेंकता है। यदि, उदाहरण के लिए, यह लिनक्स पर लोड होता है, तो परफॉरमेंस एन्काउंटर लिनक्स पर डिजाइन पर काम नहीं करता है, और एक PlatformNotSupportedException वहां से उड़ जाता है। इसमें .deps.jsonएक रनटाइमटैग सेक्शन भी है और यहां पहले से ही इस विधानसभा के संस्करण को विशेष रूप से विंडोज के लिए इंगित किया गया है, जहां परफॉरमेंस कार्य करना चाहिए।

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

अगली हैक: हम WindowsBase बनाने के लिए लिनक्स पर और मैक मॉक पर डाउनलोड करना चाहते हैं। समस्या यह है कि WindowsBase नाम की असेंबली पहले से ही साझा फ्रेमवर्क में मौजूद है Microsoft.NETCore.App, भले ही हम विंडोज पर न हों। Windows साझा किए गए फ़्रेमवर्क पर, Microsoft.WindowsDesktop.AppWindowsBase उस संस्करण को फिर से परिभाषित करता है जो अंदर है NETCore.App। आइए .deps.jsonइन फ्रेमवर्क को देखें, उन अनुभागों में अधिक सटीक रूप से जो विंडोजबेस का वर्णन करते हैं।

यहाँ अंतर है:

अगर कुछ पुस्तकालय संघर्ष और कई में मौजूद है .deps.json, तो उनमें से अधिकतम से मिलकर जोड़ी के लिए चयन किया जाता है assemblyVersionऔर fileVersion। .NET गाइड का कहना है कि fileVersionइसे केवल विंडोज एक्सप्लोरर में दिखाने की जरूरत है, लेकिन ऐसा नहीं है, यह गिर जाता है.deps.json। यह केवल मामला है कि मैं जब संस्करण में निर्धारित के बारे में पता है .deps.json, assemblyVersionऔर fileVersion, वास्तव में किया जाता है। अन्य सभी मामलों में, मैंने एक व्यवहार देखा कि चाहे जो भी संस्करण .deps.jsonलिखे गए हों, असेंबली वैसे भी लोड होती रहेगी।

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

समाधान: runtimeconfig में कस्टम कॉन्फ़िगरेशन सक्षम करें। यह सेटिंग वास्तव में .NET कोर 1.0 के साथ पिछड़े संगतता के लिए आवश्यक है।

जाँच - परिणाम

तो, .runtime.jsonऔर .deps.json.NET कोर पर - ये एक तरह के एनालॉग्स हैं App.config। App.configउदाहरण के लिए, आप रिश्तेदार चीजों को लोड करते हैं। इसका उपयोग करते हुए .deps.json, इसे मैन्युअल रूप से फिर से लिखना, यदि आप एक बहुत ही जटिल परिदृश्य रखते हैं, तो आप .NET कोर पर असेंबलियों के लोडिंग को कस्टमाइज़ कर सकते हैं।

डीबग असेंबली डाउनलोड

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

संलयन लॉग

बैक टू बेसिक्स: फ्यूजन लॉग व्यूअर टू डिबग का प्रयोग अस्पष्ट त्रुटियों को
मिटाता है

। .NET फ्रेमवर्क में असेंबलियों को लोड करने के लिए तंत्र को फ्यूजन कहा जाता है, और यह जानता है कि डिस्क पर क्या किया गया, इसे कैसे लॉग किया जाए। लॉगिंग को सक्षम करने के लिए, आपको रजिस्ट्री में विशेष सेटिंग्स जोड़ने की आवश्यकता है। यह बहुत सुविधाजनक नहीं है, इसलिए यह उपयोगिताओं का उपयोग करने के लिए समझ में आता है, अर्थात् फ्यूजन लॉग व्यूअर और फ्यूजन ++। फ़्यूज़न लॉग व्यूअर एक मानक उपयोगिता है जो विज़ुअल स्टूडियो के साथ आती है और इसे विज़ुअल स्टूडियो कमांड लाइन, विज़ुअल स्टूडियो डेवलपर कमांड प्रॉम्प्ट से लॉन्च किया जा सकता है। फ्यूजन ++ इस उपकरण का एक खुला स्रोत एनालॉग है जिसमें एक अच्छा इंटरफ़ेस है।

फ्यूजन लॉग व्यूअर ऐसा दिखता है। यह WinDbg से भी बदतर है क्योंकि यह खिड़की भी खिंचाव नहीं करती है। फिर भी, आप यहां चेकमार्क को छेद सकते हैं, हालांकि यह हमेशा स्पष्ट नहीं होता है कि चेकमार्क का कौन सा सेट सही है।

फ़्यूज़न ++ में एक "स्टार्ट लॉगिंग" बटन है, और फिर "स्टॉप लॉगिंग" बटन दिखाई देता है। इसमें, आप लोडिंग असेंबलियों के बारे में सभी रिकॉर्ड देख सकते हैं, लॉग्स को पढ़ सकते हैं कि वास्तव में क्या हो रहा था। ये लॉग संक्षिप्त रूप में कुछ इस तरह दिखते हैं।

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

रनटाइम इवेंट्स

लॉग

ऑन रनटाइम इवेंट्स मोनो पर, आप पर्यावरण चर का उपयोग करके लॉगिंग को सक्षम कर सकते हैं, और लॉग को अंततः लिखा जाएगा stdoutऔर stderr। इतना सुविधाजनक नहीं है, लेकिन समाधान काम कर रहा है।

डिफ़ॉल्ट प्रोबिंग - .NET कोर
डॉक्यूमेंटेशन / डिज़ाइन डॉक्स / होस्ट ट्रेसिंग

। .NET कोर में एक विशेष पर्यावरण चर भी होता COREHOST_TRACEहै जिसमें लॉग इन करना शामिल होता है stderr। .NET कोर 3.0 के साथ, आप एक चर में पथ निर्दिष्ट करके किसी फ़ाइल में लॉग लिख सकते हैं COREHOST_TRACEFILE।

एक ऐसी घटना होती है जब असेंबली लोड करने में विफल हो जाती है। यह एक घटना है AssembleResolve। एक दूसरी उपयोगी घटना है, यह FirstChanceException। आप इसे सब्सक्राइब कर सकते हैं और असेंबली लोड करने के बारे में एक त्रुटि प्राप्त कर सकते हैं, भले ही किसी ने कोशिश लिखी हो..जहाँ और सभी निष्पादनों को याद किया, जहाँFileLoadExceptionहुई। यदि एप्लिकेशन पहले से ही संकलित किया गया है, तो आप इसे शुरू कर सकते हैं perfview, और यह .NET निष्पादन की निगरानी कर सकता है, और वहां आप डाउनलोड फ़ाइलों से संबंधित पा सकते हैं।

जाँच - परिणाम

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

मैं दृढ़ता से अनुशंसा करता हूं कि आप निम्नलिखित लिंक पढ़ें:

DotNext 2020 Piter . , 8 JUG Ru Group.

.NET: निर्भरता उपचार

पोस्ट संरचना:

कुछ निर्भरता के मुद्दे क्या हैं?

सख्त विधानसभा लोड हो रहा है

बाइंडिंग पुनर्निर्देश

हम रीडायरेक्ट के लेखन को सरल बनाते हैं

XML Configs के लिए वैकल्पिक

सख्त विधानसभा लोडिंग और .NET कोर

मजबूत नामकरण

मजबूत नाम: विरासत?

मजबूत नाम सत्यापन

जाँच - परिणाम

.NET मानक

जाँच - परिणाम

.NET कोर

.NET कोर एप्लीकेशन

साझा रूपरेखाएँ, .runtimeconfig.json

Jetbrains सवार

ऐसी विशेषताएं जो राइडर को .NET कोर में ट्रांसलेट करना मुश्किल बनाती हैं

फेसला

आपको किस हैक्स में जाना है?

जाँच - परिणाम

डीबग असेंबली डाउनलोड

संलयन लॉग

रनटाइम इवेंट्स

जाँच - परिणाम

More articles:

साझा रूपरेखाएँ, `.runtimeconfig.json`