Wix Tools अपडेट पुरानी कस्टम क्रियाओं का उपयोग करता है




windows-installer (2)

शर्तों का परीक्षण

शर्त # 1:

Installed AND (NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)

कंडीशनिंग के इस अजीब नक्षत्र के कारण कस्टम एक्शन प्रश्न में ताज़ा स्थापना के दौरान नहीं चलेगा, न ही मैन्युअल अनइंस्टॉल। ऐसा लगता है कि यह कस्टम एक्शन के दौरान चलेगा: प्रमुख उन्नयन (जो एक विशेष प्रकार की स्थापना रद्द है), संशोधित और मरम्मत। मुझे लगता है कि यह सेटिंग फ़ाइल का बैकअप लेने का काम करेगा। हालाँकि...

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

संक्षेप में:

  • रन : प्रमुख अपग्रेड (पुराने MSI के माध्यम से चलाएं जो कि uninstalls, लेकिन नए MSI में नहीं), संशोधित, मरम्मत
  • नहीं चलता है : पहली बार स्थापित करें, स्थापना रद्द करें।

शर्त # 2:

NOT Installed OR Installed AND (NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)

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

संक्षेप में:

  • रन : पहली बार स्थापित, प्रमुख उन्नयन
  • नहीं चलता है : स्थापना रद्द करें, संशोधित करें, मरम्मत करें

मानक शर्तें

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

मैं पूरी तरह से कस्टम क्रियाओं से बचने की सलाह दूंगा, और इसे प्राप्त करने के लिए नीचे एक सुझाव दिया गया दृष्टिकोण है।

सेटिंग फाइलों को प्रबंधित करने के लिए एप्लिकेशन का उपयोग करना

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

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

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

जब आप अपने इंस्टॉलर द्वारा अछूत हैं एक नई फ़ाइल के लिए टेम्पलेट सेटिंग्स फ़ाइलों की प्रतिलिपि बनाते समय आपको एमएसआई की सनक और क्विर्क - या किसी भी प्रबंधित कस्टम क्रियाओं और उनकी रनटाइम आवश्यकताओं से निपटना नहीं होगा।

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

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

बस इसका उल्लेख करने के लिए: आपकी सेटिंग फ़ाइल वास्तव में वैसे ही आपकी वर्तमान अपग्रेड योजना द्वारा अधिलेखित नहीं की जा रही है। इसे प्रमुख उन्नयन के दौरान अनइंस्टॉल और पुनः इंस्टॉल किया जा रहा है क्योंकि इसका घटक मूल रूप से Permanent = "yes" और NeverOverwrite="yes" लिए सेट नहीं किया गया था। ऐसा प्रतीत होता है कि उसने इसे डिफ़ॉल्ट मानों में बदल दिया है, लेकिन इसे कभी भी अधिलेखित नहीं किया गया था। बल्कि इसे अनइंस्टॉल कर दिया गया था और बदलावों को मिटा दिया गया था। MSI परिवर्तित, गैर-संस्करणित फ़ाइलों को अधिलेखित नहीं करेगा, लेकिन जब तक उन्हें स्थायी रूप से चिह्नित नहीं किया जाता है, तब तक यह खुशी से स्थापना रद्द करेगा और उन्हें पुनर्स्थापित करेगा। यह मेरी राय में एक प्रौद्योगिकी विरोधी पैटर्न है - बहुत सारी टीमों को हर समय इस समस्या का सामना करना पड़ता है। इसलिए यहाँ वर्णित के रूप में कुछ डेटा फ़ाइल परिनियोजन विकल्पों की समीक्षा करने के लिए मेरा सुझाव: व्यवस्थापक प्रोफ़ाइल से फ़ोल्डर और फ़ाइल बनाएं, व्यवस्थापक प्रोफ़ाइल (ऊपर दिए गए लिंक से)।

मुझे आशा है कि इसमें से कुछ मदद करता है, और कृपया हमें बताएं कि आपको परीक्षण के दौरान क्या मिला।

पुराने उत्तर :

