.NET 4 कॉन्फिगरेशन में 'useLegacyV2RuntimeActivationPolicy' क्या करता है?

214

एक प्रोजेक्ट को परिवर्तित करते समय, जिसने स्लिमडीएक्स का उपयोग किया, और इसलिए इसका अप्रबंधित कोड है। .NET 4.0 के लिए मैं निम्नलिखित त्रुटि में भाग गया:

मिश्रित मोड असेंबली रनटाइम के संस्करण 'v2.0.50727' के खिलाफ बनाया गया है और अतिरिक्त कॉन्फ़िगरेशन जानकारी के बिना 4.0 रनटाइम में लोड नहीं किया जा सकता है।

चारों ओर गुग्लिंग ने मुझे समाधान दिया, जो इसे एप्लिकेशन कॉन्फिगर में जोड़ना है:

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

मेरा सवाल है, क्या useLegacyV2RuntimeActivationPolicyकर रहा है? मुझे इसके बारे में कोई दस्तावेज नहीं मिल रहा है।

— कैमरन मैकफारलैंड
स्रोत

165

थोड़े समय (और अधिक खोज) के बाद, मुझे जोमो फिशर द्वारा यह ब्लॉग प्रविष्टि मिली ।

हाल की समस्याओं में से एक हमने देखा है कि, साइड-बाय-साइड रनटाइम के लिए समर्थन के कारण, .NET 4.0 ने पुराने मिश्रित-मोड असेंबली के लिए बांधने के तरीके को बदल दिया है। उदाहरण के लिए, ये असेंबली C ++ \ CLI से संकलित की जाती हैं। वर्तमान में उपलब्ध DirectX असेंबलियाँ मिश्रित मोड हैं। यदि आप इस तरह का संदेश देखते हैं तो आप जानते हैं कि आप इस मुद्दे पर भाग चुके हैं:

मिश्रित मोड असेंबली रनटाइम के संस्करण 'v1.1.4322' के खिलाफ बनाया गया है और अतिरिक्त कॉन्फ़िगरेशन जानकारी के बिना 4.0 रनटाइम में लोड नहीं किया जा सकता है।

[कटाव]

अनुप्रयोगों के लिए अच्छी खबर यह है कि आपके पास इन विधानसभाओं के लिए .NET 2.0 युग के बंधन को वापस करने का विकल्प है।
<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v4.0"/>
</startup>

तो ऐसा लगता है कि मिश्रित-मोड असेंबलियों को रनटाइम लोड करने का तरीका बदल गया है। मुझे इस परिवर्तन के बारे में कोई विवरण नहीं मिला है, या ऐसा क्यों किया गया। लेकिन useLegacyV2RuntimeActivationPolicyविशेषता CLR 2.0 लोडिंग पर वापस लौटती है।

— कैमरन मैकफारलैंड
स्रोत

28

यह यहाँ ध्यान देने योग्य है कि इस बीच मार्कलियो उत्तर ( stackoverflow.com/questions/1604663/… ) इस परिवर्तन के बारे में उनकी गहन व्याख्या के लिए एक लिंक प्रदान करता है।

— स्टीफन ओपल

1

इसका पूरी तरह से विवरण MSDN पर पाया जा सकता है (हालाँकि यह ऊपर वर्णित समाधान का स्पष्ट रूप से उल्लेख नहीं करता है): msdn.microsoft.com/en-us/magazine/ee819091.aspx

— मौहम्मद सोइदाने

क्या होगा अगर मैंने इसे अपने एप्लिकेशन के लिए कॉन्फ़िगर और मेरे यूनिटटेस्ट प्रोजेक्ट के लिए एक कॉन्फिगरेशन दोनों के लिए जोड़ दिया है और मुझे अभी भी परीक्षण के दौरान फाइल लोड की त्रुटि प्राप्त हो रही है। क्या मुझे एक नया प्रश्न पोस्ट करना चाहिए?

— कोडेनमेकेन

126

इस विशेषता पर जानकारी के शून्य के साथ मदद करने के लिए हाल ही में मैंने एक स्पष्टीकरण लिखा है। http://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx (इंटरनेट आर्काइव वेबैक मशीन लिंक)

सबसे अधिक प्रासंगिक बिट्स उद्धृत करने के लिए:

[स्थापित .NET] v4 "गैर-प्रभावकारी" है। इसे स्थापित होने पर मौजूदा घटकों के व्यवहार को नहीं बदलना चाहिए।

UseLegacyV2RuntimeActivationPolicy विशेषता मूल रूप से आपको कहती है, “मुझे विरासत शिम एपीआई पर कुछ निर्भरताएं हैं। कृपया उन्हें चुने हुए रनटाइम के संबंध में जिस तरह से इस्तेमाल किया गया है, उसे काम करें। ”

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

पूरी पोस्ट इसे और अधिक विस्तार से बताती है। RTM पर, इस पर MSDN डॉक्स बेहतर होना चाहिए।

— मार्क मिलर
स्रोत

user20493, क्या आप अपने ऐप को एनवायरनमेंट वैरिएबल Complus_CLRLoadLogDir के साथ चला सकते हैं, जिस ऐप को खाली डायरेक्टरी में सेट किया गया है, जिसके परिणामस्वरूप ऐप लॉग इन कर रहा है और परिणामी लॉग्स को शेयर कर रहा है (कृपया शेयर करने से पहले किसी भी PII के लिए स्क्रब करें)। यह समझाने में मदद कर सकता है कि क्या हो रहा है। कॉन्फ़िगर विशेषता उस संदर्भ पर लागू नहीं हो सकती है जिसमें आपका ऐप चल रहा है।

— मार्क मिलर

इस लिंक से आपको यह समझने में भी मदद मिलेगी कि समस्या क्या है, और समाधान आपके लिए क्या कर रहा है: msdn.microsoft.com/en-us/magazine/ee819091.aspx

— Mouhammed Soueidane