मैं विज़ुअल स्टूडियो संकलन त्रुटि, "प्रोसेसर आर्किटेक्चर के बीच बेमेल" कैसे तय करूं?

458

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

MSB3270 को चेतावनी देना: "MSIL" और संदर्भ के प्रोसेसर आर्किटेक्चर "[आंतरिक C # dll]", "x86" का निर्माण करने वाले प्रोसेसर आर्किटेक्चर के बीच एक बेमेल संबंध था।

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

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

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

.net  visual-studio 
— पॉल ईस्टलुंड
स्रोत
शिकायत क्या है, विशेष रूप से, जब आप इसे किसी भी सीपीयू में बदलते हैं?
— लॉर्डचेतो
2
मेरे पास एक सूचित सुझाव बनाने के लिए पर्याप्त जानकारी नहीं है, लेकिन अपने समाधान पर राइट क्लिक करें -> प्रोजेक्ट बिल्ड ऑर्डर और सुनिश्चित करें कि आपका C # प्रोजेक्ट C ++ प्रोजेक्ट से पहले बनाया जा रहा है। यदि यह नहीं है, तो निर्भरता टैब पर जाएं और वीएस को बताएं कि सी ++ प्रोजेक्ट सी # प्रोजेक्ट पर निर्भर करता है।
— लॉर्डचेतो
2
विजुअल स्टूडियो इस पर फिर से बकवास है। मेरी स्क्रीन के शीर्ष पर प्लेटफ़ॉर्म x64 कहता है, लेकिन चेतावनी कहती है कि बनाया जा रहा प्रोजेक्ट "MSIL" है। तो विज़ुअल स्टूडियो मुझे बता रहा है कि जब मैं सेब का उपयोग नहीं कर रहा हूं तो सेब और संतरे के बीच एक बेमेल संबंध है। क्या हम इसका नाम बदलकर Visual Stupido रख सकते हैं?
— पॉल मैकार्थी
जहाँ तक मेरा सवाल है यह Visual Studio में एक बग है। मैं प्लेटफ़ॉर्म लक्ष्य के रूप में x64 का चयन करता हूं और यह बताता है कि मैं इस परियोजना का निर्माण एमएसआईएल के लिए कर रहा हूं।
— पॉल मैकार्थी
संक्षिप्त उत्तर यह है कि अगर आपके प्रोजेक्ट में x86 या x64 पर निर्भरता है, तो आप किसी भी CPU (जो केवल शुद्ध .NET अनुप्रयोगों के लिए है) का उपयोग नहीं कर सकते हैं। तो आपको या तो x64 या x32 के लिए निर्माण करना होगा, न कि किसी सीपीयू से। यह डेव के उत्तर
— ज़ार

जवाबों:

512

ऐसा लगता है कि नए विज़ुअल स्टूडियो 11 बीटा और .NET 4.5 के साथ पेश किया गया है, हालांकि मुझे लगता है कि यह पहले संभव हो सकता है।

पहला, यह वास्तव में सिर्फ एक चेतावनी है। यदि आपको x86 निर्भरता के साथ काम कर रहे हैं तो यह कुछ भी चोट नहीं पहुंचनी चाहिए। Microsoft आपको केवल यह बताने की कोशिश कर रहा है कि जब आप कहते हैं कि आपकी परियोजना "किसी भी CPU" के साथ संगत है, लेकिन आपके पास एक परियोजना या। Dll असेंबली की निर्भरता है जो या तो x86 या x64 है। क्योंकि आपके पास x86 निर्भरता है, इसलिए तकनीकी रूप से आपकी परियोजना "कोई भी CPU" संगत नहीं है। चेतावनी को दूर करने के लिए, आपको वास्तव में अपनी परियोजना को "किसी भी सीपीयू" से "x86" में बदलना चाहिए। यह करना बहुत आसान है, यहां कदम हैं।

  1. कॉन्फ़िगरेशन प्रबंधक मेनू आइटम बिल्ड पर जाएं।
  2. अपने प्रोजेक्ट को सूची में ढूंढें, प्लेटफ़ॉर्म के तहत यह "कोई भी सीपीयू" कहेगा
  3. ड्रॉप डाउन से "कोई भी सीपीयू" विकल्प चुनें और फिर चुनें <New..>
  4. उस संवाद से, "नया प्लेटफ़ॉर्म" ड्रॉप डाउन से x86 का चयन करें और सुनिश्चित करें कि "ड्रॉप डाउन" से "किसी भी सीपीयू" को "कॉपी सेटिंग्स" में चुना गया है।
  5. ठीक है मारो
  6. आप डिबग और रिलीज़ कॉन्फ़िगरेशन दोनों के लिए x86 का चयन करना चाहेंगे।

