हमारे पास एक (शुद्ध देशी सी ++) है। डीएलएल जो वीएस द्वारा निर्मित है। क्लाइंट के रूप में हमारे पास सी ++/सीएलआई में लिखे गए इस डीएलएल के आसपास कुछ देशी सी ++ एप्लिकेशन और नेट-रैपर है। अंत में सी # में लिखे गए नेट-रैपर के लिए कुछ ग्राहक अनुप्रयोग हैं।डीएलएल को स्थिर रूप से कैसे लिंक करें?
मेरी समस्या यह है कि net.dll को नेट दुनिया के काम से अलग तरीके से वितरित किया जाना चाहिए और वीएस उस डीएलएल का ट्रैक नहीं रखता है। तो मेरे सभी सी # ऐप्स सही तरीके से काम करने के लिए मुझे इसे प्रत्येक निष्पादन योग्य निर्देशिका में कॉपी करना होगा या इसे% PATH% में कहीं भी रखना होगा (जिसे मैं डेवलपर कंप्यूटर से बचना चाहूंगा क्योंकि वे डीएलएल के विभिन्न संस्करणों के साथ अलग-अलग ऐप्स शुरू करना चाहते हैं) । यदि बड़ी समस्याएं होती हैं तो उपयोगकर्ता समस्याएं हैं जो रैपर-डीएलएल का संदर्भ देती हैं: आपको डीएलएल को वीएस की निर्देशिका में कॉपी करना होगा या फिर% PATH% पर प्रतिलिपि बनाना होगा। लेकिन हमारे अनुवादक उपकरण के साथ सबसे खराब मामला होता है। यह टूल .Net-Assemblies का ट्रैक रखता है और उन्हें ट्रांसलेटर-पैकेज में पैक करता है जिसे बाहरी अनुवादक को भेजा जा सकता है। जहां तक मुझे पता है कि देशी को डालने का कोई तरीका नहीं है। डीएलएल उस पैकेज में!
इसलिए मैं मूल डीएलएल को मूल रूप से .NET-Wrapper में जोड़ने की योजना बना रहा हूं जो मेरी समस्याओं का समाधान करेगा। लेकिन हमारे मूल अनुप्रयोगों के लिए यह मूल डीएलएल अभी भी एक डीएलएल होना चाहिए।
तो मैं दो विकल्प हैं:
- की कि दो परियोजनाओं बनाएँ (एक है कि एक स्थिर पुस्तकालय उत्पन्न करता है, और एक है कि एक गतिशील एक बनाता है => मैं इस से बचने की कोशिश)
- एक समाधान का पता लगाएं DLLs से जोड़ने के लिए स्थिर
- वी.एस. एक परियोजना
मैं यहाँ एक सा Daft हो सकता है लेकिन मुझे समझ नहीं आता क्यों अपने मूल एप्लिकेशन देशी डीएलएल का उपयोग नहीं कर सकते हैं, और आपके .net ऐप्स C++/cli-wrapped dll का उपयोग करते हैं। – Niklas
वे दोनों कर सकते हैं। लेकिन रैपर-डीएलएल मूल डीएलएल का संदर्भ देता है और इसलिए मेरे सी # ऐप्स दोनों की आवश्यकता है। जो रैपर के लिए ठीक है लेकिन देशी डीएलएल के लिए गधे में दर्द है। – mmmmmmmm
क्यों न सिर्फ डीएल के लिए एक lib बनाएँ? आपने कहा कि आप वीएस का उपयोग कर डीएलएल बनाते हैं, नहीं? –