Wix इंस्टॉलर: कमांड लाइन पर MSIEXEC एडमिन इंस्टॉल करते समय कंपोनेंट कंडीशन प्रॉपर्टी सेट करना




windows-installer conditional-statements (2)

आपका पूर्व-प्रोसेसर उपयोग

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

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

फ्लेवर सेट करें

जब मैं अलग सेटअप फ्लेवर या उत्पाद संस्करण बनाने की आवश्यकता होती है, तो मैं जो सामान्य तकनीकी दृष्टिकोण का उपयोग करता हूं, वे इस प्रकार हैं:

  1. प्रीप्रोसेसर निर्माण : एमएसआई के विभिन्न स्वादों या संस्करणों (अलग-अलग भाषा के संस्करणों) का संकलन करने के लिए उपयोग किया जाता है। ऐसा ही एक निर्माण है ?if? आप उल्लेख कर रहे हैं। कई अन्य भी हैं, जैसा कि ऊपर दिए गए लिंक में देखा गया है। आपके लिए प्रासंगिक व्यक्ति सशर्त कथन होंगे ( if , ifdef , ifndef , else , ifndef , ifndef ) और संभवत: include वक्तव्य include

    • तो समग्र संदेश यह है कि प्रीप्रोसेसर निर्माण आपको MSI फ़ाइलों के कई अलग-अलग स्वादों को एक एकल वाईएक्स एक्सएमएल स्रोत से बनाने की अनुमति देता है

    • आपके मामले में यह एक एकल वाईएक्स एक्सएमएल स्रोत और तीन एमएसआई फाइलें प्राप्त करेगा - प्रत्येक आवेदन के एक अलग संस्करण के लिए। सभी समान, लेकिन केवल उन घटकों के साथ जिनकी उन्हें आवश्यकता है।

    • /i या एडमिनिस्ट्रेटिव इमेज (फाइल एक्सट्रेक्ट) के माध्यम से इंस्टॉलेशन रन करना /a आपके द्वारा उस सेटअप फ्लेवर में जोड़े गए कंपोनेंट्स को ही प्राप्त करेगा, लेकिन आपके पास एक भी MSI नहीं है जैसा कि आप कहते हैं - लेकिन तीन अलग-अलग लोगों के आधार पर कि आपने कैसे संकलित किया।

    • मैं उपयोग करना पसंद करता हूं ?include? केवल स्थिति घटकों के बजाय वाईएक्स टुकड़े फ़ाइलों को शामिल करने के लिए बयान ?if? जैसा कि आप उल्लेख करते हैं। " प्रीप्रोसेसर कंस्ट्रक्शंस " अनुभाग में नीचे अंतर का एक नमूना है।

  2. MSI फीचर्स (जैसा कि PhilDW ने उत्तर दिया है) : आप अलग-अलग फ्लेवर में सिंगल सेटअप देने के लिए MSI फीचर्स पर भी भरोसा कर सकते हैं। सुविधाओं का उपयोग MSI को विभिन्न उपयोगकर्ता-चयन करने योग्य इंस्टॉलेशन आइटम (जिनमें से कुछ आप अनिवार्य कर सकते हैं) में अलग करने के लिए किया जाता है।

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

      • उपयोगकर्ता सुविधा नियंत्रण

        • उपयोगकर्ता सेटअप के फ़ीचरट्री डायलॉग के माध्यम से अंतःक्रियात्मक रूप से इंस्टॉल करने के लिए सुविधाओं को नियंत्रित कर सकते हैं (अधिकांश नहीं)। आमतौर पर इसमें "कस्टम" इंस्टॉलेशन करना शामिल होता है।

        • आप ADDLOCAL प्रॉपर्टी और REMOVE प्रॉपर्टी (और संभवतः अन्य, समान गुण - विवरणों के लिए लिंक देखें) का उपयोग करके इंस्टॉलेशन को लात मारते हुए कमांड लाइन के माध्यम से सेटअप में स्थापित करने के लिए क्या सुविधाएँ निर्दिष्ट कर सकते हैं।

        • कभी-कभी आप स्थापना के दौरान एक कस्टम संपत्ति सेट कर सकते हैं जो निर्दिष्ट "संस्करण" के आधार पर मानक सुविधाओं के एक तारामंडल को ट्रिगर करेगा, जो हमें अगले बिंदु पर लाता है।

      • प्रोग्रामेटिक सुविधा नियंत्रण

        • प्रोग्रामेटिक फीचर कंट्रोल पर एक उत्तर के लिए एक लिंक जोड़ना: कस्टम एक्शन में सेट की गई संपत्ति के आधार पर फीचर कैसे इंस्टॉल करें?

        • जैसा कि कहा गया है, आप कमांड लाइन के माध्यम से ADDLOCAL संपत्ति और सेटअप के अंदर REMOVE प्रॉपर्टी का उपयोग करके चलाए जाने के दौरान कौन-सी सुविधाओं को जोड़ सकते हैं ऐसा करने के लिए आप एक कस्टम क्रिया का उपयोग कर सकते हैं

        • इसमें एक INSTALLLEVEL संपत्ति भी है जो सुविधाओं की स्थापना स्थिति के लिए प्रासंगिक है। प्रत्येक सुविधा के लिए एक इंस्टॉल स्तर है, और यह स्थिति तालिका में निर्धारित शर्तों से प्रभावित हो सकता है।

          • तो हालत तालिका का उपयोग सशर्त अभिव्यक्ति के आधार पर फ़ीचर तालिका में किसी भी प्रविष्टि की चयन स्थिति को संशोधित करने के लिए किया जा सकता है।

          • दूसरे शब्दों में आप इसका उपयोग सुविधाओं को सेट करने के लिए कर सकते हैं या शर्त के आधार पर डिफ़ॉल्ट रूप से स्थापित नहीं कर सकते हैं।

        • INSTALLLEVEL अवधारणा के अलावा, आप सुविधा चयन स्थिति को नियंत्रित करने के लिए कस्टम क्रियाओं का भी उपयोग कर सकते हैं।

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

        • आपका सेटअप यह भी निर्धारित कर सकता है कि आपके द्वारा चलाए जा रहे ओएस के आधार पर एक निश्चित सुविधा को स्थापित नहीं किया जाना चाहिए (उदाहरण के लिए, Tablet OS सुविधाओं को स्थापित न करें)।

        • प्रोग्राम चयन सुविधा को बदलने के लिए तकनीकी और व्यावहारिक कारणों में से कोई भी संख्या हो सकती है।

    • यह ध्यान रखना महत्वपूर्ण है कि समग्र परिणाम यह है कि सुविधा का चयन कमांड लाइन के माध्यम से या उपयोगकर्ता द्वारा सेट किया जा सकता है, और फिर आपका सेटअप तकनीकी कारणों से कुछ "हूड" संशोधनों के तहत बनाता है।

    • और बस इसे इंगित करने के लिए: प्रोग्राम को इंस्टॉलेशन के लिए जोड़-तोड़ करने वाली विशेषताओं को आमतौर पर दृश्य से छिपाया जाता है (लेकिन फिर भी कमांड लाइन के माध्यम से ओवरराइड करना संभव है - जो एक समस्या हो सकती है)।

    • यहां स्थापना के लिए सुविधाओं, घटकों और सेटअप के अनुकूलन पर अधिक: MSI फ़ाइलों का बेहतर उपयोग कैसे करें

  3. Setup.exe लांचर : अलग-अलग स्वादों में जटिल तैनाती करने का एक "आधुनिक" तरीका एक अलग इंस्टॉलेशन स्थिति प्राप्त करने के लिए विभिन्न "सेट" में स्थापित छोटे MSI सेटअपों को संकलित करने के लिए WiX की बर्न सुविधा का उपयोग किया जा सकता है।

    • मुझे यह सामान्य उपयोग के लिए बहुत जटिल लगता है, लेकिन यह निश्चित रूप से संभव है। मुझे लगता है कि कुछ को यह आसान लगता है, क्योंकि कम फीचर हेरफेर है। शायद मुझे इसके साथ अनुभव की कमी है।
    • लाभ छोटी MSI फ़ाइलें हैं जो जल्दी स्थापित होती हैं, और आप एक एकल MSI फ़ाइल को अपडेट कर सकते हैं और एक नया setup.exe आवरण बना सकते हैं और फिर सभी सेटअपों को फिर से बनाए बिना आपके संपूर्ण समाधान पर कुल QA कर सकते हैं।
    • मेरी दुनिया में एकल, अपडेटेड MSI के लिए वैसे भी पूर्ण QA की आवश्यकता होती है, इसलिए मैं हमेशा इन "सरलता के तर्कों" को स्वयं नहीं खरीद रहा हूं। प्रत्येक रिलीज़ चक्र में जोखिम होते हैं, और इसलिए कुल जोखिम में जुड़ जाता है । हालांकि, यह एक छोटे से सेटअप के पुनर्निर्माण और अपने बड़े को स्थिर रखने में सक्षम होने के लिए महान हो सकता है।