यह चेतावनी को दूर कर देगा और यह भी बताएगा कि आपकी असेंबली या प्रोजेक्ट अब "कोई भी CPU" संगत नहीं है, लेकिन अब x86 विशिष्ट है। यह तब भी लागू होता है जब आप 64 बिट प्रोजेक्ट बना रहे हैं जिसमें x64 निर्भरता है; आप इसके बजाय x64 का चयन करेंगे।

एक अन्य नोट, परियोजनाएं "कोई भी CPU" संगत हो सकती हैं यदि वे शुद्ध .NET प्रोजेक्ट हैं। यह समस्या केवल तभी सामने आती है जब आप एक विशिष्ट प्रोसेसर आर्किटेक्चर को लक्षित करने वाली एक निर्भरता (3 पार्टी डीएल या अपने स्वयं के सी ++ प्रबंधित प्रोजेक्ट) का परिचय देते हैं।

— डेविड सैक्स
स्रोत
3
मैंने अभी विजुअल स्टूडियो 2012 के RTW को स्थापित किया और 2010 का एक विचित्र समाधान खोला और उसी चेतावनी को देखना शुरू किया, इसलिए यह ऐसा कुछ है जो अभी भी RTW में विद्यमान है।
— टॉड थॉमसन
4
यह कहा जा रहा है, मुझे लगता है कि डेविड का जवाब सही है, यह चेतावनी आपको बता रही है कि आपका ऐप वास्तव में "एएनसीपीयू" नहीं है, इसलिए आप उन मुद्दों पर चलेंगे जब आप अंततः इसे गलत आर्किटेक्चर में तैनात करेंगे।
— टॉड थॉमसन
6
यह बहुत अच्छी तरह से कुछ चोट पहुंचा सकता है। कोई भी CPU एक्सई 64 बिट OS पर x64 के रूप में लोड होगा और x86 dll को लोड करने में असमर्थ होगा। इसलिए यदि आपके पास किसी विशेष प्लेटफ़ॉर्म पर निर्भरता है, तो वास्तव में आपके प्लेटफ़ॉर्म को सही तरीके से सेट करना चाहिए।
— यौर
1
वीएस सी # 2010 एक्सप्रेस में बिल्ड मेनू गायब लगता है। मैं इसे कैसे प्राप्त करूं? काश वे चीजें नहीं छिपाते।
— Xonatron
1
बस दृश्य स्टूडियो 2010 एक्सप्रेस में निर्माण मेनू को सक्षम करने का तरीका पता चला: उपकरण मेनू -> सेटिंग्स -> 'विशेषज्ञ सेटिंग' का चयन करें
— Xonatron
144

यह एक बहुत ही जिद्दी चेतावनी है और यह एक वैध चेतावनी है जबकि कुछ मामले हैं जहां इसे 3 पार्टी घटकों और अन्य कारणों के उपयोग के कारण हल नहीं किया जा सकता है। मेरे पास एक समान मुद्दा है सिवाय इसके कि चेतावनी इसलिए है क्योंकि मेरा प्रोजेक्ट प्लेटफॉर्म AnyCPU है और मैं AMD64 के लिए निर्मित एक MS लाइब्रेरी का उल्लेख कर रहा हूं। यह दृश्य स्टूडियो 2010 में है, और VS2012 और .net 4.5 को स्थापित करके पेश किया गया है।

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

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

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

