2009-05-15 18 views
5

पर क्यूटी डीएलएल परिनियोजन मेरे पास किसी अन्य कंपनी से किसी एप्लिकेशन के लिए प्लग-इन है। मेरा प्लग-इन Qt का उपयोग करता है इसलिए इसे क्यूटी डीएलएल की आवश्यकता होती है। मेरी समस्या यह है कि 4.x क्यूटी डीएलएस के सभी संस्करणों को वही कहा जाता है, उदा। : QtCore4.dll। यह काफी संभव है कि कुछ अन्य प्लगइन, या एक अन्य अनुप्रयोग जो खुद को पाथ पर्यावरण चर में डाला गया है, ने अनुप्रयोग फ़ोल्डर में क्यूटी डीएलएस डाल दिया है। उस स्थिति में, प्लग-इन शुरू नहीं होगा क्योंकि यह डीएलएल के एक अलग संस्करण की अपेक्षा कर रहा है।विंडोज

  • प्रश्न 1। डीएलएल तैनाती के लिए सुझाए गए सामान्य अभ्यास क्या है?
  • प्रश्न 2। क्या होगा यदि होस्ट एप्लिकेशन क्यूटी के एक अलग संस्करण का उपयोग करता है। क्या विंडोज़ मेजबान एप्लिकेशन और प्लग-इन को विभिन्न संस्करणों() का उपयोग करने की अनुमति देगा?

धन्यवाद!

उत्तर

0

क्या क्यूटी के साथ स्थैतिक रूप से लिंक करने का कोई तरीका नहीं है?

मैं डीएलएल को उसी ऐप/प्लगइन के रूप में उसी निर्देशिका में तैनात करता हूं।

हालांकि यह आपकी अन्य चिंताओं का उत्तर नहीं देता है।

+0

जहाँ तक मुझे पता है, सांख्यिकीय रूप से लिंकिंग केवल वाणिज्यिक क्यूटी लाइसेंस के लिए ही अनुमति है। एलजीपीएल लाइसेंस के लिए आवश्यक है कि आप अपने ग्राहकों को क्यूटी के नए संस्करण के साथ अपने एप्लिकेशन को 'रिलिकिंक' करने दें, जिसका अर्थ है: या तो अपने एप्लिकेशन के स्रोत या ऑब्जेक्ट फ़ाइलों को दूर करें। या क्यूटी को डीएलएल के रूप में वितरित करें। – Patrick

0

जैसे टिम ने कहा कि आपको उसी निर्देशिका में डीएलएल को तैनात करना चाहिए जैसा आप बना रहे हैं। मेरा मानना ​​है कि पैथ वैरिएबल पहला स्थान नहीं है जहां आपका प्रोग्राम क्यूटी 4 डीएल की तलाश करेगा, इसलिए यदि आप इसे उसी फ़ोल्डर में तैनात करते हैं तो आपका ऐप आपके ऐप के साथ एक उठाएगा और पथ पर मौजूद किसी भी को अनदेखा करेगा।

प्रश्न 1: अतीत में ऐसा लगता था कि हर किसी ने सिस्टम डीएलएल को सिस्टम 32 फ़ोल्डर में फेंक दिया क्योंकि उन्हें पता था कि यह पथ पर था और पता था कि प्रोग्राम इसे ढूंढ पाएगा। किसी उपयोगकर्ता के दृष्टिकोण से मुझे लगता है कि जब मैं कुछ अनइंस्टॉल करना चाहता हूं तो उसे साफ़ करना बहुत कठिन लगता है। और अब स्टोरेज की छोटी कीमत के साथ मैं कहूंगा कि अपने डीएलएल को अपने ऐप से रखें, खासकर अगर वे इस तरह हैं जहां कई संस्करण हो सकते हैं। जबकि मैं कोई विशेषज्ञ नहीं हूं, इस तरह मैं जावा अनुप्रयोगों के लिए जार फ़ाइलों को कैसे संभालता हूं।

प्रश्न 2: मुझे ऐसा लगता है। यह ऐप और प्लगइन की निर्देशिका संरचना पर निर्भर करेगा। आप अपनी प्लगइन को बता सकते हैं कि किस संस्करण का उपयोग करना है और मैं यह शर्त लगाने के लिए तैयार हूं कि ऐप का संस्करण पहले से ही एक विशेष स्थान पर भी है।

