एक ही समाधान/प्रोजेक्ट

Question

में विजुअल स्टूडियो के साथ 32 बिट और 64 बिट दोनों को लक्षित करना मुझे बहु-लक्ष्यीकरण के लिए मेरे विजुअल स्टूडियो बिल्ड को सेट करने के तरीके पर थोड़ा दुविधा है।

पृष्ठभूमि: सी # .NET v2.0 पी/पीडी के साथ तीसरे पक्ष 32 बिट डीएलएल, एसक्यूएल कॉम्पैक्ट v3.5 SP1, एक सेटअप प्रोजेक्ट के साथ। अभी, प्लेटफ़ॉर्म लक्ष्य x86 पर सेट है, इसलिए इसे Windows x64 पर चलाया जा सकता है।

तृतीय पक्ष कंपनी ने अभी अपने डीएलएल के 64 बिट संस्करण जारी किए हैं और मैं एक समर्पित 64 बिट प्रोग्राम बनाना चाहता हूं।

यह कुछ प्रश्न उठाता है जिन्हें मुझे अभी तक जवाब नहीं मिला है। मैं सटीक कोड आधार रखना चाहता हूं। मुझे डीएलएल या 64 बिट डीएलएल के 32 बिट सेट के संदर्भों के साथ निर्माण करना होगा। (दोनों तृतीय पक्ष और SQL सर्वर कॉम्पैक्ट)

क्या इसे कॉन्फ़िगरेशन के 2 नए सेट (डीबग 64 और रिलीज़ 64) के साथ हल किया जा सकता है?

क्या मुझे 2 अलग-अलग सेटअप प्रोजेक्ट (std। विजुअल स्टूडियो प्रोजेक्ट्स, नो विक्स या कोई अन्य उपयोगिता) बनाना चाहिए, या इसे उसी .msi में हल किया जा सकता है?

किसी भी विचार और/या सिफारिशों का स्वागत किया जाएगा।

Answer 1

हाँ, आप दोनों x86 और एक ही परियोजना में एक ही कोड आधार के साथ 64 लक्षित कर सकते हैं। आम तौर पर, यदि आप VS.NET में सही समाधान कॉन्फ़िगरेशन बनाते हैं तो चीजें बस काम करेंगी (हालांकि पी/पूरी तरह से अप्रबंधित डीएलएल के लिए आमंत्रित करने की संभावना अधिकतर सशर्त कोड की आवश्यकता होगी): जिन वस्तुओं को मुझे विशेष ध्यान देने की आवश्यकता है, वे हैं:

• एक ही नाम है, लेकिन अपनी विशिष्ट bitness साथ बाहर प्रबंधित विधानसभाओं के संदर्भ (यह भी COM इंटरॉप असेंबलियों के लिए लागू होता है)
• MSI पैकेज (जो, के रूप में पहले से ही उल्लेख किया गया है, या तो 86 या 64 को लक्षित करने की आवश्यकता होगी)
• आपके एमएसआई पैकेज में कोई कस्टम .NET इंस्टॉलर क्लास-आधारित क्रिया

असेंबली संदर्भ समस्या पूरी तरह से VS.NET के भीतर हल नहीं की जा सकती है, क्योंकि यह आपको एक बार किसी दिए गए नाम के साथ संदर्भ जोड़ने की अनुमति देगा। इसके आसपास काम करने के लिए, अपनी प्रोजेक्ट फ़ाइल को मैन्युअल रूप से संपादित करें (वीएस में, समाधान एक्सप्लोरर में अपनी प्रोजेक्ट फ़ाइल पर राइट-क्लिक करें, अनलोड प्रोजेक्ट का चयन करें, फिर राइट-क्लिक करें और संपादित करें का चयन करें)।

<Reference Include="Filename, ..., processorArchitecture=x86"> 
    <HintPath>C:\path\to\x86\DLL</HintPath> 
</Reference> 

लपेटें कि एक ItemGroup टैग के अंदर टैग संदर्भ समाधान विन्यास यह लागू होता है यह दर्शाता है, जैसे::

करने के लिए, कहते हैं, एक विधानसभा का x86 संस्करण के लिए एक संदर्भ जोड़ने के बाद, अपनी परियोजना फ़ाइल की तरह कुछ में शामिल होंगे

<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' "> 
    <Reference ...>....</Reference> 
</ItemGroup> 

फिर, कॉपी और पूरे ItemGroup टैग पेस्ट, और इसे संपादित अपने 64-बिट DLL के विवरण, जैसे को रोकने के लिए:

<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' "> 
    <Reference Include="Filename, ..., processorArchitecture=AMD64"> 
    <HintPath>C:\path\to\x64\DLL</HintPath> 
    </Reference> 
</ItemGroup> 