<PropertyGroup>
  <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
— जियो पालासिनो
स्रोत
1
इस समाधान का केवल दूसरा आधिकारिक एमएस संदर्भ जो मैंने देखा है वह Microsoft .NET फ्रेमवर्क 4.5 RC Readme फ़ाइल में है । अजीब तरह से इसे आरटीएम रीडमी फ़ाइल से हटा दिया गया था।
— जॉन्स
4
यह काम करता है, लेकिन चेतावनी की भिन्नता के लिए नहीं: "संदर्भित विधानसभा ... आवेदन की तुलना में एक अलग प्रोसेसर को लक्षित करता है"। यह बहुत अच्छा होगा अगर इस चेतावनी के लिए एक समान सेटिंग थी?
— जिमी
6
"मेरा प्रोजेक्ट प्लेटफॉर्म AnyCPU है और मैं AMD64 के लिए निर्मित एक MS लाइब्रेरी का उल्लेख कर रहा हूं" ... यह WRONG है। चूंकि आपकी लक्ष्य तैनाती हमेशा 64-बिट होती है, इसलिए आप अपने प्लेटफॉर्म को x64 पर सेट कर सकते हैं, जो अधिक उपयुक्त त्रुटि के लिए बनाता है यदि आपकी 64-बिट धारणा का कभी भी उल्लंघन होता है, और चेतावनी को भी रोकता है।
— बेन वोयगेट
2
@BenVoigt सिद्धांत में एक महान विचार है, लेकिन वी.एस. एक x86 प्रक्रिया होने के नाते विंडोज फॉर्म डिजाइनर की तरह सामान चलाने के लिए x86 नियंत्रण की आवश्यकता है, भले ही आपका आवेदन केवल 64 बिट हो। यह एक गलत "किसी भी सीपीयू" बिल्ड का उपयोग करने का एक वैध, लेकिन दुर्भाग्यपूर्ण कारण है।
— जूनियर
1
@jrh: फिर एक DLL परियोजना में जीयूआई रखा, और निर्माण कि AnyCPU के रूप में। EXE को मूल निर्भरता से मेल खाने के लिए सही आर्किटेक्चर के साथ चिह्नित करने की आवश्यकता है। GUI को तर्क से अलग करना एक लंबा रास्ता तय करता है (हालाँकि इसकी सीमाएँ अभी भी हैं, जैसे कि जब देशी कोड GUI का हिस्सा प्रदान कर रहा है, लेकिन तब डिज़ाइनर सपोर्ट एक खो कारण है जब तक आप दोनों के लिए पूरे प्रोजेक्ट का निर्माण नहीं करते हैं x86 और x64)
— बेन वोइगट
61

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

  • EXE OS को लक्ष्य करता है, x86 या x64 निर्दिष्ट करके।
  • DLL को खुला छोड़ दिया जाता है (यानी, AnyCPU) ताकि उन्हें 32-बिट या 64-बिट प्रक्रिया के भीतर त्वरित किया जा सके।

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

AnyCPU के रूप में DLLs का निर्माण उन्हें या तो प्रक्रिया के अनुकूल बनाता है।

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

  • AnyCPU - x64 या x86 असेंबली के रूप में लोड करता है, जो कि चालान प्रक्रिया पर निर्भर करता है
  • x86 - x86 विधानसभा के रूप में लोड; x64 प्रक्रिया से लोड नहीं होगा
  • x64 - x64 विधानसभा के रूप में लोड; x86 प्रक्रिया से लोड नहीं होगा