1

XP (यानी XP, 2003, Vista, 2008, और Win7) के बाद से विंडोज के संस्करणों के साथ, आप side-by-side assemblies या DLL redirection का उपयोग कर सकते हैं। किसी भी मामले में, अनिवार्य रूप से आप जो कर रहे हैं वह एक छोटी पाठ फ़ाइल शामिल है जो ऑपरेटिंग सिस्टम को बताती है कि आपको डीएलएल के विशिष्ट संस्करण का उपयोग करने की आवश्यकता है जिसे आपने निष्पादन योग्य के रूप में उसी निर्देशिका में शामिल किया है।

ये कम ज्ञात विशेषताएं हैं, लेकिन वे वास्तव में आपके बट को "डीएलएल नरक" से बचा सकते हैं।

+0

साइड-बाय-साइड कैश एक बड़े नेटवर्क में एप्लिकेशन को तैनात करना अधिक कठिन बनाता है। मैं सरल, शून्य-इंस्टॉल, xcopy-install अनुप्रयोगों को प्राथमिकता देता हूं जहां आपको केवल exe और कुछ DLL की प्रतिलिपि बनाना है, या आपको इसे कॉपी करने की भी आवश्यकता नहीं है, लेकिन इसे केवल नेटवर्क ड्राइव पर छोड़ दें। साइड-बाय-साइड-कैश-डीएलएल के साथ आपको प्रत्येक पीसी पर एप्लिकेशन को स्पष्ट रूप से इंस्टॉल करने के लिए मजबूर होना पड़ता है। और यदि अगले संस्करण को नए डीएलएल की आवश्यकता है, तो आपको एप्लिकेशन को फिर से इंस्टॉल करना होगा। – Patrick

3

ए 1: सर्वश्रेष्ठ अभ्यास: डीएलएल को निष्पादन योग्य की निर्देशिका में डालें। यह डीएलएल लोड करने के लिए पहले वहां देखेंगे। यह सामान्य अभ्यास है।

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

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

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

3

बस इस समस्या के साथ अन्य लोगों की सहायता करने के लिए: क्यूटी डीएलएल की सभी 4.X संस्करणों के लिए समान (या कम से कम बाइनरी संगत) होने की गारंटी है। (सभी 3.X संस्करणों के लिए और इसी तरह) तो कोई समस्या नहीं होगी। यह भी कारण है कि क्यूटी डीएल नामकरण में कोई दूसरा नंबर नहीं है।

+3

हालांकि, यदि दो अलग-अलग क्यूटी निर्माण के लिए कॉन्फ़िगरेशन अलग हैं, तो वे बाइनरी संगत नहीं हैं। – swongu

+0

और क्यूटी डीएलएल के 32-बिट और 64-बिट संस्करण के बारे में क्या? फिर वे बाइनरी संगत नहीं हैं। – Patrick

0

सुरक्षा के लिए आपको यह सुनिश्चित करना होगा कि आपका एप्लिकेशन उन डीएलएल संस्करणों का उपयोग करता है जिन्हें आप उपयोग करना चाहते हैं। विंडोज़ को पहले एप्लिकेशन फ़ोल्डर में देखने की गारंटी है। तो वहां आपको अपनी सभी बाइनरी निर्भरताओं को रखना चाहिए।

यदि आपका ऐप नहीं चलता है जब आप दोगुना एक्सप्लोरर Windows में उस पर क्लिक करें आपको बता देंगे क्या DLL यह की जरूरत है। उस फ़ोल्डर को उस फ़ोल्डर में कॉपी करें। यदि आपका एप्लिकेशन चलता है तो अगले चरण पर जाएं।

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

केवल तभी यदि आप सुनिश्चित हैं कि आपका एप्लिकेशन एप्लिकेशन डीआईआर में डीएलएल का उपयोग करता है और कहीं और से किसी भी डीएल में नहीं खींचता है तो आप पुरानी स्थिति को पुनर्स्थापित करने के लिए फिर से पैथ वैरिएबल को संपादित करना शुरू कर सकते हैं।