.net - मैं विजुअल स्टूडियो संकलन त्रुटि को कैसे ठीक करूं, "प्रोसेसर आर्किटेक्चर के बीच मेल नहीं खाता"?




visual-studio (12)

मैं विजुअल स्टूडियो 2010 में प्रोजेक्ट कॉन्फ़िगरेशन के लिए नया हूं, लेकिन मैंने कुछ research और अभी भी इस मुद्दे को काफी समझ नहीं सकता है। मेरे पास सी # डीएलएल संदर्भित सी ++ डीएलएल के साथ एक विजुअल स्टूडियो समाधान है। सी # डीएलएल कुछ अन्य डीएलएल का संदर्भ देता है, कुछ मेरी परियोजना के भीतर और कुछ बाहरी। जब मैं सी ++ डीएलएल संकलित करने का प्रयास करता हूं, तो मुझे यह चेतावनी मिलती है:

एमएसबी 3270 चेतावनी: परियोजना के प्रोसेसर आर्किटेक्चर "एमएसआईएल" और "[आंतरिक सी # डीएलएल]", "x86" के प्रोसेसर आर्किटेक्चर के बीच एक विसंगति थी।

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

जब मैं कॉन्फ़िगरेशन मैनेजर को देखता हूं तो यह मेरे सी # डीएलएल के लिए x86 के रूप में प्लेटफार्म दिखाता है और मेरे सी ++ प्रोजेक्ट के लिए Win32 के रूप में दिखाता है। यह सही सेटअप की तरह लगता है; निश्चित रूप से मैं नहीं चाहता कि मेरे सी ++ प्रोजेक्ट के लिए प्लेटफॉर्म को x64 पर सेट किया जाए, जो कि एकमात्र अन्य विकल्प प्रस्तुत किया गया है।

मुझसे यहां क्या गलत हो रहा है?


सी # डीएलएल प्लेटफार्म लक्ष्य x86 के साथ स्थापित है

कौन सी समस्या है, एक डीएलएल वास्तव में यह चुनने के लिए नहीं मिलता है कि प्रक्रिया का क्या खतरा होगा। यह पूरी तरह से EXE प्रोजेक्ट द्वारा निर्धारित किया गया है, यह पहली असेंबली है जो लोड हो जाती है, इसलिए इसकी प्लेटफ़ॉर्म लक्ष्य सेटिंग वह है जो प्रक्रिया के लिए गठबंधन को निर्धारित करती है और सेट करती है।

डीएलएल के पास कोई विकल्प नहीं है, उन्हें प्रक्रिया के साथ संगत होने की आवश्यकता है। यदि वे नहीं हैं तो आप BadImageFormatException के साथ एक बड़ा Kaboom प्राप्त करेंगे जब आपका कोड उनका उपयोग करने का प्रयास करता है।

तो डीएलएल के लिए एक अच्छा चयन AnyCPU है इसलिए वे किसी भी तरह से काम करते हैं। इससे सी # डीएलएल के लिए बहुत सारी समझ होती है, वे किसी भी तरह से काम करते हैं। लेकिन निश्चित रूप से, आपके सी ++ / सीएलआई मिश्रित मोड डीएलएल नहीं, इसमें अप्रबंधित कोड है जो प्रक्रिया केवल 32-बिट मोड में चलने पर अच्छी तरह से काम कर सकती है। आप इसके बारे में चेतावनियां उत्पन्न करने के लिए बिल्ड सिस्टम प्राप्त कर सकते हैं। जो आपको मिला वह ठीक है। बस चेतावनियां, यह अभी भी ठीक से बनाता है।

बस समस्या का शिकार करें। EXE प्रोजेक्ट के प्लेटफ़ॉर्म लक्ष्य को x86 पर सेट करें, यह किसी भी अन्य सेटिंग के साथ काम नहीं करेगा। और बस सभी डीएलएल परियोजनाओं को AnyCPU पर रखें।


.NET EXE / DLL AnyCPU बनाने के लिए एक तरीका होना चाहिए, और किसी भी अप्रबंधित DLLs यह x86 और x64 दोनों के साथ संकलित पर निर्भर करता है, दोनों अलग-अलग फ़ाइल नामों के साथ बंडल किए गए हैं और फिर .NET मॉड्यूल गतिशील रूप से अपने रनटाइम के आधार पर सही लोड कर रहा है प्रोसेसर वास्तुकला। यह AnyCPU शक्तिशाली बना देगा। यदि सी ++ डीएलएल केवल x86 या x64 का समर्थन करता है तो कोई भीCPU निश्चित रूप से व्यर्थ है। लेकिन दोनों विचारों को बंडल करने के लिए मैंने अभी तक कॉन्फ़िगरेशन मैनेजर के रूप में लागू नहीं किया है, एक ही प्रोजेक्ट को दोबारा एक अलग कॉन्फ़िगरेशन / प्लेटफॉर्म के साथ दोबारा बनाने के साधनों को भी प्रदान नहीं करता है, जिससे किसी भी कॉन्फ़िगरेशन की तरह किसी भी कॉन्फ़िगरेशन की अनुमति हो सकती है।


