2010-06-14 13 views
7

मुझे कोई समस्या है, मैं कल से इसे हल करने की कोशिश करता हूं लेकिन कोई भाग्य नहीं। मेरे पास 32 बिट डेल्फी डीएल है जिसे मैं .NET Win अनुप्रयोग में आयात करना चाहता हूं। यह एप्लिकेशन किसी भी CPU मोड पर बनाया जाना है। बेशक, BadImageFormatException आ रहा है, जिसका मतलब है कि x64 एप्लिकेशन में x86 dll लोड नहीं किया जा सकता है .. मैं चारों ओर गुगलता हूं और समाधान ढूंढता हूं, उसने कहा कि मुझे रैपर करना है, लेकिन यह मेरे लिए स्पष्ट नहीं था। क्या कोई इस समस्या को हल करने के बारे में बता सकता है, क्या कोई भी संभावित तरीका है जिसे मैं बनाया गया प्रोग्राम में 32 बिट डेल्फी डीएल आयात कर सकता हूं कोई भी CPU या x64 मोड (शायद एक और समाधान)।32 बिट डीएल 64 बिट में आयात करना। नेट एप्लिकेशन

+2

क्यों .NET अनुप्रयोग को x86 के रूप में संकलित नहीं करें? – OregonGhost

+2

इसे किसी भी CPU के रूप में क्यों संकलित किया जाना चाहिए? 32-बिट ऐप 64-बिट ओएस पर चलाएगा। – juharr

+1

@ ओरेगॉनहोस्ट क्योंकि यह 21 वीं शताब्दी है। – sproketboy

उत्तर

5

एक सामान्य विचार आपके (अप्रबंधित) 32-बिट डीएलएल को एक प्रबंधित 32-बिट रैपर डीएल के साथ लपेटने और इसे COM दृश्यमान बनाने के लिए हो सकता है। यह आपके सीएफ इंटरफ़ेस के माध्यम से आपके रैपर डीएलएल को कॉल करने की अनुमति देता है।

आप COM COM को प्रक्रिया COM सर्वर के बाहर के रूप में प्रकट करने के लिए COM सरोगेट का उपयोग करने से अधिक कर सकते हैं। इस विषय पर कुछ और जानकारी के लिए इस SO प्रश्न पर एक नज़र डालें: Access x86 COM from x64 .NET

2

जैसा कि मैं चीजों को समझता हूं, आपके पास 64-बिट अनुप्रयोग से 32-बिट डीएलएल का उपयोग करने का कोई तरीका नहीं है। उस ने कहा, आप केवल अपने आवेदन को X86 के लिए संकलित कर सकते हैं।

आपके द्वारा प्राप्त समाधान एक डीएलएल का उपयोग करने के बारे में हो सकता है जो "किसी भी CPU" -compiled प्रोजेक्ट में 32- और 64-बिट संस्करणों के लिए मौजूद है, इस पर निर्भर करता है कि एप्लिकेशन 32- या 64- थोड़ा पर्यावरण

ऐसा करने के लिए, आप सी # में दो रैपर डीएलएल, 64-बिट के लिए एक और 32-बिट के लिए एक लिख सकते हैं और 64-बिट या 32-बिट ओएस पर चल रहे हैं या नहीं, इसके आधार पर संबंधित रैपर का उपयोग कर सकते हैं ।

हालांकि, यह तब काम नहीं करता जब आपके पास 32-बिट डीएलएल है। एक 64-बिट अनुप्रयोग 32-बिट DLL का उपयोग नहीं कर सकता है, साथ ही 32-बिट एप्लिकेशन 64-बिट DLL का उपयोग नहीं कर सकता है।

तो आपको या तो 32-बिट के लिए अपना एप्लिकेशन संकलित करने की आवश्यकता है, या आपको अपने डीएलएल का 64-बिट संस्करण बनाना होगा।

+0

इस समय, मेरे पास केवल डीएलएल (32 बिट एक) पर है और एक और डीएलएल - 64 बिट संस्करण होने का कोई मौका नहीं है, इस बीच मेरा .NET एप्लिकेशन किसी भी CPU (जिसे 64 बिट भी माना जाता है) के रूप में संकलित किया जाना है। तो, इस मामले के लिए कोई समाधान नहीं है? – scatterbraiin

+0

ठीक है, जैसा कि लास वी। कार्ल्सन ने सुझाव दिया है, आप एक अलग 32-बिट एप्लिकेशन (पुस्तकालय नहीं!) लिख सकते हैं जिसे आप एक अलग प्रक्रिया के रूप में शुरू करते हैं और इंटर प्रोसेस संचार का उपयोग करके "बात करते हैं"। –

1

एक समाधान हालांकि थोड़ा गड़बड़ एक अलग 32-बिट अनुप्रयोग लिखना हो सकता है जिसे आप अपने 64-बिट एप्लिकेशन से बात कर सकते हैं जैसे कंसोल एप्लिकेशन जिसे आप आदेश भेजते हैं।

