Assembly.LoadFrom BadImageFormatException - .NET 4.0 और 4.5 (संभवतः गैर-दस्तावेजी)

Question

अनुसार MSDN documentation करने के लिए अलग व्यवहार,

public static Assembly LoadFrom(string assemblyFile) 

फेंकता BadImageFormatException

अगर

assemblyFile is not a valid assembly. 
-or- 
Version 2.0 or later of the common language runtime is currently loaded 
and assemblyFile was compiled with a later version. 

वास्तव में, वहाँ एक अतिरिक्त मामला है - लोड हो रहा है असेंबली से x86 के लिए बनाई गई असेंबली जो x64 मोड में चलती है। शायद इसे "वैध असेंबली नहीं" कथन में शामिल किया गया है, मुझे नहीं पता। लेकिन यह अपवाद का उचित कारण है।

ठीक है, लेकिन .NET 4.5 में यह नहीं है! मेरे पास एक .NET 4.5 WPF ऐप है, जो किसी कारण से अलग-अलग एप्लायंस लोड करता है। यह किसी भी सीपीयू के लिए निर्माण कर रहा है और मैं इसे x64 विन 7 पर शुरू कर रहा हूं। मैं इसे एक निष्पादन योग्य पर परीक्षण कर रहा हूं, जो .NET 4.0 x86 के लिए बनाया गया है, और यह ठीक काम करता है। लेकिन जब मैंने अपना ऐप .NET 4.0 पर स्विच किया तो यह Assembly.Load विधि पर दुर्घटनाग्रस्त हो गया!

तो, मेरा सवाल है, क्या मुझे कुछ याद आ रही है? यदि नहीं, तो उन्होंने ऐसा कैसे किया - x64 प्रक्रिया से x64 प्रक्रिया में x86 असेंबली लोड हो रही है? मुझे इस बिंदु पर कुछ समझ की कमी है।

अद्यतन

हंस Passant के लिए धन्यवाद, मैं अपनी गलती खोज निकाला है। वास्तव में Assembly.Load का व्यवहार कोई अलग है। यह निकला, मैंने प्रोजेक्ट सेटिंग्स में Prefer 32-bit विकल्प (या .csproj फ़ाइल में Prefer32Bit टैग) को नोटिस नहीं किया था। यही कारण है कि मेरी प्रक्रिया .NET 4.5 ran in a 32-bit mode में। जब मैंने WPF .NET 4.5 प्रोजेक्ट बनाया था तो यह सेटिंग सच थी। फिर, जब मैंने .NET 4.0 पर स्विच किया तो यह निष्क्रिय हो गया क्योंकि .NET 4.0 में ऐसा कोई विकल्प नहीं था। और जब मैंने .NET 4.5 पर वापस स्विच किया तो यह झूठी बन गया, जो मुझे लगता है, संगतता उद्देश्य के लिए।

Answer 1

चलो तालिका से तुरंत एक धारणा को साफ़ करते हैं, मशीन पर अलग-अलग व्यवहार करने का कोई संभावित तरीका नहीं है जिसमें .NET 4.5 स्थापित है। लक्ष्यीकरण 4.0 रनटाइम पर कोई फर्क नहीं पड़ता। एकमात्र चीज जो संदर्भ असेंबली का एक अलग सेट चुनती है, वे आपको .NET 4.5 पर उपलब्ध क्लास का उपयोग करके गलती से रोकते हैं लेकिन .NET 4.0 पर नहीं।

एक ही मशीन पर 4.0 और 4.5 दोनों स्थापित करने का कोई तरीका नहीं है। .NET 4.5 .NET फ्रेमवर्क का साइड-बाय-साइड संस्करण नहीं है, जैसे 3.5 और 4.0 साइड-बाय-साइड हैं। 4.5 स्थापित करना एक स्थापित 4.0 संस्करण को प्रतिस्थापित करता है। सीएलआर, जिटर, सभी रनटाइम असेंबली प्लस सी # कंपाइलर।

यह आपके EXE प्रोजेक्ट की प्लेटफ़ॉर्म लक्ष्य सेटिंग पर ध्यान केंद्रित करने के लिए सबसे अच्छा है, यही वह प्रक्रिया है जो प्रक्रिया के प्रत्यक्षदर्शी का चयन करता है। आप जिस तरह की गलतियों को कर सकते हैं वह भूल रहा है कि सेटिंग डिबग बनाम रिलीज बिल्ड के लिए अलग हो सकती है। और यह मानते हुए कि बिल्ड + कॉन्फ़िगरेशन प्रबंधक में "सक्रिय समाधान प्लेटफ़ॉर्म" combobox का कोई प्रभाव पड़ता है। यह नहीं, केवल परियोजना + गुण, बिल्ड टैब, प्लेटफार्म लक्ष्य सेटिंग मामलों। यह एक बहुत ही अजीब जाल है कि कई प्रोग्रामर गिर गए हैं।