— गुस्तावो मोरी
स्रोत
4
यह नियम मेरे लिए मायने रखता है। लेकिन निम्न स्थिति पर विचार करें: Net1.dll (किसी भी सीपीयू) द्वारा प्रयुक्त नेटिवेल (x64) नेटबेल (किसी भी सीपीयू) द्वारा प्रयुक्त App1.exe (x64)। यहाँ कोई वास्तविक समस्या नहीं है, लेकिन NetA.dll का संकलन मुझे चेतावनी देता है। ठीक है, चूंकि यह विधानसभा सीधे Native.dll पर निर्भर करती है, इसलिए मैं इसे x64 के रूप में भी चिह्नित कर सकता हूं। लेकिन इसके बाद नेटबी.डेल कंप्लेन करता है। मैं NetB.dll को "किसी भी सीपीयू" के रूप में रखना चाहता हूं क्योंकि यह एक अलग, शुद्ध-डॉट-नेट एप्लिकेशन में उपयोग की जाने वाली एक आम सभा है। मैं निष्कर्ष निकालता हूं कि मेरा एकमात्र विकल्प चेतावनी को दबाने / अनदेखा करना है। हाँ?
— स्टीव रॉबिंस
2
Native.dll पर निर्भरता के कारण, आपका पूरा ऐप / असेंबली वंश अब x64 है, चाहे आपकी चेतावनी को दबा दिया जाए या नहीं। जबकि दमन आपके परिदृश्य में काम करता है, भविष्य में अजीब स्थिति पैदा हो सकती है। उदाहरण के लिए, 1) असेंबली नेटबी का उपयोग x86 वातावरण में किया जाता है, जहां नेटिव 6464 लोड नहीं होगा, या 2) आपका ग्राहक App1.exe का x86 संस्करण चाहता है, और आप खुशी से संकलन करते हैं, क्योंकि नेटबी किसी भी सीपीयू के रूप में चिह्नित है, लेकिन फिर से। ढेर के शीर्ष पर Nativex64 लोड नहीं होगा
— गुस्तावो मोरी
जबकि गुस्तावो का नियम एक अच्छा सिद्धांत है, इसका उपयोग इस प्रश्न में पूछी गई विशिष्ट समस्या के लिए नहीं किया जा सकता है क्योंकि परियोजना में पहले से ही एक 3 पार्टी विधानसभा पर निर्भरता है जो नियम का पालन नहीं किया (यह x86 है, AnyCPU नहीं)। इसलिए जब तक निर्भरता है परियोजनाओं की पूरी श्रृंखला x86 को लक्षित करना चाहिए और कुछ नहीं।
— डेविड बर्ग
23

C # DLL को प्लेटफ़ॉर्म लक्ष्य x86 के साथ सेट किया गया है

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

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

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

बस समस्या को कुंद करें। EXE प्रोजेक्ट के प्लेटफ़ॉर्म लक्ष्य को x86 पर सेट करें, यह किसी अन्य सेटिंग के साथ काम करने वाला नहीं है। और AnyCPU में सभी DLL प्रोजेक्ट्स को रखें।

— हंस पसंत
स्रोत
1
तो, स्पष्ट होने के लिए: मैं EXE का निर्माण नहीं कर रहा हूं, मैं किसी और के EXE के साथ चलने के लिए DLL का निर्माण कर रहा हूं। C # DLL के प्लेटफ़ॉर्म लक्ष्य को किसी भी CPU में बदलने से चेतावनी समाप्त नहीं होती है। मैं सोच रहा था कि क्या यह कनेक्ट का मामला है। Microsoft.VisualStudio / feedback / details / 728901/… - - मैं स्वयं चेतावनी को अनदेखा करूंगा लेकिन वास्तव में EXE C # DLL लोड करने में सक्षम है, लेकिन C ++ DLL नहीं इसलिए मुझे लगता है कि यह एक वास्तविक समस्या है।
— पॉल ईस्टलुंड
क्या आप वास्तव में VS2010 का उपयोग कर रहे हैं? यह भी स्पष्ट नहीं था कि आप C ++ / CLI DLL को लोड नहीं कर सकते। डायग्नोस्टिक क्या है? इस आवश्यक जानकारी के साथ अपने प्रश्नों को अपडेट करें।
— हंस पैसेंट
लोड विफलता के बारे में पोस्ट नहीं किया था क्योंकि मुझे यकीन नहीं था कि यह 100% जुड़ा हुआ था, और आगे डिबगिंग पर यह पता चलता है कि यह नहीं है। मैं VS2010 का उपयोग कर रहा हूं। अपडेटेड प्रश्न पाठ। भ्रम के लिए बहुत खेद है
— पॉल ईस्टलुंड
1
आपने DLL लोड करने से संबंधित किसी भी प्रकार की त्रुटि या अपवाद का दस्तावेज़ नहीं दिया है। अगर आप मुझे नहीं जानते, तो मैं आपकी मदद नहीं कर सकता। इसके साथ गुड लक।
— हंस पैसेंट
5