सुंदर नहीं है लेकिन अगर आपको केवल कभी-कभार कॉल की आवश्यकता हो तो काम कर सकता है।

+0

मैंने कोशिश की, बिल्कुल ठीक नहीं, मैंने कक्षा पुस्तकालय लिखा, जहां मैंने डेल्फी डीएलएल आयात किया, x86 संकलित किया और फिर मैंने इसे अपने 64 बिट मुख्य अनुप्रयोग में संदर्भित किया, लेकिन अभी भी कोई भाग्य नहीं है। – scatterbraiin

+0

क्योंकि यह एक ही समस्या है, केवल अधिक जटिलता के साथ। आपका 64-बिट एप्लिकेशन 32-बिट क्लास लाइब्रेरी का उपयोग नहीं कर सकता है! माइकल 32-बिट एप्लिकेशन के बारे में बात कर रहा था जिसे आप नामांकित पाइप्स या अन्य आईपीसी विधियों के माध्यम से संवाद करते हैं। –

+0

मैंने पढ़ा है कि आईपीसी के माध्यम से यह संभव है लेकिन आपको सच कहने के लिए यह मेरे लिए बिल्कुल स्पष्ट नहीं था .. क्या आपके पास इसके बारे में कुछ निर्देश हैं ?? मुझे अधिक जानकारी चाहिए, क्योंकि यह मेरे लिए वास्तव में नया है – scatterbraiin

14

आपको क्या करना है एक 32-बिट प्रक्रिया में 32-बिट DLL फ़ाइल होस्ट करने वाला एक रैपर एप्लिकेशन लिखना है।

आपके 64-बिट एप्लिकेशन को नेटवर्क प्रक्रियाओं के माध्यम से, या डीएलएल कार्यों को COM ऑब्जेक्ट, या इसी तरह के माध्यम से उपलब्ध कराकर, इस 32-बिट प्रक्रिया से बात करनी है।

आप 64-बिट प्रक्रिया के अंदर 32-बिट डीएलएल चला सकते हैं, इससे कोई फर्क नहीं पड़ता कि आप कितनी मेहनत करते हैं, इसलिए आपको इसे 32-बिट प्रक्रिया में चलाने की आवश्यकता है।

यदि 32-बिट के लिए आपके आवेदन को संकलित करना केवल एक विकल्प नहीं है, तो आपके पास होस्ट एप्लिकेशन बनाने के अलावा कोई विकल्प नहीं है।

+0

क्या आप मुझे कोई स्रोत दे सकते हैं मैं यह कैसे कर सकता हूं? या क्या आप जानते हैं कि कोई विस्तार स्पष्टीकरण कहां हो सकता है? बहुत बहुत धन्यवाद – scatterbraiin

+0

मुझे पूरा यकीन है कि 64-बिट एप्लिकेशन 32-बिट COM घटकों का भी उपयोग नहीं कर सकता है, या क्या मैं यहां गलत हूं? 32-बिट COM नियंत्रण का उपयोग करने से पहले मुझे यह समस्या आई है और जब तक मैंने अपनी सी # प्रोजेक्ट को X86 के रूप में संकलित नहीं किया तब तक त्रुटियां मिलीं। –

+0

दुर्भाग्यवश यह मेरे लिए एक विकल्प नहीं है :( – scatterbraiin

1

बस अपने .NET एप्लिकेशन को प्लेटफ़ॉर्म x86 के रूप में संकलित करें। यह x64 मशीनों पर चलेगा और यह आपके 32 बिट डीएलएल का उपयोग करेगा। एक रैपर पर समय बर्बाद मत करो।

+0

अंतर्निहित ओएस 64 बिट होने पर कोई विकल्प नहीं है, क्योंकि यह ओएस परत से गुज़रने वाले अपवादों को निगल देगा और आप उन्हें नहीं देख पाएंगे! – XMight

+0

आप किस जादुई ओएस कॉन्फ़िगरेशन का सपना देख चुके हैं जहां आप 64 बिट ओएस पर 32 बिट .Net ऐप चला सकते हैं लेकिन अपवाद "निगल" हैं ... – user7116

+2

यह एक सपने में नहीं है, लेकिन कई महीनों के लिए मेरी विकास की स्थिति है। मेरे पास 64 बिट विकास मशीन है, और यदि आप x86 प्लेटफ़ॉर्म के लिए संकलित करते हैं तो अपवाद निगल जाते हैं (समांतर कार्यों से और न केवल)। विजुअल स्टूडियो केवल आउटपुट विंडो "अपवाद का पहला मौका" में दिखाता है जो स्पष्ट रूप से आप क्लाइंट ऐप में नहीं देख पाएंगे। कारण: http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/ – XMight

संबंधित मुद्दे