.NET 4.5 - .NET 4.0 के लिए इन-प्लेस अपग्रेड

वीएस 2011 और विंडोज 8 के बीटा संस्करणों के साथ, बहुत से लोग .NET 4.5 के साथ इंस्टॉल और डील करेंगे। .NET 4.5 कई नए संवर्द्धन जोड़ता है जो काफी पारदर्शी हैं, लेकिन यह समझना महत्वपूर्ण है कि यह आपके मशीन पर आपके CLR दृष्टिकोण से कैसे काम करता है।

जब .NET 4.5 स्थापित होता है, तो यह वास्तव में आपके मशीन पर .NET 4.0 को बदल देता है। .NET 4.0 के नए संस्करण के साथ .NET 4.0 को अधिलेखित किया जा रहा है, जो कि Microsoft के अनुसार, 100% संगतता की गारंटी देता है। 100% संगतता आकर्षक लगती है, लेकिन हम सभी जानते हैं कि ऐसा परिणाम प्राप्त करना काफी मुश्किल है। लेकिन पिछड़ी संगतता की तुलना में बहुत अधिक दिलचस्प बात है, जो कि .NET 4.5 की तैनाती की स्थिति को सबसे अच्छा और असुविधाजनक है।

इन-प्लेस अपग्रेड का क्या मतलब है?

जब आप .NET 4.5 स्थापित करते हैं, तो .NET 4.0 से आपके असेंबली \ Windows \ .NET फ्रेमवर्क \ V4.0.30319 फ़ोल्डर में नए सेट के साथ ओवरराइट किया जाता है। नतीजतन, आपको फिर से लिखे गए असेंबली के साथ छोड़ दिया जाता है, साथ ही नए लोगों का एक समूह (उदाहरण के लिए, विधानसभा System.Net.Http)। निम्न छवि .NET 4.5 (बाएं) और .NET 4.0 (दाएं) के लिए System.dll असेंबली दिखाती है:



जाहिर है, ये अलग-अलग आकार के साथ अलग-अलग फाइलें हैं (दिलचस्प बात यह है कि, .NET संस्करण 4.5 छोटा है)।

वह सब नहीं है। यदि .NET 4.5 के साथ किसी एप्लिकेशन के रनटाइम में आपने एन्वायरनमेंट तक पहुंच स्थापित की है। संपत्ति, तो भी आपको 4.0.30319 मिलेगी।

यदि आप .NET 4.5 में System.dll असेंबली गुण विंडो खोलते हैं, तो आप भी देखेंगे



कृपया ध्यान दें कि फ़ाइल संस्करण अभी भी 4.0.xxx है।

लेआउट संख्या में अंतर: .NET 4.0 में यह 261 है, जबकि .NET 4.5 के वर्तमान बीटा संस्करण में यह 17379 है। मुझे लगता है कि आप .NET के संस्करण को निर्धारित करने के लिए लेआउट संख्या का उपयोग कर सकते हैं: यदि यह 17000 से अधिक है, तो यह .NET 4.5 है, हालांकि, यह एक बहुत सुंदर समाधान नहीं है।

.NET 4.5 या .NET 4.0 के किस संस्करण का उपयोग किया जाता है, यह निर्धारित करने के लिए कोई सरल या स्पष्ट तरीका नहीं है, क्योंकि वे आवेदन के लिए समान हैं।

.NET 4.5 के लिए संकलन, लेकिन .NET 4.0 पर चलना एक अच्छा विचार नहीं है

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

आप स्वाभाविक रूप से .NET 4.5 के लिए .NET 4.0 के लिए लिखे गए एप्लिकेशन चला सकते हैं और यह बहुत अधिक फैंसी के बिना काम करना चाहिए।

परिभाषा संस्करणों

यदि आप .NET 4.5 के लिए एक आवेदन लिख रहे हैं, तो कॉन्फ़िगरेशन फ़ाइल का उपयोग करके इसके निष्पादन पर आपका कुछ नियंत्रण है। आप निर्दिष्ट कर सकते हैं कि आवेदन की जरूरत है। .NET 4.5, उदाहरण के लिए, इस तरह:

<?xml version="1.0" encoding="utf-8" ?> <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework, Version=v4.5" /> </startup> </configuration> 

ऐसा इसलिए किया जाता है ताकि .NET 4.5 पर शुरू न होने पर एप्लिकेशन, रनटाइम पर क्रैश होने के बजाय एक त्रुटि की रिपोर्ट करे।

इसके अलावा, .NET 4.5 वेब अनुप्रयोग समान परिणाम प्राप्त करने के लिए targetFramework संपत्ति का उपयोग कर सकते हैं।

 <configuration> <system.web> <compilation debug="true" strict="false" explicit="true" targetFramework="4.5" /> </system.web> </configuration> 

यह स्टैंडअलोन डेस्कटॉप और वेब अनुप्रयोगों के लिए अच्छी तरह से काम करता है, लेकिन प्रोजेक्ट में बिल्ड के लिए कोई रास्ता नहीं है। .NET 4.0 पर एक प्रोजेक्ट के लिए, .NET 4.5 असेंबली किसी भी अन्य .NET 4.0 असेंबली की तरह लगती है।

डेवलपर्स के लिए, विशेष रूप से घटक डेवलपर्स, यह विशेष रूप से समस्याग्रस्त है क्योंकि .NET के संस्करण को निर्धारित करने का कोई तरीका नहीं है, क्योंकि Environment.Version। रिटर्न 4।

निम्नलिखित कोड प्रदर्शित करता है

 void Main() { Environment.Version.ToString().Dump(); Environment.Version.Build.Dump(); Environment.Version.Revision.Dump(); Environment.Version.Major.Dump(); } 