प्रायोगिक उपयोग

मैं संभव के रूप में कुछ सेटअप फ़्लेवर बनाना पसंद करता हूं , लेकिन ज्यादातर समय मैं प्रीप्रोसेसर निर्माण का उपयोग करके अलग- अलग भाषा संस्करणों (अंग्रेजी, जर्मन, रूसी) और विभिन्न उत्पाद संस्करणों (एंटरप्राइज़, प्रोफेशनल, स्टैंडर्ड) के लिए अलग- अलग सेटअप बनाने के लिए उपयोग करता हूं। । मैं आमतौर पर उन सभी संबंधित साझाकरणों को एक उन्नयन कोड सेट करता हूं और साइड-बाय-साइड इंस्टॉल करने में सक्षम नहीं होता।

मुझे लगता है कि एक एकल एमएसआई को अधिक क्यूए संसाधन मिलते हैं और इसलिए इसका बेहतर परीक्षण किया जाएगा। हालाँकि, यह एकल MSI दृष्टिकोण आमतौर पर टूट जाता है यदि सेटअप बहुत बड़े होते हैं - जिस स्थिति में मैं उन्हें विभाजित करना पसंद करता हूं। मैं व्यापार के लिए प्रत्येक भाषा के लिए अलग-अलग सेटअप बनाना पसंद करता हूं- और वास्तविक विश्व व्यावहारिक कारणों को यहां समझाया गया है । व्यावहारिक और कानूनी आवश्यकताएं (लाइसेंसिंग) भी समान MSI सेटअप के विशेष संस्करणों को संकलित करने के लिए अनिवार्य बना सकती हैं। मुझे OEM विक्रेताओं के लिए नए MSI जायके बनाने के लिए भी कहा गया है।

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

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