मुझे वही चेतावनी मिल रही थी जो मैंने यह किया:

  1. उतराई परियोजना
  2. संपादित करें परियोजना गुण .csproj

  3. निम्नलिखित टैग जोड़ें:

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

  4. प्रोजेक्ट को पुनः लोड करें

— योगेश्वर गुट्टे
स्रोत
2
इससे समस्या हल नहीं हो रही है। यह सिर्फ विशेष परियोजना के लिए चेतावनी को अक्षम कर रहा है। लेकिन कुछ मामलों में मुझे यह एक वैध समाधान लगता है। धन्यवाद!
— टिनी
4

मुझे आज यह समस्या थी और केवल विजुअल स्टूडियो में बिल्डिंग कॉन्फ़िगरेशन देखने में मदद नहीं कर रहा था क्योंकि यह दोनों प्रोजेक्ट के लिए किसी भी सीपीयू को दिखाता था जो बिल्डिंग और संदर्भित प्रोजेक्ट नहीं था।

मैंने तब संदर्भित प्रोजेक्ट के csproj में देखा और यह पाया:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x64</PlatformTarget>

किसी तरह यह प्लेटफॉर्मटार्ग एक विन्यास परिवर्तन के बीच में जुड़ गया और आईडीई ने इसे देखा नहीं।

संदर्भित परियोजना से इस लाइन को हटाने से मेरी समस्या हल हो गई।

— JBourne
स्रोत
मुझे यह पता लगाने में पूरा दिन लग गया। आपका बहुत बहुत धन्यवाद! :)
— सोहमक
3

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

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

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

— डेविड डब्ल्यू
स्रोत
3

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

— डेव कजिनो
स्रोत
2

C # प्रोजेक्ट्स के लिए, x86 का लक्ष्य वही करता है जो उसे अच्छा लगता है। यह कहता है कि यह विधानसभा केवल x86 आर्किटेक्चर का समर्थन करती है। इसी तरह x64 के लिए। दूसरी ओर कोई भी सीपीयू कहता है कि मुझे इस बात की परवाह नहीं है कि मैं किस आर्किटेक्चर का समर्थन करता हूं। तो, अगले 2 प्रश्न हैं (1) निष्पादन योग्य का विन्यास क्या है जो इन dll का उपयोग करता है? और (2) बिटनेस क्या हैअपने ओएस / कंप्यूटर की? मेरे द्वारा पूछे जाने का कारण यह है क्योंकि यदि आपके निष्पादन योग्य को 64-बिट में चलाने के लिए संकलित किया जाता है, तो यह सभी निर्भरता को 64-बिट मोड में भी चलाने में सक्षम होने के लिए आवश्यक है। आपकी किसी भी सीपीयू असेंबली को लोड करने में सक्षम होना चाहिए, लेकिन शायद यह कुछ अन्य निर्भरता को संदर्भित कर रहा है जो केवल x86 कॉन्फ़िगरेशन में चलने में सक्षम है। यदि आप 64-बिट मोड में निष्पादन योग्य चलाने की योजना बनाते हैं, तो यह सुनिश्चित करने के लिए कि सभी कुछ "कोई भी सीपीयू" या "x64" है, सभी निर्भरता और निर्भरता-निर्भरता की जांच करें। अन्यथा, आपके पास मुद्दे होंगे।