अपने proje पुन: लोड करने के बाद वीएस.नेट में सीटी, विधानसभा संदर्भ संवाद इन परिवर्तनों से थोड़ा उलझन में होगा, और आपको गलत लक्ष्य प्रोसेसर के साथ असेंबली के बारे में कुछ चेतावनियां मिल सकती हैं, लेकिन आपके सभी बिल्ड ठीक काम करेंगे।

एमएसआई मुद्दे को सुलझाने के बगल में है, और दुर्भाग्य से इस एक non-VS.NET उपकरण की आवश्यकता होगी: मैं पसंद Caphyon के Advanced Installer उस उद्देश्य के लिए, के रूप में के रूप में यह बुनियादी चाल शामिल (एक आम एमएसआई बनाने खींचती 32-बिट और 64-बिट विशिष्ट एमएसआई के साथ-साथ, सही संस्करण निकालने के लिए .EXE सेटअप लॉन्चर का उपयोग करें और रनटाइम पर आवश्यक फ़िक्सअप करें) बहुत, बहुत अच्छी तरह से।

आप शायद ही परिणाम अन्य उपकरण या Windows Installer XML (WiX) toolset का उपयोग कर प्राप्त कर सकते हैं, लेकिन उन्नत इंस्टालर चीजें इतनी आसान बना देता है (और है कि कम से काफी सस्ती है) कि मैं वास्तव में विकल्प पर कभी नहीं देखा है।

एक चीज आपको को अभी भी वाईएक्स की आवश्यकता है, भले ही उन्नत इंस्टॉलर का उपयोग करते समय भी आपके .NET इंस्टॉलर क्लास कस्टम क्रियाओं के लिए हो।यद्यपि यह कुछ क्रियाओं को निर्दिष्ट करने के लिए तुच्छ है जो केवल कुछ प्लेटफॉर्म पर चलाना चाहिए (क्रमशः संस्करणNT64 और संस्करण संस्करण 64 निष्पादन शर्तों का उपयोग करके), अंतर्निहित एआई कस्टम क्रियाएं 32-बिट फ्रेमवर्क का उपयोग करके निष्पादित की जाएंगी, यहां तक ​​कि 64-बिट मशीनों पर भी ।

इसे भविष्य में रिलीज में ठीक किया जा सकता है, लेकिन अभी के लिए (या जब आपके एमएसआई को एक ही समस्या है तो एक अलग टूल का उपयोग करते समय), आप एक्शन डीएलएल बनाने के लिए वाईएक्स 3.0 के प्रबंधित कस्टम एक्शन सपोर्ट का उपयोग कर सकते हैं उचित फ्रेमवर्क जो इसी फ्रेमवर्क का उपयोग करके निष्पादित किया जाएगा।

---

संपादित करें: संस्करण 8.1.2 के रूप में, उन्नत इंस्टॉलर 64-बिट कस्टम क्रियाओं का सही ढंग से समर्थन करता है। मेरी मूल जवाब के बाद से, इसकी कीमत काफ़ी, दुर्भाग्य से, भले ही यह अभी भी बहुत अच्छा मूल्य है जब InstallShield और उसके जैसे लोग की तुलना में बढ़ गया है ...

---

संपादित करें: अपने DLLs GAC में पंजीकृत हैं, तो आप भी मानक संदर्भ टैग इस तरह से (एक उदाहरण के रूप SQLite) का उपयोग कर सकते हैं:

<ItemGroup Condition="'$(Platform)' == 'x86'"> 
    <Reference Include="System.Data.SQLite, Version=1.0.80.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=x86" /> 
</ItemGroup> 
<ItemGroup Condition="'$(Platform)' == 'x64'"> 
    <Reference Include="System.Data.SQLite, Version=1.0.80.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=AMD64" /> 
</ItemGroup> 

हालत भी सभी के लिए नीचे कम हो जाता है प्रकार, रिहाई या डिबग निर्माण, और सिर्फ प्रोसेसर आर्किटेक्चर निर्दिष्ट करता है।

Answer 2

अपने प्रश्न के कुल उत्तर के बारे में सुनिश्चित नहीं है - लेकिन सोचा कि मैं SQL Compact 3.5 SP1 download page के अतिरिक्त सूचना अनुभाग में एक टिप्पणी इंगित करता हूं कि आप x64 देख रहे हैं - उम्मीद है कि इससे मदद मिलती है।

एसक्यूएल सर्वर कॉम्पैक्ट SP1 में परिवर्तन और अतिरिक्त 64-बिट संस्करण समर्थन, केन्द्र स्थापित किया है और मिश्रित मोड वातावरण एसक्यूएल सर्वर कॉम्पैक्ट 3.5 और 64-बिट एसक्यूएल के संस्करण के 32-बिट संस्करण के कारण सर्वर कॉम्पैक्ट 3.5 एसपी 1 इंटरमीटेंट समस्याओं के रूप में दिखाई दे सकता है। संघर्ष के लिए संभावित कम करने के लिए, और भी Windows इंस्टालर (MSI) फ़ाइल का उपयोग एसक्यूएल सर्वर कॉम्पैक्ट 3.5 एसपी 1 के 64-बिट संस्करण को स्थापित करने में कामयाब रहे क्लाइंट अनुप्रयोग के मंच तटस्थ तैनाती सक्षम करने के लिए, केन्द्र स्थापित करने की आवश्यकता है एसक्यूएल सर्वर कॉम्पैक्ट 3.5 एसपी 1 एमएसआई फ़ाइल के 32-बिट संस्करण । उन अनुप्रयोगों के लिए जो केवल को देशी 64-बिट की आवश्यकता होती है, निजी के 64-बिट संस्करण की तैनाती SQL सर्वर कॉम्पैक्ट 3.5 एसपी 1 उपयोग किया जा सकता है।