वास्तविकता में वापस : वास्तविक तैनाती के लिए आपको अनियमित वर्जनिंग स्कीम वाली फाइलों का एक गुच्छा मिलेगा, जो आपको धीमे नेटवर्क शेयर के माध्यम से एक डेवलपर से असंगत निर्देशों के एक समूह के साथ दिया जाएगा, जो ऑफशोर और प्रति घंटा भुगतान किया जाता है (आप सुनिश्चित कर सकते हैं कि वह दर्द महसूस करता है भी :-))। और उनके पास आपके कम-से-आदर्श डिजाइन को कवर करने के लिए जादू करने के लिए आंशिक रूप से पागल आवश्यकताओं का एक गुच्छा होगा (जो कि वे बनाने के लिए भुगतान किया गया था)। यह एक शेख़ी नहीं है, यह वास्तविकता है - कहने के लिए दुखद ( ठीक है, यह एक शेख़ी है )। तैनाती कम त्रुटि वाला बनाने के लिए हमें एक एप्लिकेशन के समग्र डिजाइन को बेहतर बनाने के लिए काम करना चाहिए। जादू वास्तव में एक सेटअप में किया जा सकता है, लेकिन यह तैनाती की अपरिहार्य और अनियंत्रित जटिलता के कारण तैनाती के लिए उच्च त्रुटि प्रतिशत को ट्रिगर करेगा (सबसे महत्वपूर्ण: 1) त्रुटियां संचयी हैं - प्रत्येक रिलीज़ आपके स्थापना की गतिशीलता को तोड़ने के लिए जोखिम और अवसर जोड़ता है (कभी-कभी आपको सब कुछ वापस खींचना पड़ता है और शुरू करना पड़ता है - बड़ी लागत पर), 2) लक्ष्य प्रणाली बेहद विविध और अप्रत्याशित अवस्थाओं (किसी भी राज्य, किसी भी भाषा, किसी भी ओएस संस्करण, किसी भी हार्डवेयर, किसी भी मैलवेयर, आदि ...) में होती है। , 3) डिबगिंग बहुत मुश्किल है जब आपके पास समस्या प्रणाली तक पहुंच नहीं होती है अंतःक्रियात्मक - अधिक विवरण के लिए लिंक किए गए उत्तर के नीचे की ओर देखें। और मैं 2 4th issue से बाहर होने वाले 4th issue जोड़ूंगा: क्या आप मैलवेयर से भरी मशीन चोक पर तैनाती की गारंटी दे सकते हैं? ऐसी प्रणालियों को समर्थन और डिबग करना असंभव है - बस एक महत्वपूर्ण समस्या का पता लगाने के लिए अपनी पिक लें जिसे आप ठीक नहीं कर सकते हैं। यदि आपका पैकेज ऐसे मैलवेयर सिस्टम पर विफल रहता है, तो यह एक प्राकृतिक त्रुटि प्रतिशत है जो अपरिहार्य है