अंगूठे का एक अच्छा नियम "खुले डीएलएल, बंद EXEs" है, जो है:

  • EXE x86 या x64 निर्दिष्ट करके ओएस को लक्षित करता है।
  • डीएलएल खुले रह गए हैं (यानि, एसीसीपीयू) ताकि उन्हें 32-बिट या 64-बिट प्रक्रिया में तुरंत चालू किया जा सके।

जब आप किसी भी ईसीईयू के रूप में EXE बनाते हैं, तो आप जो भी कर रहे हैं, उस पर निर्णय लेना है कि ओएस को किस प्रक्रिया का उपयोग करना है, जो जेईटी को अपनी पसंद के लिए जेईटी करेगा। यही है, एक x64 ओएस 64-बिट प्रक्रिया बनाएगा, एक x86 ओएस 32-बिट प्रक्रिया बनाएगा।

डीएलएल का निर्माण किसी भी सीसीपीयू के रूप में उन्हें किसी भी प्रक्रिया के अनुकूल बनाता है।

असेंबली लोडिंग के subtleties पर अधिक के लिए, here देखें। कार्यकारी सारांश कुछ इस तरह पढ़ता है:

  • किसी भीCPU - invoking प्रक्रिया के आधार पर x64 या x86 असेंबली के रूप में लोड करता है
  • x86 - x86 असेंबली के रूप में लोड; एक x64 प्रक्रिया से लोड नहीं होगा
  • x64 - x64 असेंबली के रूप में लोड; एक x86 प्रक्रिया से लोड नहीं होगा


डेविड सैक के जवाब के अतिरिक्त, आपको Project Properties के Build टैब पर भी जाना होगा और Project Properties के लिए Platform Target को x86 सेट करना होगा जो आपको ये चेतावनियां दे रहा है। यद्यपि आप इसकी अपेक्षा कर सकते हैं, यह सेटिंग कॉन्फ़िगरेशन प्रबंधक में सेटिंग के साथ पूरी तरह सिंक्रनाइज़ नहीं होती है।


मुझे SQLite उद्घाटन कनेक्शन के साथ एक ही समस्या थी, और Nuget का उपयोग करके और प्रोजेक्ट (SQLite) में उपयोग किए गए घटक को स्थापित करने से इसे ठीक किया गया! अपने घटक को इस तरह से स्थापित करने का प्रयास करें और परिणाम की जांच करें


मुझे एमएस यूनिट टेस्ट डीएलएल के कारण इसी तरह की समस्या थी। मेरा डब्ल्यूपीएफ एप्लीकेशन x86 के रूप में संकलित किया गया था लेकिन इकाई परीक्षण डीएलएल (संदर्भित EXE फ़ाइल) "कोई भी CPU" के रूप में। मैंने यूनिट टेस्ट डीएलएल को x86 (EXE के समान) के लिए संकलित करने के लिए बदल दिया और इसे पुनर्स्थापित किया गया।


मुझे पहले भी इसी तरह की समस्या थी, विशेष रूप से जब मौजूदा x64 समाधान, जैसे SharePoint के लिए परीक्षण समाधान जोड़ना। मेरे मामले में, ऐसा लगता है कि कुछ परियोजना टेम्पलेट डिफ़ॉल्ट रूप से कुछ प्लेटफ़ॉर्म के रूप में जोड़े जाते हैं।

यहां समाधान है जो अक्सर मेरे लिए काम करता है: कॉन्फ़िगरेशन मैनेजर में सक्रिय प्लेटफॉर्म पर सब कुछ सेट करें (सक्रिय कॉन्फ़िगरेशन ड्रॉप-डाउन, सामान्य रूप से डीबग कहता है, इसे पाने का एक अच्छा तरीका है) और प्रोजेक्ट प्लेटफ़ॉर्म (प्रोजेक्ट गुणों में), फिर निर्माण करें, फिर सब कुछ वापस किसी भीCPU पर सेट करें। कभी-कभी मुझे कुछ निर्भरताओं (प्रत्येक प्रोजेक्ट की गुणों में डीएलएल) को हटाने और फिर से जोड़ना पड़ता है और कभी-कभी "32 बिट या 64 बिट प्रक्रिया में परीक्षण चलाएं" (स्थानीय.testsettings पर डबल-क्लिक करें और होस्ट पर जाएं) को बदलना होगा।

ऐसा लगता है कि यह सिर्फ कुछ स्थापित करने के बाद इसे स्थापित कर रहा है, लेकिन शायद उन दृश्यों के पीछे आगे बढ़ रहा है जिन्हें मैं नहीं देख रहा हूं। हालांकि यह अतीत में मेरे लिए काफी लगातार काम करता है।