.NET 4.0 पर
4.0.30319.269
30319
269
4

.NET 4.5 पर
4.0.30319.17379
30319
17,379
4

सुंदर, ऐसा लगता है, नहीं? ध्यान दें, हालाँकि, संशोधन संख्या .NET 4.5 में 17379 अधिक है, जबकि .NET 4.0 में यह 261 है। यदि आप वास्तव में जानना चाहते हैं कि आप .NET 4.5 या .NET 4.0 का उपयोग कर रहे हैं, तो आप निम्नलिखित कोड का उपयोग कर सकते हैं:

 public static bool IsDotNet45() { return Environment.Version.Major == 4 && Environment.Version.Revision > 17000; } 

दूसरा तरीका है कि प्रतिबिंब 4.5 का उपयोग करके .NET 4.5 में जोड़े गए कुछ प्रकार का पता लगाने का प्रयास किया जाए।

 public static bool IsNet45OrNewer() { //  "ReflectionContext"    .NET 4.5. return Type.GetType("System.Reflection.ReflectionContext", false) != null; } 

इस दृष्टिकोण के फायदों में से एक .NET के बाद के संस्करणों में इसका उपयोग करने की क्षमता है।

हालाँकि, यह पर्याप्त रूप से महत्वपूर्ण है कि हमें वर्जन की अनुकूलता का पता लगाने के लिए ऐसी ट्रिक का सहारा लेना होगा।

.NET 3.0 / 3.5 के साथ अंतर

ध्यान दें कि यह इन-प्लेस अपग्रेड .NET .NET 3.0 / 3.5 (भी जगह) में .NET 2.0 अपग्रेड से बहुत अलग है, जो दूसरे संस्करण CLR पर काम करता था। .NET 2.0 कर्नेल के शीर्ष पर दोनों 3.x संस्करण सिर्फ लाइब्रेरी एन्हांसमेंट थे। दोनों संस्करण .NET 2.0 चला रहे थे, जिसे पूरे 3.x चक्र में नहीं बदला गया था। बदले में, संख्या 4.5 के तहत अद्यतन वास्तविक संस्करण संख्या v4.0.30319 छोड़कर .NET 4.0 को पूरी तरह से बदल देता है।

जब आप VS 2011 में एक नया प्रोजेक्ट बनाते हैं, तब भी आप .NET 4.0 या .NET 4.5 प्लेटफॉर्म का संस्करण चुन सकते हैं। लेकिन वास्तव में, आप अपने द्वारा चुने गए संस्करण की परवाह किए बिना असेंबली के एक ही सेट का उल्लेख कर रहे हैं। अंतर यह है कि .NET 4.0 के लिए संकलन करते समय, कंपाइलर NET 4.0 में उपलब्ध सुविधाओं का केवल सबसेट प्रदान करता है, लेकिन .NET 4.5 के लिए संकलन करते समय आप सभी कार्यक्षमता का उपयोग कर सकते हैं। इसका मतलब यह नहीं है कि आप .NET 4.5 के अनुप्रयोगों को विकसित करने के लिए वीएस 2010 का उपयोग कर सकते हैं।

अच्छी खबर - बुरी खबर

Microsoft .NET के नए संस्करणों को तैनात करने के लिए हर तरह से प्रयोग करने की कोशिश कर रहा है। कोई भी दो अपडेट नहीं हैं जो समान हैं। बेशक, एक पूर्ण अपडेट (जैसे .NET 2.0, 4.0) में इसकी कमियां हैं, लेकिन इन-प्लेस अपडेट करना और .NET के वर्तमान संस्करण को निर्धारित करने का एक तरीका भी प्रदान नहीं करना पूरी तरह से सही नहीं है, यहां तक ​​कि Microsoft मानकों द्वारा भी। विशेष रूप से यह देखते हुए कि .NET 4.5 सभी async-s के साथ एक काफी बड़ा अपडेट है। IO का उपयोग करने वाले अधिकांश API को Async का समर्थन करने के लिए अद्यतन किया गया है, जिसने मौजूदा API को महत्वपूर्ण रूप से प्रभावित किया है। इससे भी बदतर, .NET 4.5 विंडोज 8 के साथ जहाज जाएगा, इसलिए यह लंबे समय तक हमारे साथ रहेगा, जब तक कि माइक्रोसॉफ्ट सिस्टम के उन्नयन के हिस्से के रूप में .NET संस्करण को अपग्रेड करने का निर्णय लेने का निर्णय नहीं लेता। यह विस्टा के साथ बिल्कुल वैसा ही था, जो .NET 3.0 के एक मध्यवर्ती संस्करण के साथ आया था, जिसे जल्दी से अधिक व्यावहारिक और लंबे समय तक .NET 3.5 द्वारा प्रतिस्थापित किया गया था। लोगों को 3.x संस्करणों के साथ भ्रमित स्थिति की समस्या थी जो वास्तव में .NET 2.0 पर काम करते थे। मैं उन प्रश्नों की संख्या भी नहीं गिन सकता, जिन्हें लोग IIS डायलॉग बॉक्स में .NET 3.5 नहीं खोज सकते। यही बात .NET 4.5 के साथ भी हो सकती है। यह अच्छा है जब हम जानते हैं कि संस्करण 4.5 में कैसे अपग्रेड किया जाए, लेकिन जो प्रशासक .NET से पूरी तरह परिचित नहीं हैं, उन्हें इन बारीकियों को समझने की संभावना नहीं है, और अंततः .NET का कौन सा संस्करण स्थापित है, यह उलझन में होगा।

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