.NET में, क्या DLL को पंजीकृत करने की आवश्यकता है?

Question

क्या एक लक्षित मशीन पर एक संकलित DLL (सी # .NET में लिखा गया) पंजीकृत करना आवश्यक है।

लक्ष्य मशीन में .NET इंस्टॉल होगा, क्या यह डीएलएल को लक्ष्य मशीन पर छोड़ने के लिए पर्याप्त है?

Answer 1

मुझे लगता है कि आप चीजों को थोड़ा उलझन में डाल रहे हैं। इसका उपयोग करने के लिए किसी डीएल को पंजीकृत करने की आवश्यकता नहीं है।

एक डीएलएल का उपयोग केवल इसे लोड करने के लिए आवश्यक है (ज्ञात स्थान दिया गया है या यदि पुस्तकालय सिस्टम पथ में है) और उस फ़ंक्शन का पता प्राप्त करें जिसे आप उपयोग करना चाहते हैं।

डीएल को पंजीकृत करना COM या ActiveX ऑब्जेक्ट्स वितरित करते समय उपयोग किया जाता था, जिन्हें Windows रजिस्ट्री में कुछ प्रविष्टियां जोड़ने की आवश्यकता होती है। एक COM सेवा का उपयोग करने के लिए (उदाहरण के लिए) आपको एक GUID — संदर्भित करने की आवश्यकता है, जो एक अद्वितीय पहचानकर्ता — है जो आपको सेवा लागू करने वाले डीएल को संभालने की अनुमति देता है (या इसे एक्सेस प्रदान करता है)। कभी-कभी आप पूरी तरह से योग्य नाम का संदर्भ ले सकते हैं और एक ही परिणाम प्राप्त कर सकते हैं।

पंजीकृत होने के लिए आवश्यक डीएलएल को काम करने के लिए सभी के लिए। यह "पंजीकरण" प्रक्रिया केवल रजिस्ट्री में कई प्रविष्टियां बनाती है, लेकिन मुख्य रूप से ये दो: एक डीएलआई के स्थान के साथ एक GUID को जोड़ती है (ताकि आप यह जानने के बिना GUID के माध्यम से संदर्भित कर सकें कि यह वास्तव में कहां स्थित है) और दूसरा GUID के साथ पूरा नाम जोड़ना। लेकिन फिर, यह सिर्फ COM या ActiveX ऑब्जेक्ट्स के लिए है।

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

• पहला स्थान एप्लिकेशन पथ है।
• दूसरा स्थान जीएसी है।

जीएसी (ग्लोबल असेंबली कैश) आपको पूरे सिस्टम में प्रभावी रूप से उपयोग करने के लिए एक डीएल पंजीकृत करने की अनुमति देता है और पुराने पंजीकरण तंत्र के विकास के रूप में काम करता है।

तो मूल रूप से आपको केवल एप्लिकेशन के उसी फ़ोल्डर में डीएल डालना होगा।

Answer 2

आमतौर पर लक्ष्य मशीन पर आपके ऐप के फ़ोल्डर में डीएल ड्रॉप करने के लिए पर्याप्त होता है।

यदि डीएलएल अन्य अनुप्रयोगों के लिए उपलब्ध होना चाहिए तो आप GAC पर विचार करना चाहेंगे।

Answer 3

आपको इसे उस निर्देशिका में "ड्रॉप" करने की आवश्यकता है जहां इसे आवश्यक एप्लिकेशन को मिलेगा।

यदि कई एप्लिकेशन हैं, या आप फ़ाइल निर्देशिका के अलावा कहीं भी "ड्रॉप" करना चाहते हैं, तो आपको आम तौर पर या तो पीएटीएच चर समायोजित करने की आवश्यकता होती है, या ग्लोबल असेंबली कैश (जीएसी) में असेंबली पंजीकृत करने की आवश्यकता होती है।

Answer 4

एक एप्लिकेशन एप्लिकेशन के साथ एक ही फ़ोल्डर में मौजूद होने के द्वारा एक .NET डीएलएल का उपयोग कर सकता है।

हालांकि यदि आप अन्य तृतीय-पक्ष अनुप्रयोगों को डीएलएल ढूंढना चाहते हैं और इसका उपयोग करना चाहते हैं तो उन्हें इसे अपने वितरण में भी शामिल करना होगा। यह वांछनीय नहीं हो सकता है।

एक विकल्प यह है कि डीएलएल जीएसी (ग्लोबल असेंबली कैश) में पंजीकृत है।

Answer 5

यदि आप access the assembly via com+ करना चाहते हैं। एक उदाहरण एक .NET असेंबली से .NET असेंबली में परिभाषित प्रकार का उपयोग करेगा, जैसे वीबी 6 विनफॉर्म ऐप।

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

Answer 6

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

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

मैवेन जैसे बिल्ड रिपोजिटरी सिस्टम के साथ मॉड्यूल के संस्करणों को प्रबंधित करना एक बात है। मेवेन बहुत अच्छा काम करता है जो करता है।

हालांकि, यह एक पूरी तरह से अलग बात है, हालांकि, उस समस्या से निपटने के लिए अंत उपयोगकर्ता रनटाइम पर्यावरण में लाखों उपयोगकर्ताओं की आबादी में फैल गया।

.NET GAC इस उम्र के पुराने विंडोज़ समस्या का पर्याप्त समाधान नहीं है।

निजी रूप से खपत डीएलएल असेंबली असीम रूप से बेहतर हो रही है। यह जाने का कोई मस्तिष्क तरीका नहीं है क्योंकि डिस्कस्पेस इन दिनों बेहद सस्ती है (~ $ 100 इन दिनों फ्राई में टेराबाइट ड्राइव द्वारा कर सकते हैं)। अन्य उत्पादों के साथ असेंबली साझा करने के साथ कुछ भी हासिल नहीं किया जा सकता है - और फिर भी जब गरीब उपयोगकर्ता के लिए चीजें दक्षिण में जाती हैं तो कंपनी की प्रतिष्ठा ढीली होती है।

Answer 7

वास्तव में लक्ष्य मशीन पर .NET में एक डीएल पंजीकृत करने की आवश्यकता नहीं है।

यदि आप अपने आवेदन में .dll का संदर्भ देते हैं, तो संदर्भ में .dll पर क्लिक करें, अपनी प्रोजेक्ट में संदर्भों के तहत, गुणों को देखें और TRUE को अलग सेट करें।

अब यह आपके प्रोजेक्ट में स्वचालित रूप से इस .dll को शामिल करेगा और आपका एप्लिकेशन लक्ष्य परियोजना पर पंजीकरण करने की आवश्यकता के बिना आपके प्रोजेक्ट में शामिल .dll की प्रति का उपयोग करेगा।

इस की एक काम उदाहरण यहां देखने के लिए देखने के लिए:

http://code.msdn.microsoft.com/SEHE

प्रश्न में .dll प्रणाली इस ठीक से काम करने के लिए जहां आप अपने आवेदन का निर्माण पर पंजीकृत करने की आवश्यकता होगी। हालांकि, जब आप अपनी परियोजना का निर्माण कर लेंगे, तो आपके आवेदन या कार्यक्रम को तैनात करने वाले किसी भी सिस्टम पर प्रश्न में डीएलएल को पंजीकृत करने की आवश्यकता नहीं होगी।

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

उपरोक्त उदाहरण उन मामलों में से एक है, Skype4COM के कई संस्करण हैं जो एक स्काइप एपीआई है। डीएल और अक्सर बदल सकते हैं।

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

इसके अलावा, कुछ स्काइप क्लाइंट हैं जो इस .dll को स्थापित नहीं करते हैं, उदाहरण के लिए स्काइप क्लाइंट का व्यावसायिक संस्करण छोटा है, और इसमें यह शामिल नहीं है। डीएल, इसलिए इस मामले में, परियोजना विफल नहीं होती है उस पर .dll गायब है और पंजीकृत नहीं है क्योंकि इसे परियोजना में अलग = सत्य के रूप में शामिल किया गया है।