समग्र बिंदु स्पष्ट है: हम इन अज्ञात के लिए - कचरा में, कचरा बाहर (यह कैसे लगता है के लिए माफी के साथ) के लिए जिम्मेदार नहीं है - एक त्रुटि प्रतिशत हो जाएगा - हर बार जब आप तैनात - यहां तक ​​कि सही संकुल के लिए । सभी उपलब्ध और हमेशा मूल्यवान क्यूए-दोस्तों को पकड़ना सुनिश्चित करें और उन्हें सेटअप परीक्षण के बारे में सिखाएं (सभी इंस्टॉलेशन मोड्स का परीक्षण करना, अन्य अनुप्रयोगों के साथ अनइंस्टॉल और इंटरैक्शन का परीक्षण करना, वास्तविक दुनिया के अपग्रेड परिदृश्यों का परीक्षण करना, विशिष्ट उन्नत सेटअप विशेषताओं का परीक्षण करना जैसे लाइसेंस चेक करना, आदि। ...)। उन सभी सहायता प्राप्त करें जो आप प्राप्त कर सकते हैं और उनके योगदान को महत्व दे सकते हैं। अगर और कुछ नहीं, के रूप में :-)। गंभीरता से: उपलब्ध क्यूए-संसाधनों का प्रभावी ढंग से उपयोग करने और तैनाती परीक्षण में उन्हें प्रशिक्षित करने में विफल रहने के कारण मेरी सूची में एक रिलीज मैनेजर और सेटअप डेवलपर के रूप में मेरी सबसे बड़ी उपेक्षा है। यह एक सुरक्षित धारणा है कि आप कुछ ही समय में अपने क्यूए-होरेल्का की एक बोतल - या ग्रीन टी या रूइबोस चाय - के कारण आप दुनिया में कहाँ हैं पर निर्भर हैं।

प्री-प्रोसेसर कंस्ट्रक्शंस

मैं शायद प्रीप्रोसेसर निर्माण का उपयोग करूंगा ?if? और ?include? अपने परिभाषित संस्करण के आधार पर वाईएक्स एक्सएमएल स्रोत कोड / मार्कअप के विभिन्न वर्गों को चुनिंदा रूप से ?define? नमूने के शीर्ष पर वक्तव्य:

<?define EditionType = LITE ?>

<!-- You can put your edition-specific components in an include file  -->
  <?if $(var.EditionType) = "200" ?> 
    <?include "200Features.wxi" ?>
  <?endif ?>
  <?if $(var.EditionType) = "LITE" ?>
    <?include "LiteFeatures.wxi" ?>
  <?endif ?>

फ़ाइलों को शामिल करने के बजाय, आप इस इनलाइन को अपने मुख्य स्रोत में भी कर सकते हैं (यह वही हो सकता है जो आपने किया है):

 <?if $(var.EditionType) = "200" ?> 
    <Component>
       <File Source="$(var.MenusPath)\ClientListView 200.r5m" /> 
    </Component>
<?endif?>
<?if $(var.EditionType) = "LITE" ?>
    <Component>
       <File Source="$(var.MenusPath)\ClientListView Lite.r5m" />
    </Component>    
<?endif?>

उपरोक्त विकल्पों में से, मैं संस्करण-विशिष्ट घटकों को एक अलग शामिल फ़ाइल (पहला विकल्प) में रखना पसंद करूंगा - फिर आपके वाईएक्स स्रोत में कम "लाइन शोर" है (प्रीप्रोसेसर निर्माणों की कम पुनरावृत्ति)।