मैं इस पढ़ने के रूप में "32 बिट SQLCE फ़ाइलों के साथ-साथ 64 बिट फ़ाइलों में शामिल हैं," अगर 64 बिट ग्राहकों के लिए वितरण।

मुझे लगता है कि जीवन दिलचस्प दिलचस्प लगता है .. मुझे कहना होगा कि मुझे "अस्थायी समस्याएं दिखाई देती हैं" लाइन से प्यार है ... थोड़ा सा लगता है जैसे "आप चीजों की कल्पना कर रहे हैं, लेकिन बस मामले में, ऐसा करें ..."

Answer 3

आपके अंतिम प्रश्न के बारे में। सबसे अधिक संभावना है कि आप इसे एक एकल एमएसआई के अंदर हल नहीं कर सकते हैं। यदि आप रजिस्ट्री/सिस्टम फ़ोल्डर्स या संबंधित किसी भी चीज का उपयोग कर रहे हैं, तो एमएसआई को इसके बारे में अवगत होना चाहिए और आपको 32 बिट मशीन पर ठीक से स्थापित करने के लिए 64 बिट एमएसआई तैयार करना होगा।

ऐसी संभावना है कि आप इसे 32 एप्लिकेशन के रूप में उत्पाद स्थापित कर सकें और फिर भी इसे 64 बिट के रूप में चलाने में सक्षम हो, लेकिन मुझे लगता है कि यह हासिल करने में कुछ मुश्किल हो सकती है।

कहा जा रहा है कि मुझे लगता है कि आप सब कुछ के लिए एक कोड आधार रखने में सक्षम होना चाहिए। मेरे वर्तमान कार्यस्थल में हमने ऐसा करने में कामयाब रहे हैं। (लेकिन यह सब कुछ एक साथ खेलने के लिए कुछ जुगलिंग ले लिया)

उम्मीद है कि इससे मदद मिलती है। Heres कुछ 32/64 बिट के मुद्दों से संबंधित जानकारी के लिए एक लिंक: http://blog.typemock.com/2008/07/registry-on-windows-64-bit-double-your.html

Answer 4

मान लीजिए कि आप है DLLs दोनों प्लेटफार्मों के लिए निर्माण, और वे निम्न स्थान पर हैं दो:

<HintPath>C:\whatever\x86\whatever.dll</HintPath> 

करने के लिए:

C:\whatever\x86\whatever.dll 
C:\whatever\x64\whatever.dll 

आप बस इस से अपने .csproj फ़ाइल संपादित करने की जरूरत यह:

<HintPath>C:\whatever\$(Platform)\whatever.dll</HintPath> 

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

Answer 5

यदि आप अपने एमएसआई इंस्टॉलर के हिस्से के रूप में .NET में लिखित कस्टम क्रियाओं का उपयोग करते हैं तो आपको एक और समस्या है।

इन कस्टम कार्यों को चलाने वाला 'शिम' हमेशा 32 बिट होता है, तो आपके द्वारा निर्दिष्ट लक्ष्य के बावजूद आपकी कस्टम कार्रवाई 32 बिट भी चलती है।

अधिक जानकारी & कुछ निंजा के आसपास मिलता है (मूल रूप से एमएसआई बदलने इस शिम का 64 बिट संस्करण का उपयोग करने के)

Building an MSI in Visual Studio 2005/2008 to work on a SharePoint 64

64-bit Managed Custom Actions with Visual Studio

Answer 6

आप अलग दो समाधान पैदा करते हैं और मर्ज कर सकते हैं करने के लिए ले जाता है बाद में उन्हें! मैंने इसे वीएस 2010 के लिए किया था। और यह काम करता है। मेरे पास सीएमके द्वारा उत्पन्न 2 अलग-अलग समाधान थे और मैंने उन्हें

Answer 7

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

उदाहरण:

<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' "> 
    <Reference Include="DLLName"> 
     <HintPath>..\DLLName.dll</HintPath> 
    </Reference> 
    <ProjectReference Include="..\MyOtherProject.vcxproj"> 
     <Project>{AAAAAA-000000-BBBB-CCCC-TTTTTTTTTT}</Project> 
     <Name>MyOtherProject</Name> 
    </ProjectReference> 
    </ItemGroup>