एमएस इंस्टॉलर/विक्स

Question

में निर्भरता मैं वर्तमान में वाईएक्स और विंडोज इंस्टालर की अनियमितताओं को सीख रहा हूं और मैंने एक ठोकर खाई है।

परियोजना जो मैं वर्तमान में पैकेजिंग कर रहा हूं वह छह अलग-अलग हिस्सों से बना है। अभी के लिए उन्हें एक कॉल, बी, सी, डी, ई, एफ और

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

हिस्सा बी आम पुस्तकालयों और उपयोगिताओं कि यह अजीब लगता है हिस्सा ए द्वारा प्रदान की कार्यक्षमता की आवश्यकता का एक और सेट है, लेकिन वास्तुकला को प्रभावित करने या नियंत्रित करने के लिए अपनी क्षमता से परे है।

चंक सी सामान्य पुस्तकालयों और उपयोगिताओं का एक तीसरा सेट है जिसके लिए भाग ए और बी द्वारा प्रदान की गई कार्यक्षमता की आवश्यकता होती है। यह पहले से भी अधिक विषम लगता है, लेकिन मेरे पास अभी भी इसे बदलने की कोई क्षमता नहीं है।

चंक्स डी, ई, और एफ, सभी हिस्सा द्वारा प्रदान की कार्यक्षमता की आवश्यकता होती है ए, बी, और सी

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

मेरा तत्काल विचार ए, बी, और सी में घटकों के लिए मर्ज मॉड्यूल बनाना है, फिर उन्हें डी, ई, और एफ के लिए अलग इंस्टॉलर्स द्वारा प्रदान की गई सुविधाओं में संदर्भित करना है। यह फूट जाएगा इंस्टॉलर, लेकिन यह गारंटी होगी कि वें ई आवश्यक घटक स्थापित हैं। दुर्भाग्यवश, मुझे डर है कि यह अपग्रेड करते समय विंडोज इंस्टालर सत्यापन के अंदर समस्याएं पैदा करेगा।

एक और सोचा था कि मैं था कि ए, बी, और सी के लिए एक एकल संस्थापक बनाने के लिए और एक ComponentSearch के माध्यम से डी, ई, और एफ के लिए संस्थापक में यह आवश्यकता के लिए किया गया था।

क्या कोई विचार समझ में आता है? यदि कोई विचार समझ में नहीं आता है, तो क्या आपके पास ऐसा करने के सही तरीके के लिए कोई सिफारिश है?

Answer 1

प्रत्येक इंस्टॉलर के साथ ए + बी + सी शामिल करें, और सामान्य फ़ाइलों पर स्थापित करें। विंडोज इंस्टालर संदर्भ गिनती को संभालेगा ताकि डिस्क पर केवल एक प्रति मौजूद रहे और अंतिम उत्पाद हटा दिए जाने तक बने रहे। उन्नयन ठीक हो जाएगा, Windows इंस्टालर बात :)

हालांकि, बजाय मर्ज मॉड्यूल, मेरा सुझाव है की इस तरह प्रयोग करने के लिए डिज़ाइन किया गया है Wixlibs

Answer 2

मैं आश्वासन दिया गया है कि हिस्सा ए, बी, और सी स्थिर एपीआई रख सकेंगे ताकि वे डी की कार्यक्षमता, ई, enter code here या एफ

तोड़ने

एक चाकू के बिना उन्नत किया जा सकता है ले एपीआई पर्याप्त नहीं हो सकता है। क्या होगा यदि कोई एप्लिकेशन गलती से ऐसे व्यवहार पर निर्भर करता है जो एक अनियंत्रित संयोग (जैसे लौटाई गई सूची में वस्तुओं का क्रम), या बदतर, वास्तव में एक बग है जो व्यवहार पर निर्भर करता है? साझा किए गए घटकों का एक अपग्रेड तब आपके एप्लिकेशन को तोड़ सकता है क्योंकि इसे अपग्रेड किए गए घटकों के खिलाफ परीक्षण नहीं किया गया था।

मेरा तत्काल विचार मॉड्यूल मर्ज करना है ...मुझे डर है कि यह विंडोज के अंदर समस्याएं अपग्रेड करते समय इंस्टॉलर सत्यापन का कारण बन जाएगा।

आप सही हो सकते हैं कि मर्ज मॉड्यूल के साथ सेवाशीलता समस्याएं हैं। माइक्रोसॉफ्ट अब नए मर्ज मॉड्यूल वितरित नहीं करता है। अपग्रेड करने योग्य घटकों को बनाना भी बेहद मुश्किल है और अभी भी Windows Installer Component Rules का पालन करना मुश्किल है।

मैं वास्तव में प्रत्येक अनुप्रयोग की बिन फ़ोल्डर में "साझा" घटकों को अलग से स्थापित करने के लिए पसंद करते हैं। मैं इन घटकों के लिए wixlibs बना देता हूं, ताकि उन्हें एप्लिकेशन इंस्टॉलर्स के बीच साझा किया जा सके। Wixlib फ़ाइलों के अंदर, मैंने घटक को <DirectoryRef Id="SharedComponentFolder> में रखा है। यह निर्देशिका संदर्भ अपरिभाषित छोड़ दिया गया है, जो lit.exe के लिए कोई समस्या नहीं है। एप्लिकेशन इंस्टॉलर में, मैं तो इस तरह आवेदन बिन फ़ोल्डर उर्फ:

<Directory Id="AppBinFolder" Name="bin"> 
    <Directory Id="SharedComponent1Folder" /> <!-- alias for AppBinFolder --> 
    <Directory Id="SharedComponent2Folder" /> <!-- another alias --> 
</Directory> 

नतीजतन, अनुप्रयोगों उनकी निर्भरता को अपने स्वयं के बिन फ़ोल्डर में है और दूसरे से अलग रहते हैं। वहाँ निश्चित रूप से एक व्यापार बंद है:

• आप स्थिरता हासिल आपका आवेदन हमेशा निर्भरता इसके खिलाफ परीक्षण किया जाता है की सही संस्करण के खिलाफ चलाता है; कोई DLL Hell मुद्दे।
• आपके पास साझा किया गया घटक साझा होने पर अधिक काम होता है; प्रत्येक एप्लिकेशन इंस्टॉलर को साझा घटक के लिए केवल एक इंस्टॉलर के बजाय अद्यतन और पुनर्वितरित होना आवश्यक है।
• आप डिस्क स्थान खो (क्योंकि साझा घटक इंस्टॉल नहीं हैं कई बार)।

.NET विधानसभाओं के साथ

, कहानी और भी अधिक GAC, strong names, policy file redirects आदि के साथ जटिल हो सकता है लेकिन इस पोस्ट के पहले से ही बहुत लंबा :-)