शामिल फाइलें मूल रूप से सिर्फ वाईएक्स एक्सएमएल फाइलें हैं, जो संकलन समय पर मूल वाईएक्स एक्सएमएल फाइल में सी ++ हेडर फाइलों की तरह ही शामिल हैं। जैसे फिल कहते हैं कि मैं अलग-अलग संस्करणों के लिए अलग-अलग फीचर नामों का उपयोग करता हूं, इसलिए आप 200Features में 200Features फ़ीचर को एक फ़ीचर परिभाषित करते हैं, जिसमें फ़ाइल शामिल है, लेकिन आपको सुविधाओं का उपयोग करने की आवश्यकता नहीं है - हालांकि दृढ़ता से प्रोत्साहित किया जाता है।

इसके अलावा टुकड़ा तत्व के वाईएक्स अवधारणा के बारे में पता होना चाहिए। मूल रूप से वाईएक्स स्रोत फ़ाइल में सामग्री को पार करने का एक तरीका है। एक उदाहरण यहाँ

मुझे यह उल्लेख करना चाहिए कि एमएसआई में मर्ज मॉड्यूल की मूल अवधारणा विभिन्न सेटअपों के बीच घटकों को साझा करने का एक अलग तरीका प्रदान करती है, लेकिन मुझे शामिल फ़ाइल दृष्टिकोण बेहतर है। मर्ज मॉड्यूल किसी तरह COM ऑब्जेक्ट्स की तरह महसूस करते हैं (बाइनरी ब्लॉब को एक पूर्ण संस्करण के रूप में शामिल किया गया है), जबकि फ़ाइलें शामिल हैं और अधिक गतिशील लगती हैं कि आप बिना किसी मर्ज मॉड्यूल पुनर्निर्माण और संस्करण के बिना हर बिल्ड के लिए लिंक की गई नवीनतम फाइलें प्राप्त करें। कुछ लोग निस्संदेह इसे बहुत गलत पाएंगे।

हमारे पास हमारे उत्पाद के तीन प्रकार / स्वाद हैं, लेकिन केवल एक MSI है जो वाईएक्स में लिखा गया है। जब हम इंस्टॉलर का निर्माण करते हैं तो हम स्वाद में एक परिभाषित स्थिरांक से गुजरते हैं:

Call MSBUILD.bat ..\MSIs\CoreProduct\OurProduct.sln /p:DefineConstants="FLAVOUR=%_Flavour%"

और निरंतर दृश्य स्टूडियो में सेटअप है, बिल्ड -> FLAVOR = 50 के रूप में प्रीप्रोसेसर चर को परिभाषित करें। निर्माण प्रक्रिया, स्वाद के रूप में मान 50, 200 या LITE में गुजरती है।

वाईएक्स कोड में हमारे घटकों पर परिस्थितियों का भार है जो यह बताता है कि स्वाद के आधार पर कौन सी फ़ाइल स्थापित करनी है; जैसे

      <Component Id="cmp7F45920B1AA100729BAE37FC846B3FC5" Guid="*">
    <File Id="fil238A776D9294E14671E012472F9F7196"
          KeyPath="yes"
          Source="$(var.MenusPath)\ClientListView 200.r5m"  
    <Condition>$(var.FLAVOUR)=200</Condition>
  </Component>

      <Component Id="cmp8BFF42B232724DC4BA5B8F87994DEF21" Guid="*">
    <File Id="fil808D6428D67248DDB8CA65DBC5978283" 
          KeyPath="yes" 
          Source="$(var.MenusPath)\ClientListView Lite.r5m"
    <Condition>$(var.FLAVOUR)=LITE</Condition>
  </Component>

तो ऊपर दिया गया उदाहरण "ClientListView Lite.r5m" नामक एक फ़ाइल स्थापित करेगा यदि FLAVOR LITE है या यह "ClientListView 200.r5m" नामक एक फ़ाइल स्थापित करेगा यदि FLAVOR 200 है।

यह सब उम्मीद के अनुसार काम करता है और सालों से किया है !!

लेकिन अब, हमारे पास हमारे उत्पाद का एक वेब संस्करण है और हमें फ़ोल्डर की संरचना और प्रत्येक स्वाद के लिए स्थापित की जाने वाली फ़ाइलों को शामिल करने के लिए एक ज़िप फ़ाइल की आवश्यकता है। मुझे पता चला कि आप MSIEXEC और / एक तर्क का उपयोग करके कमांड लाइन पर एक msi चला सकते हैं जो तब सब कुछ पुनर्निर्देशित कर देगा जो एक फ़ोल्डर में स्थापित किया गया होगा और सोचा कि यह वही है जो मैं चाहता हूं ... लेकिन अफसोस यह काम नहीं कर रहा है जैसा कि मैं उम्मीद है

