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

Question

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

चेतावनी MSB3270:: जब मैं सी ++ DLL संकलित करने के लिए प्रयास करते हैं, मैं इस चेतावनी मिल परियोजना "MSIL" का निर्माण किया जा रहा है की प्रोसेसर आर्किटेक्चर और संदर्भ के प्रोसेसर आर्किटेक्चर "[आंतरिक सी # के बीच एक बेमेल थी डीएलएल] "," x86 "।

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

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

मैं यहाँ क्या गलत कर रहा हूं?

Answer 1

यह चेतावनी, नए दृश्य स्टूडियो 11 बीटा और .NET 4.5 के साथ पेश किया गया है लगता है।

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

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

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

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

Answer 2

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

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

Answer 3

सी # DLL

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

मुझे ऐसा लगता है कि यह सिर्फ फिर कुछ स्थापित कर रही है इसे वापस की स्थापना, लेकिन वहाँ शायद और अधिक दृश्यों कि मैं नहीं दिखाई दे रही है पीछे चल रहा है। हालांकि यह अतीत में मेरे लिए काफी लगातार काम करता है।

Answer 7

इसका एक अच्छा नियम है "खुला DLLs, बंद व्यय", वह यह है कि:

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

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

AnyCPU के रूप में बिल्डिंग DLLs उन्हें या तो प्रक्रिया के लिए संगत बना देता है।

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

• AnyCPU -, 64 या 86 विधानसभा के रूप में लोड प्रेरक प्रक्रिया पर निर्भर करता है
• - 86 विधानसभा के रूप में लोड; एक 64 प्रक्रिया
• से लोड नहीं होगा - 64 विधानसभा के रूप में लोड; x86 प्रक्रिया

Answer 8

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

Answer 9

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

<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"/> 

यह करने के लिए बदल जाओ:

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

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

Answer 10

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

Answer 11

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

Answer 12

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

Answer 13

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

Answer 14

आप एमएस फॉक्स असेंबली के लिए यह चेतावनी भी प्राप्त कर सकते हैं जो f.csproj कमांड पर निर्माण के बाद हल करने में आसान नहीं है। सौभाग्य से the Fakes xml allows you to add it in there।

Answer 15

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

Answer 16

मैं एक ही चेतावनी मैं ऐसा किया हो रही थी:

1) अनलोड परियोजना 2) संपादित परियोजना गुण यानी .csproj 3> टैग का पालन

4) फिर से लोड परियोजना 5) हो गया जोड़ें। ..

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

Answer 17

मैं आज इस समस्या थी और सिर्फ दृश्य स्टूडियो में निर्माण विन्यास के लिए देख मदद नहीं कर रहा था क्योंकि यह दोनों परियोजना है कि निर्माण नहीं किया गया था और refere के लिए किसी भी सीपीयू से पता चला nced परियोजना।

मैं तो संदर्भित परियोजना के 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> 

किसी तरह इस PlatformTarget एक config परिवर्तन और आईडीई के बीच में जोड़ा गया देखने के लिए नहीं मालूम था यह।

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

Answer 18

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