चूंकि डीएलएल स्मृति में लोड हो जाते हैं, क्या कोई कारण है कि संदर्भ डीएलएस को चल रहे प्रक्रिया से लॉक करना होगा? डीएलएस को एक अस्थायी फ़ोल्डर में कॉपी करने और वहां से लोड करने के अलावा लॉकिंग के आसपास कोई रास्ता है?.NET फ्रेमवर्क लॉक डीएलएस क्यों करता है?
यह सीएलआर का एक दुष्प्रभाव है जो इसे असेंबली के मेमोरी मैप किए गए दृश्य को मेमोरी में मैप करने के लिए बनाता है। मेमोरी मैप की गई फाइलें विंडोज़ में निम्न-स्तरीय फीचर हैं, जो मेमोरीमैप्डफाइल क्लास के साथ .NET 4.0 में भी उजागर हुई हैं। अन्यथा विंडोज़ जैसे मांग-पजे हुए वर्चुअल मेमोरी ऑपरेटिंग सिस्टम में एक आम सुविधा।
एमएमएफ में बहुत वांछनीय गुण हैं। एक असेंबली "लोडिंग" का कार्य बहुत सरल और बहुत तेज़ हो जाता है। वास्तव में फ़ाइल से कुछ भी नहीं पढ़ा जाता है, यह आलसी फैशन में होता है। फ़ाइल में प्रत्येक बाइट में एक संबंधित स्मृति पता है। जब सीएलआर पहली बार असेंबली मेटाडेटा या आईएल में एक बाइट पढ़ने की कोशिश करता है, तो प्रोसेसर पेज गलती की यात्रा करता है क्योंकि पेज रैम में उपलब्ध नहीं है। ऑपरेटिंग सिस्टम डिस्क से फ़ाइल सामग्री को गतिशील रूप से पढ़कर इसे संभालता है। सीएलआर जारी है जैसे कि कुछ नहीं होता है, यह पूरी तरह से अनजान है कि क्या हुआ।
इस प्रकार की आलसी पहुंच बहुत बढ़िया है, आप जो भी उपयोग नहीं करते हैं उसके लिए आप भुगतान नहीं करते हैं। इसलिए यदि आपको एक ही प्रकार से एक विधि की आवश्यकता है, तो कहें, माइक्रोसॉफ्ट.विज़ुअलबासिक डीएल जैसी बड़ी असेंबली तो आप केवल उस विधि के लिए भुगतान करते हैं। आपका प्रोग्राम वास्तव में अन्य तरीकों या अन्य तरीकों के आईएल के मेटाडेटा को कभी नहीं पढ़ता है।
और भी कुछ है। आप या तो स्मृति करने के लिए भुगतान नहीं करते हैं। यदि मशीन पर किसी अन्य प्रक्रिया को रैम की आवश्यकता होती है तो असेंबली डेटा वाले पृष्ठों को आसानी से त्याग दिया जा सकता है। चूंकि उन्हें फ़ाइल से पुनः लोड किया जा सकता है। उन्हें पेजिंग फ़ाइल द्वारा समर्थित नहीं होना चाहिए, सस्ता वर्चुअल मेमोरी जिसे आप खरीद सकते हैं।
और भी कुछ है। तथ्य यह है कि असेंबली डेटा को किसी भी समय फ़ाइल से पुनः लोड करने योग्य होने की आवश्यकता होती है, इसका मतलब यह भी है कि किसी भी व्यक्ति को फ़ाइल को संशोधित करने की अनुमति देने के लिए यह कभी भी सही नहीं हो सकता है। चूंकि इससे रैम में डेटा फ़ाइल में डेटा को मेल नहीं कर पाएगा। और इसके लिए सीएलआर के दृष्टिकोण से यादृच्छिक रूप से बदलना है क्योंकि यह पेज दोषों का पालन नहीं कर सकता है। तो एक एमएमएफ फाइल पर एक हार्ड लॉक डालता है, कोई भी इसके साथ गड़बड़ नहीं कर सकता है। यह एक मुफ्त एंटी-मैलवेयर सुविधा है।
और भी कुछ है। लॉक गारंटी का यह भी अर्थ है कि सीएलआर को कभी भी लिखित कोड से निपटना नहीं पड़ता है, जो अब विधानसभा में आईएल से मेल नहीं खाता है। ऐसा कुछ जो लागू करने के लिए असाधारण रूप से कठिन होगा क्योंकि असेंबली में यादृच्छिक परिवर्तन कोड निष्पादन के साथ ठीक से सिंक्रनाइज़ करने के लिए असंभव के बगल में हैं। और यह बहुत महंगा होगा, विधि कॉल अब आसान कॉल निर्देश नहीं हो सका। और यह कोड तक सीमित नहीं है, एक प्रतिनिधि वस्तु की लक्ष्य विधि को गतिशील रूप से हल किया जाना चाहिए। बहुत प्रमुख perf हत्यारों। अन्यथा हल की गई समस्या, यही कारण है कि सीएलआर एक ऐपडोमेन की धारणा का समर्थन करता है। एक एपडोमेन को उतारने से सब कुछ, कोड और डेटा नष्ट हो जाता है। छाया-प्रतिलिपि असेंबली के पीछे अंतर्निहित तकनीक, जैसे कि एएसपी.नेट
आहा मेमोरी मैप की गई फ़ाइल। यह समझ आता है। सारी जानकारी के लिए शुक्रिया! –
संभवतः क्योंकि आप आम तौर पर उस कोड को नहीं चाहते हैं जो आप नीचे से निकल रहे हैं (विशेष रूप से क्योंकि यह नहीं हुआ है जेआईटी अभी तक संकलित)। – BradleyDotNET
विंडोज़ और विंडोज़ अनुप्रयोगों में उनके द्वारा उपयोग की जाने वाली फ़ाइलों को लॉक करने या उस पर निर्भर करने की एक मजबूत प्रवृत्ति है। – zneak
यदि आप अपनी समस्या पोस्ट करते हैं, तो आप एक कामकाज प्राप्त कर सकते हैं। – Ehsan