कई मायनों में, विजुअल स्टूडियो किसी भी सीपीयू और विभिन्न आर्किटेक्चर पर निर्भर असेंबलियों के मिश्रण को आसान नहीं बनाता है। यह उल्लेखनीय है, लेकिन इसके लिए अक्सर यह आवश्यक होता है कि एक असेंबली जो कि "कोई भी सीपीयू" हो, जिसे x86 और x64 के लिए अलग-अलग संकलित किया जाना चाहिए क्योंकि कुछ निर्भरता-ए-निर्भरता के कहीं-कहीं दो संस्करण हैं।

— जोनाथन डेकार्लो
स्रोत
क्या निष्पादन योग्य पदार्थ का विन्यास स्थिर है क्योंकि मुझे केवल DLL बनाने की कोशिश में विफलता मिल रही है? (यह x86 हालांकि है।) मेरा कंप्यूटर x64 है।
— पॉल ईस्टलुंड
2
यह निष्पादन योग्य है जो यह निर्धारित करता है कि किस बिटनेस का उपयोग किया जाएगा। यदि निष्पादन योग्य x64 के रूप में चल रहा है, तो कुछ भी लोड होता है (प्रत्यक्ष या अप्रत्यक्ष रूप से) x64 या कोई CPU होना चाहिए। यदि निष्पादन योग्य x86 के रूप में चल रहा है, तो कुछ भी लोड होता है (प्रत्यक्ष या अप्रत्यक्ष रूप से) x86 या कोई CPU होना चाहिए।
— जोनाथन डेकार्लो
1

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

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

यह मुझे लगता है कि यह सिर्फ कुछ सेट कर रहा है फिर इसे वापस सेट कर रहा है, लेकिन संभवतः उन दृश्यों के पीछे चल रहा है जो मैं नहीं देख रहा हूं। हालांकि यह मेरे लिए अतीत में लगातार काम किया है।

— ssamuel
स्रोत
1

मेरी परियोजना के लिए, मुझे 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"/>
— Thick_propheT
स्रोत
1

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

— user1257110
स्रोत
0

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

— ग्रेगरी मोर्स
स्रोत
2
stackoverflow में आपका स्वागत है! क्या आप इस उत्तर को थोड़ा ध्यान केंद्रित करने / सुधारने की कोशिश कर सकते हैं?
— कॉर्ली ब्रिग्मैन
ऐसा लगता है कि यह एक अच्छा सवाल, या एक ब्लॉग पोस्ट या कनेक्ट पर एक सुविधा अनुरोध करेगा ... यह वास्तव में इस एक का जवाब नहीं देता है।
— बेन वोयगेट
0

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

— NicoCV
स्रोत
0

मैंने इस चेतावनी को "कॉन्फ़िगरेशन प्रबंधक" को रिलीज़ (मिश्रित प्लैटफॉर्म) में बदलते हुए हल किया।

— एडू पेलाइस
स्रोत
0

SQL Server 2012 SP1 SSIS पाइपलाइन स्क्रिप्ट कार्य को संकलित करते समय मुझे विजुअल स्टूडियो 2012 में यह चेतावनी मिली - जब तक मैंने SQL सर्वर 2012 SP2 स्थापित नहीं किया।

— cdonner
स्रोत
0

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

— StudioX
स्रोत
0

Https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-example का उपयोग करें :

  • अपने समाधान फ़ोल्डर में एक Directory.Build.props फ़ाइल जोड़ें
  • इसे इसमें पेस्ट करें: 
<Project>
 <PropertyGroup>
   <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
 </PropertyGroup>
</Project>
— साइडराइट ज़ैकवेहडेक्स
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.