ऐसा लगता है कि एमएसआई चल रहा है और फ़ाइलों को लक्ष्य फ़ोल्डर में निकाल रहा है, लेकिन यह स्वाद की अनदेखी कर रहा है और इसलिए आप "ClientListView Lite.r5m" और "ClientListView 200.r5m" दोनों फ़ाइलों के साथ समाप्त हो गए हैं। फ़ोल्डर; जो स्पष्ट रूप से वह नहीं है जो मैं चाहता हूं।

MSIEXEC पर डॉक्स पढ़ने पर, ऐसा लगता है कि आप एक सार्वजनिक संपत्ति जैसे कि msiexec.exe / a "C: \ Example.msi" MY_PROP = "myValue" के लिए मान में पास कर सकते हैं - इसलिए मुझे लगा कि इससे मुझे मदद मिल सकती है; इसलिए मेरे वाईएक्स कोड में मैंने लाइन जोड़ी:

    <Property Id='PRODTYPE' Value="$(var.FLAVOUR)"/>

और फिर मेरी घटक शर्तों को बदल दिया जैसे:

  <Component Id="cmp7F45920B1AA100729BAE37FC846B3FC5" Guid="*">
    <File Id="fil238A776D9294E14671E012472F9F7196"
          KeyPath="yes"
          Source="$(var.MenusPath)\ClientListView 200.r5m"  
    <Condition><![CDATA[PRODTYPE=200]]></Condition>
  </Component>

  <Component Id="cmp8BFF42B232724DC4BA5B8F87994DEF21" Guid="*">
    <File Id="fil808D6428D67248DDB8CA65DBC5978283" 
          KeyPath="yes" 
          Source="$(var.MenusPath)\ClientListView Lite.r5m"
    <Condition><![CDATA[PRODTYPE=LITE]]></Condition>
  </Component>

लेकिन यद्यपि यह संकलित ठीक है, इसके माध्यम से चल रहा है:

msiexec /a OurProduct.msi /qb PRODTYPE=200 TARGETDIR="C:\InstalledFiles200"

अभी भी 200 और लाइट जायके के लिए दोनों फाइलें निकालता है, जहां मैं सिर्फ 200 के लिए एक चाहता था।

इसलिए, क्या मैं ऐसा कुछ करने की कोशिश कर रहा हूं जो संभव नहीं है ... या क्या मैं कुछ गलत कर रहा हूं - किसी भी मदद की सराहना की जाएगी, क्योंकि मेरे ज़िप बनाने के लिए बैच फ़ाइल में प्रक्रिया की नकल करने का विकल्प; भयावह होगा !!

चीयर्स,

क्रिस।


Msiexec कमांड लाइन में एक स्विच सामान्य अर्थों में एक इंस्टॉल नहीं है। यह सचमुच एक स्थान के लिए फ़ाइलों का सिर्फ एक अनपैक है। यदि आप एक वास्तविक स्थापित करना चाहते हैं, तो आपको / i या बस MSI फ़ाइल का डबल-क्लिक करना चाहिए। वह आपको प्रोग्राम्स और फीचर्स आदि में प्रविष्टि के साथ एक उचित पूर्ण इंस्टॉलेशन देगा।

क्या स्थापित करने के विकल्प अधिक सामान्य रूप से सेटअप को सुविधाओं में विभाजित करके नियंत्रित किए जाते हैं, प्रत्येक में आवश्यक कार्यक्षमता वाले घटकों का एक सेट होता है। वाईएक्स यूआई में आप सुविधाओं को चुनने के लिए एक संवाद प्राप्त कर सकते हैं, और रखरखाव मोड आपको वापस जाने और उन्हें बदलने देगा। एक कमांड लाइन में आप सिर्फ इतना कहेंगे / i [msi फ़ाइल] ADDLOCAL = Feature1, Feature2 और इतने पर। यदि आप वास्तव में "स्वाद" का उपयोग करना चाहते हैं तो आंतरिक रूप से आप इसे ADDLOCAL सूची में बदल देंगे।