ब्रायन ने वास्तविक सलाह का उल्लेख किया है, लेकिन शायद स्पष्टीकरण के लिए कुछ प्रश्न। एक बार कुछ उत्तर देने के बाद मैं इसे एक प्रयास में उत्तर दूंगा।

  • ये कस्टम एक्शन कैसे चल रहे हैं? क्या वे EXE कमांड हैं या आप एक लांचर EXE चला रहे हैं जो फिर उन्हें आमंत्रित करता है? यदि आप ऐसे लांचर EXE का उपयोग करते हैं, तो क्या यह मूल (C ++) या .NET है? (सी # / VB.NET)। अगर यह .NET है तो अक्सर बुरी खबर है।
  • क्या हम पूछ सकते हैं कि आप इन कॉपी कमांडों के साथ क्या कर रहे हैं? यह आवेदन में ही किया जा सकता है और अधिक मज़बूती से? यह शायद सबसे आम सलाह है जो हम लोगों को देते हैं, कि यदि वास्तव में तैनाती को सरल बनाया जाए और इसे और अधिक विश्वसनीय बनाया जाए। आपके पास एक एप्लिकेशन में क्या होता है, इसका अधिक नियंत्रण है, आप एक पूर्वानुमानित सुरक्षा संदर्भ में चलते हैं और देखभाल करने के लिए कोई कंडीशनिंग या अनुक्रमण नहीं है। और अंत में: आप एप्लिकेशन को पुनरारंभ कर सकते हैं और इसे फिर से कर सकते हैं, एक सेटअप "एक शॉट" है।
  • मैं इसे उस समय के लिए छोड़ दूंगा ...

हमने आगंतुक सेटअप टूल का उपयोग करके कुछ अजीब व्यवहार का पता लगाया है। हमने कुछ प्रमुख संस्करणों (2.2.0 - से 2.2.4) को तैनात किया है। 2.2.5 के लिए हमने कस्टम क्रियाओं में एक छोटी सी चीज़ बदल दी (इससे पहले कि हम XCOPY का उपयोग करते हैं, अब हम RoboCopy का उपयोग करते हैं क्योंकि इसमें "MOVE" कमांड है और न केवल एक प्रति है)।

लेकिन जब हम अब 2.2.4 से 2.2.5 तक अपडेट करते हैं, तब भी सेटअप नए MOVE कमांड के बजाय पुरानी कॉपी कमांड का उपयोग करता है, लेकिन ऐसा नहीं हो सकता क्योंकि 2.2.5 में कोई कॉपी कमांड नहीं है। अगर मैं 2.2.6 (2.2.5 के साथ समान) को तैनात करता हूं और 2.2.5 से अपडेट करता हूं तो यह नई अपडेट प्रक्रिया का उपयोग करता है ... ऐसा लगता है कि अपडेट पुराने एमएसआई का उपयोग करता है।

एसओ को यह मिला

क्या इस व्यवहार को रोकने का कोई तरीका है? यह पूरी तरह से अपडेट प्रक्रिया को तोड़ता है क्योंकि मौजूदा कॉन्फिग फाइल को अपडेट पर सही तरीके से कॉपी नहीं किया जाता है।

हम ग्राहक को रजिस्ट्री को साफ करने या किसी भी MSI फ़ाइलों को GUID द्वारा कैश निकालने के लिए बाध्य नहीं कर सकते ...

किसी भी मदद की सराहना की। अग्रिम में धन्यवाद

अद्यतन: Product.wxs में नई कस्टम क्रिया

<Property Id="C_TEMP" Value="C:\Temp" />
      <Property Id="ROBOCOPY_EXE">robocopy.exe</Property>
      <CustomAction Id="CopyToTemp" Property="ROBOCOPY_EXE" Return="ignore" ExeCommand='"[INSTALLDIR]\Configuration" "[C_TEMP]\ServerSettings" ServerSettings.json' />
      <CustomAction Id="CopyFromTemp" Property="ROBOCOPY_EXE" Return="ignore" ExeCommand='"[C_TEMP]\ServerSettings" "[INSTALLDIR]\Configuration" ServerSettings.json /MOVE /IS' />

पुरानी कस्टम क्रिया

<Property Id="C_TEMP" Value="C:\Temp" />
  <Property Id="XCOPY_EXE">xcopy.exe</Property>
  <CustomAction Id="CopyToTemp" Property="XCOPY_EXE" Return="ignore" ExeCommand='"[INSTALLDIR]\Configuration\ServerSettings.json" "[C_TEMP]\ServerSettings.json.bak*" /YIR' />
  <CustomAction Id="CopyFromTemp" Property="XCOPY_EXE" Return="ignore" ExeCommand='"[C_TEMP]\ServerSettings.json.bak" "[INSTALLDIR]\Configuration\ServerSettings.json*" /YIR' />

बाद में कोड अब तक नहीं बदला

<InstallExecuteSequence>
  <Custom Action="CopyToTemp" Before="InstallInitialize">Installed AND (NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)</Custom>
  <Custom Action="CopyFromTemp" Before="SetVersionsInRegistry">NOT Installed OR Installed AND (NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)</Custom>

.....
</InstallExecuteSequence>

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

  1. ब्रायन की टिप्पणी / उत्तर - वे उस मूल स्थापित में गलत तरीके से वातानुकूलित थे, और जब अद्यतन पुराने स्थापित में अनुक्रमों के माध्यम से जाता है तो यह पता चलता है कि स्थिति सही मूल्यांकन करती है। यदि आपको पसंद है, तो कस्टम क्रियाओं को स्थापित करने या कस्टम क्रियाओं को अनइंस्टॉल करने जैसी कोई चीज़ नहीं है: शर्तों के साथ केवल कस्टम क्रियाएं हैं। एक अद्यतन के रूप में पोस्ट किए गए WiX स्रोत में, UPGRADINGPRODUCTCODE का उपयोग सही नहीं है। यह संपत्ति पुराने उत्पाद में तब सेट हो जाती है जब इसे प्रमुख अपग्रेड के दौरान अनइंस्टॉल किया जा रहा होता है, इसलिए "या UPGRADINGPRODUCTCODE" कहे जाने वाले पुराने इंस्टाल में कोई भी शर्त सही होगी। यदि आप एक ऐसी स्थिति चाहते हैं जो किसी पुराने उत्पाद को अपग्रेड करते समय अपग्रेड इंस्टॉल में सेट की गई है, तो मेजरअपग्रेड तत्व द्वारा उपयोग की जाने वाली विज़िटर_यूपीजीआरईएडीईएड, का उपयोग करें।

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

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