%windir%\Microsoft.NET\assembly\ नया GAC है। क्या इसका मतलब यह है कि अब हमें दो जीएसी का प्रबंधन करना है, एक .NET 2.0-3.5 अनुप्रयोगों के लिए और दूसरा .NET 4.0 अनुप्रयोगों के लिए?.NET 4.0 में एक नया जीएसी है, क्यों?
सवाल यह है, क्यों?
हां 2 अलग ग्लोबल असेंबली कैश (जीएसी) हैं, इसलिए आपको उनमें से प्रत्येक को अलग-अलग प्रबंधित करना होगा।
.NET Framework 4.0 में, जीएसी कुछ बदलावों के माध्यम से चला गया। प्रत्येक सीएलआर के लिए जीएसी दो में विभाजित किया गया था।
सीएलआर संस्करण दोनों .NET Framework 2.0 और .NET Framework 3.5 दोनों के लिए उपयोग किया गया है CLR 2.0 है। जीएसी को विभाजित करने के लिए पिछले दो फ्रेमवर्क रिलीज में कोई आवश्यकता नहीं थी। नेट फ्रेमवर्क 4.0 में पुराने अनुप्रयोगों को तोड़ने की समस्या।
CLR 2.0 और CLR 4.0 के बीच मुद्दों से बचने के लिए, GAC अब प्रत्येक runtime.The मुख्य परिवर्तन के लिए निजी GAC के में विभाजित है कि CLR v2.0 अनुप्रयोगों अब GAC में CLR v4.0 विधानसभाओं नहीं देख सकता है।
क्यों?
यह क्योंकि वहाँ .NET 4.0 में एक CLR परिवर्तन था, लेकिन 3.5 करने के लिए 2.0 में नहीं हो रहा है। 1.1 से 2.0 सीएलआर के साथ भी यही बात हुई। ऐसा लगता है कि जीएसी में असेंबली के विभिन्न संस्करणों को स्टोर करने की क्षमता है जब तक वे एक ही सीएलआर से हैं। वे पुराने अनुप्रयोगों को तोड़ना नहीं चाहते हैं।
MSDN about the GAC changes in 4.0 में निम्न जानकारी देखें।
उदाहरण के लिए, अगर दोनों .NET 1.1 और .NET 2.0, एक ही GAC, तो एक .NET 1.1 आवेदन साझा एक विधानसभा से लोड करने से इस साझा GAC, .NET 2.0 विधानसभाओं मिल सकता है, जिससे नेट तोड़ने 1.1 आवेदन
सीएलआर संस्करण .NET फ्रेमवर्क 2.0 और .NET Framework 3.5 दोनों के लिए उपयोग किया गया है CLR 2.0 है। इसके परिणामस्वरूप, को जीएसी को विभाजित करने के लिए पिछले दो फ्रेमवर्क रिलीज़ में कोई आवश्यकता नहीं थी। पर पुराने (इस मामले में, .NET 2.0) अनुप्रयोगों नेट फ्रेमवर्क 4.0 में resurfaces तोड़ने की समस्या जो बिंदु CLR 4.0 का विमोचन किया। इसलिए, सीएलआर 2.0 और सीएलआर 4.0 के बीच हस्तक्षेप के मुद्दों से बचने के लिए, जीएसी अब प्रत्येक रनटाइम के लिए निजी जीएसी में विभाजित है।
चूंकि सीएलआर भविष्य के संस्करणों में अपडेट किया गया है, तो आप एक ही चीज़ की उम्मीद कर सकते हैं। यदि केवल भाषा बदलती है तो आप एक ही जीएसी का उपयोग कर सकते हैं।
वह ब्लॉग पोस्ट केवल ओपी की खोज को पुनर्स्थापित करता है, यह समझा नहीं जाता है कि क्यों * जीएसी को विभाजित करने की आवश्यकता है। यह स्पष्ट नहीं है, मूल जीएसी 4.0 विधानसभाओं को अलग रखने में काफी सक्षम था।उनके पास एक नया [असेंबली वर्जन] –
@ हंस: शायद सटीक कारण नहीं है लेकिन यह कहता है: "सीएलआर 2.0 और सीएलआर 4.0 के बीच मुद्दों से बचने के लिए, इस सवाल के अंदर 2 प्रश्न भी थे। दूसरा सवाल यह है: "क्या इसका मतलब यह है कि अब हमें दो जीएसी का प्रबंधन करना है, एक .NET 2.0-3.5 ऐप्स के लिए और दूसरा .NET 4.0 ऐप्स के लिए?" –
आपको इसे अपने लिंक में से एक से उद्धृत करना चाहिए: "उदाहरण के लिए, यदि .NET 1.1 और .NET 2.0 दोनों ने एक ही जीएसी साझा किया है, तो .NET 1.1 एप्लिकेशन, इस साझा जीएसी से एक असेंबली लोड करना, .NET 2.0 प्राप्त कर सकता है असेंबली, इस प्रकार .NET 1.1 एप्लिकेशन तोड़ना। " –
यह बहुत समझ में नहीं आता है, मूल जीएसी असेंबली के विभिन्न संस्करणों को संग्रहित करने में काफी सक्षम था। और यह मानने का कोई कारण नहीं है कि एक प्रोग्राम कभी गलती से गलत असेंबली का संदर्भ देगा, सभी .NET 4 असेंबली को [असेंबलीवर्सन] 4.0.0.0 तक पहुंच गया। नई इन-प्रोसेस साइड-बाय-साइड सुविधा को यह नहीं बदला जाना चाहिए।
मेरा अनुमान है: वहां पहले से ही बहुत सी .NET परियोजनाएं थीं जो "सीधे जीएसी में कुछ भी संदर्भ नहीं देती" नियम तोड़ती थीं।मैंने इसे कई बार इस साइट पर देखा है।
उन परियोजनाओं को तोड़ने से बचने के लिए केवल एक ही रास्ता: जीएसी को स्थानांतरित करें। बैक-कंपैट माइक्रोसॉफ्ट में पवित्र है।
यह एकमात्र उत्तर है जो व्याख्या करने की कोशिश करता है * क्यों * यह मामला है। +1 –
@ हंस पासेंट: "जीएसी में सीधे कुछ भी संदर्भ न दें" नियम का क्या मतलब है? –
@ मैक्स: आपकी मशीन पर .NET असेंबली की दो प्रतियां हैं। वे c: \ windows \ microsoft.net और c: \ प्रोग्राम फ़ाइलों \ संदर्भ असेंबली में संदर्भ असेंबली होने का मतलब था। और रनटाइम पर इस्तेमाल किए गए, जीएसी @ सी: \ विंडोज \ असेंबली। वे समान नहीं हैं, 64-बिट एक उदाहरण होगा। माइक्रोसॉफ्ट ने शैल एक्सटेंशन हैंडलर के साथ जीएसी को संदर्भित करने वाले किसी से भी बचने के लिए अपनी पूरी कोशिश की। और संदर्भ संदर्भ संवाद। नहीं 100% प्रभावी –
मैं भी जानना चाहता है कि 2 GAC चाहता था और में निम्नलिखित explanation by Mark Miller पाया comments section.NET 4.0 has 2 Global Assembly Cache (GAC) की:
मार्क मिलर ने कहा ... जून 28, 2010 12:13
पोस्ट के लिए धन्यवाद। "हस्तक्षेप के मुद्दे" जानबूझकर अस्पष्ट थे। लेखन के समय, समस्याएं अभी भी की जांच की जा रही थीं, लेकिन यह स्पष्ट था कि कई टूटे हुए परिदृश्य थे।
उदाहरण के लिए, कुछ अनुप्रयोग Assemby.LoadWithPartialName को असेंबली का उच्चतम संस्करण लोड करने के लिए उपयोग करते हैं। यदि उच्चतम संस्करण, एक v2 (3.0 या 3.5) अनुप्रयोग सकता यह लोड नहीं है, और अनुप्रयोग क्रैश हो सकता v4 वाले संकलित किया गया तो, भले ही एक संस्करण है कि काम किया है होगा। मूल रूप से, हम GAC विभाजित के तहत यह मूल स्थान है, लेकिन वह वजह से खिड़कियों के साथ कुछ समस्या परिदृश्यों का उन्नयन। इन शामिल कोड कि पहले से ही भेज दिया था दोनों है, तो हम चले गए हमारे (संस्करण-विभाजित एक अन्य जगह पर GAC।
यह सबसे आवेदन करने के लिए किसी भी प्रभाव नहीं होना चाहिए, और किसी भी रखरखाव नहीं जोड़ता है बोझ। दोनों स्थानों, जो विभाजन के रूप में उम्मीद के साथ सौदा तभी पहुँचा या देशी GAC API का उपयोग करके संशोधित किया जाना चाहिए। स्थानों पर जहां इस सतह करता एपीआई है कि इस तरह के रूप में GetCachePath GAC के रास्तों का पर्दाफाश के माध्यम से कर रहे हैं, या mscorlib लोड किए गए पथ की जांचप्रबंधित कोड में।
जब हम साथ ही जब हम विधानसभा पहचान का भाग के रूप में वास्तुकला की शुरुआत की v2 जारी किया गया यह ध्यान देने योग्य है कि हम GAC स्थानों संशोधित लायक है। उन ने GAC_MSIL, GAC_32, और GAC_64, जोड़ा हालांकि सभी अभी भी % windir% \ assembly के अंतर्गत हैं। दुर्भाग्य से, इस रिलीज के लिए एक विकल्प नहीं था।
आशा है कि यह भविष्य पाठकों मदद करता है। question..i पूछने के लिए
लिंक किए गए आलेख पर मिलर की टिप्पणियां विषय के अंदर एक अंदरूनी दृश्य प्रदान करती हैं। –
धन्यवाद भी बहुत उलझन में जब मैं उसके मूल स्थान :) – Jasl
अच्छा प्रश्न ... बहुत धन्यवाद में गाक नहीं मिला हूं। आपके प्रश्न के लिए – smwikipedia
+1। मैंने नेट 4.0 के तहत विकास शुरू किया और "दोहरी" जीएसी मुद्दे से उलझन में था। –