मेरी परियोजना के लिए, मुझे x86 और x64 दोनों को बनाने में सक्षम होने की आवश्यकता है। इसके साथ समस्या यह है कि जब भी आप एक का उपयोग करते समय संदर्भ जोड़ते हैं, तो यह शिकायत करता है जब आप दूसरे का निर्माण करते हैं।

मेरा समाधान * .csproj फ़ाइलों को मैन्युअल रूप से संपादित करना है ताकि इन जैसे लाइनें:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=x86"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=AMD64"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL"/>

इसमें बदल जाओ:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral"/>

मेरे निर्माण में मुझे बहुत ही समान चेतावनी थी। मेरी परियोजनाओं को .NET 4.5 को लक्षित करने के लिए सेट किया गया था, बिल्ड सर्वर पर विंडोज 8.1 एसडीके (.NET 4.5.1 के लिए) स्थापित किया गया था। .NET 4.5.1 को लक्षित करने के लिए मेरी परियोजनाओं को अपडेट करने के बाद (मेरे लिए कोई समस्या नहीं थी, पूरी तरह से नए एप्लिकेशन के लिए था), मुझे अब चेतावनी नहीं मिली ...


यदि आपके सी # डीएलएल में x86- आधारित निर्भरता है, तो आपका डीएलएल स्वयं x86 होना होगा। मैं वास्तव में उस के आसपास एक रास्ता नहीं देखता हूँ। वीएस इसे बदलने के बारे में शिकायत करता है (उदाहरण के लिए) x64 क्योंकि 64-बिट निष्पादन योग्य 32-बिट पुस्तकालय लोड नहीं कर सकता है।

मैं सी ++ प्रोजेक्ट की कॉन्फ़िगरेशन के बारे में थोड़ा उलझन में हूं। निर्माण के लिए प्रदान किया गया चेतावनी संदेश सुझाव देता है कि इसे किसी भी सीसीपीयू के लिए लक्षित किया गया था, क्योंकि यह उस प्लेटफॉर्म की सूचना देता है जिसे लक्षित किया गया था [MSIL], लेकिन आपने संकेत दिया कि परियोजना के लिए कॉन्फ़िगरेशन वास्तव में Win32 था। एक मूल Win32 ऐप में एमएसआईएल शामिल नहीं होना चाहिए - हालांकि सीएलआर समर्थन सक्षम होने की संभावना है यदि यह सी # लाइब्रेरी के साथ बातचीत कर रहा है। तो मुझे लगता है कि सूचना पक्ष पर कुछ अंतराल हैं।

क्या मैं सम्मानपूर्वक उनसे समीक्षा कर सकता हूं और परियोजनाओं की सटीक विन्यास के बारे में थोड़ा और विस्तार कर सकता हूं और वे कैसे जुड़े हुए हैं? यदि संभव हो तो आगे की मदद करने में प्रसन्न रहें।


यह एक बहुत ही जिद्दी चेतावनी है और यह एक वैध चेतावनी है, जबकि कुछ ऐसे मामले हैं जहां इसे तृतीय पक्ष घटकों और अन्य कारणों के उपयोग के कारण हल नहीं किया जा सकता है। मेरे पास एक समान समस्या है सिवाय इसके कि चेतावनी इसलिए है क्योंकि मेरी परियोजना प्लेटफॉर्म एएनसीपीयू है और मैं एएमडी 64 के लिए निर्मित एमएस लाइब्रेरी का संदर्भ दे रहा हूं। यह विजुअल स्टूडियो 2010 में है, और वीएस2012 और नेट 4.5 स्थापित करके पेश किया जा रहा है।

चूंकि मैं एमएस लाइब्रेरी को बदल नहीं सकता हूं, मैं संदर्भित कर रहा हूं, और जब से मुझे पता है कि मेरा लक्ष्य परिनियोजन वातावरण केवल 64-बिट होगा, मैं इस मुद्दे को सुरक्षित रूप से अनदेखा कर सकता हूं।

चेतावनी के बारे में क्या? माइक्रोसॉफ्ट ने कनेक्ट रिपोर्ट के जवाब में पोस्ट किया कि एक विकल्प उस चेतावनी को अक्षम करना है। आपको केवल यह करना चाहिए कि आप अपने समाधान वास्तुकला से बहुत अवगत हैं और आप अपने परिनियोजन लक्ष्य को पूरी तरह से समझते हैं और जानते हैं कि यह वास्तव में विकास पर्यावरण के बाहर एक मुद्दा नहीं है।

आप अपनी प्रोजेक्ट फ़ाइल को संपादित कर सकते हैं और चेतावनी को अक्षम करने के लिए इस प्रॉपर्टी समूह और सेटिंग को जोड़ सकते हैं:

<PropertyGroup>
  <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>




visual-studio