2009-01-17 8 views
6

अब और फिर मैं एक .NET असेंबली के x86 और x64 संस्करण दोनों देखता हूं। निम्नलिखित web part for SharePoint पर विचार करें। डेवलपर सिर्फ एक संस्करण क्यों नहीं पेश करेगा और जेआईटी कंपाइलर को बाकी हिस्सों को हल करने देगा? जब मैं इन प्रकार की पेशकश देखता हूं तो यह है कि डेवलपर ने जेआईटी से बचने के लिए ngen जैसे टूल का उपयोग करके मूल छवि बनाने का निर्णय लिया है?.NET डेवलपर्स .NET असेंबली के 32-बिट/64-बिट संस्करण क्यों प्रदान करते हैं?

कोई मेरी मदद कर रहा है, मुझे लगता है कि मुझे कुछ नोट याद आ रहा है।

  1. डेवलपर JITing से बचना चाहते थे और एक देशी बनाया:

    अपडेट किया गया है कि मैं क्या नीचे मिला से, क्योंकि एक या अधिक निम्न कारणों से दोनों x86 और x64 पेशकश कर रहे हैं बनाता है ngen.exe जैसे टूल का उपयोग करके दिए गए आर्किटेक्चर को लक्षित करने वाले अपने कोड की छवि।

  2. असेंबली में प्लेटफ़ॉर्म विशिष्ट COM कॉल शामिल हैं और इसलिए इसे किसी भीCPC के रूप में बनाने का कोई मतलब नहीं है। इन मामलों में यह निर्धारित करता है कि लक्षित विभिन्न प्लेटफार्मों में अलग-अलग कोड हो सकते हैं।

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

+0

मैंने सोचा कि नर्ग केवल लक्ष्य मशीन पर ही चलाया जा सकता है। क्या अब यह मामला नहीं है? – erikkallen

उत्तर

6

वे विशिष्ट non-.Net एपीआई का उपयोग कर रहे हैं, तो फिर वहाँ इस के लिए दो कोड ठिकानों हो सकता है, एक आदर्श उदाहरण कॉम नियंत्रण है।

आपके द्वारा वर्णित अनुसार इसके लिए ngen भी एक और अच्छा कारण है।

+0

... और शायद पी/सामान भी शामिल करें। –

6

जब आप एक .NET अनुप्रयोग संकलित करते हैं तो आपको बिल्ड सेटिंग्स में प्लेटफ़ॉर्म लक्ष्य चुनना होगा। विकल्प AnyCPU, x86 और x64 हैं।

एक सामान्य बग एक परियोजना में AnyCPU निर्दिष्ट करना है जिसमें x86 के लिए संकलित देशी डीएलएल शामिल हैं। यह 64-बिट मशीनों पर चलने पर त्रुटियों का कारण बनता है, 64 बिट मशीन पर परीक्षण करने का एक अच्छा कारण है।

इसलिए, उन लोगों का समर्थन करने के लिए जो अपनी अन्य निर्भरताओं द्वारा सीधे x86 या x64 के निर्माण के लिए मजबूर हैं, असेंबली दोनों प्रदान करता है।

0

COM 32/64 बिट सीमाओं में मार्शलिंग और अनमर्शलिंग को संभालता है। हालांकि, यह वैकल्पिक प्रकार के बाइनरी को अपार्टमेंट के गलत पॉइंटरविड्थ में लोड करने के लिए कोई समर्थन प्रदान नहीं करता है।

कई असेंबली मूल कोड पर भरोसा करते हैं (अधिकांश SQL ड्राइवर उदाहरण के लिए सी या सी ++ में लिखे गए हैं)। यह पी/invoke का उपयोग कर कुछ भी के लिए अविश्वसनीय रूप से स्पष्ट है; इस प्रकार, संकलित और वितरित विभिन्न पॉइंटरविड्थ होने का मतलब है कि 64-बिट संस्करण के लिए पैकेज में 64-बिट देशी डीएलएल होते हैं, और 32-बिट संस्करण में 32-बिट देशी डीएलएल होते हैं। यह मामला तब भी है जब असेंबली के 32 और 64 बिट संस्करण एक ही कोड से संकलित किए जाते हैं।

सीएससी देशी (प्री-जिटेड) छवियों का उत्पादन करेगा यदि आप इसे पूछें।

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