👡 👩🏿‍🤝‍👩🏼 🛩️ पैचविक्स का उपयोग करके Wix पर पैच बनाना। भाग २ ⚗️ 🤰🏿 🛀🏽

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

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

समस्या का हमारा संगठनात्मक समाधान

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

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

इस प्रकार, जब कोई ग्राहक हमसे नवीनतम संस्करण का अनुरोध करता है, तो हम जांच करेंगे कि क्या उसके पास अभी स्थापित संस्करण है और उसकी संख्या क्या है। आगे - या तो पूरी विधानसभा या एक पैच भेजा जाता है।

स्वचालित अद्यतन के साथ एक समान योजना काम करती है: या तो msi या msp पैकेज सर्वर से आता है, जो मानक msiexec टूल का उपयोग करके स्थापित किया गया है।

इस तंत्र के कार्यान्वयन को समझने के लिए, निम्नलिखित समाधान पर विचार करें।

समाधान अवलोकन

शुरू करने के लिए, समाधान की सामान्य संरचना पर विचार करें (ज़ाहिर है, फ़ोल्डर्स स्पष्टता के लिए नामित किए गए हैं)। इसका पूर्ण स्रोत कोड GitHub पर अपलोड किया गया है , लिंक अंत में है।

फ़ोल्डर में शामिल हैं:
1. आवेदन ही।
2. Wix के लिए एक्सटेंशन सहित प्रतिष्ठानों को इकट्ठा करने के लिए सामान्य फाइलें।
3. प्रोजेक्ट एप्लिकेशन इंस्टॉलेशन।
4. पैच बनाने के लिए उपयोगिता।
5. टेस्ट के लिए बॉडी शर्ट।

फ़ोल्डर संख्या आवश्यक क्रियाओं के क्रम को दर्शाती है। चलिए शुरू करते हैं।

चरणों का पालन करें

चरण 1. एक आवेदन लिखें

हमारे मामले में, यह एक सरल कंसोल एप्लिकेशन होगा "हैलो, वर्ल्ड!", जिसमें हम संस्करण को बदल देंगे।

चरण 2. हम प्रतिष्ठानों के लिए सामान्य भागों को लिखते हैं

हम फाइलों से गुजरते हैं:
Deploy.Variables.wxi सभी कंपनी प्रतिष्ठानों के लिए सामान्य चर हैं:

<Include> <?define Manufacturer=""?> <?define ManufacturerUrl="http://company.ru"?> <?define Language="1049"?> <?define Codepage="1251"?> </Include>

यह मुझे लगता है कि यहां सब कुछ स्पष्ट है: सभी स्थापना परियोजनाओं में उपयोग किए जाने वाले चर इंगित किए जाते हैं।

Deploy.Yasen.Variables.wxi - सभी उत्पाद स्थापनाओं के लिए एक सामान्य Wix फ़ाइल:

 <Include> <?define ProductName="" ?> <?define YasenProductCode="{06CABA42-492E-49CE-9849-F85E87442E99}"?> <?define YasenUpgradeCode="{BA8CCE3C-4267-4291-B330-16EE510F023B}"?> </Include>

हम यहां उत्पाद कोड और अपडेट की अलग-अलग रिपोर्टिंग क्यों कर रहे हैं? क्योंकि तब हमें कई स्थानों पर (अलग-अलग स्थापना परियोजनाओं और पैच डिस्क्रिप्टर में) उनकी आवश्यकता होगी।

Deploy.Yasen.ProductContent.wxi विभिन्न संस्थापन गुणों के साथ एक साझा फ़ाइल है।

 <Include> <Package Id="$(var.PackageId)" InstallerVersion="200" Compressed="yes" Languages="$(var.Language)" SummaryCodepage="$(var.Codepage)" Comments=" $(var.ProductName)" Keywords=", , , , , " Description="$(var.Subject)" InstallScope="perMachine" /> <!--    --> <Property Id="MSIUSEREALADMINDETECTION" Value="1" /> <MajorUpgrade DowngradeErrorMessage ="     " AllowDowngrades="no" /> <Upgrade Id='$(var.UpgradeCode)' > <UpgradeVersion OnlyDetect="no" Maximum="$(var.ProductVersion)" IncludeMaximum="no" Property="OLDERVERSIONBEINGUPGRADED" MigrateFeatures="yes" /> </Upgrade> <!-- Media --> <Media Id="1" Cabinet="media1.cab" EmbedCab="yes" /> </Include>

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

MSIUSEREALADMINDETECTION - यदि = 1 है, तो एक वास्तविक व्यवस्थापक के अधिकारों का अनुरोध किया जाएगा (UAC के माध्यम से)।
मेजरअपग्रेड तत्व - हमारे मामले में, मेजर अपग्रेड के लिए संभावनाओं को इंगित करता है - नए संस्करण में अपडेट करने की अनुमति है और पुराने वाले को रोलबैक निषिद्ध है।
एलिमेंट अपग्रेड - इसमें संभावित अपडेट का विवरण होता है।
UpgradVersion तत्व पिछले संस्करणों ( UpgradCode द्वारा) का पता लगाने और उनकी पहचान के मामले में कार्रवाई के लिए शर्तों का वर्णन करता है। संभावित विकल्प (मैं सभी नहीं देता):
न्यूनतम - न्यूनतम संस्करण जिसे यह इंस्टॉलेशन अपडेट कर सकता है।
अधिकतम - अधिकतम संस्करण जिसे यह इंस्टॉलेशन अपडेट कर सकता है।
मैक्सिमम शामिल करें - "समावेशी" अधिकतम संस्करण (डिफ़ॉल्ट रूप से - हां)।
न्यूनतम शामिल - "समावेशी" न्यूनतम संस्करण।
संपत्ति - में कुछ चर का नाम होता है। यदि संकेतित संस्करणों पर संबंधित उत्पाद पाए जाते हैं, तो उनके कोड 'इस' के माध्यम से इस चर को लिखे जाएंगे। इस चर के मान बाद में भाग ले सकते हैं, उदाहरण के लिए, जब CustomAction प्रदर्शन करते हैं।
OnlyDetect - यदि = ' हां ' है, तो निर्दिष्ट संस्करणों को केवल निर्दिष्ट गुणों का पता लगाया और लिखा जाएगा, लेकिन वे अनइंस्टॉल नहीं होंगे।
IgnoreRemoveFailure - बताता है कि क्या पता संस्करण की स्थापना रद्द करते समय त्रुटियों को अनदेखा करना है।

हमारे मामले में, UpgradVersion कॉन्फ़िगर किया गया है ताकि हमारे UpgradCode के भीतर सभी पिछले संस्करणों को अपग्रेड करना संभव हो।

हम आगे बढ़ते हैं: Deploy.Yasen.PatchCreation.xml - इस उत्पाद के लिए पैच विवरणक।

 <Include xmlns="http://schemas.microsoft.com/wix/2006/wi"> <?include Deploy.Variables.wxi?> <?include Deploy.Yasen.Variables.wxi?> <?define PatchDescription=" $(var.ProductName)"?> <PatchCreation Id="$(var.PatchId)" Codepage="$(var.Codepage)" CleanWorkingFolder="yes" OutputPath="patch.pcp" WholeFilesOnly="yes" > <PatchInformation Description="$(var.PatchDescription)" Comments="$(var.PatchDescription)" Manufacturer="$(var.Manufacturer)"/> <PatchMetadata AllowRemoval="yes" Description="$(var.PatchDescription)" ManufacturerName="$(var.Manufacturer)" TargetProductName="$(var.ProductName)" MoreInfoURL="$(var.ManufacturerUrl)" Classification="Update" DisplayName="$(var.PatchDescription)   $(var.PatchVersion)"/> <Family DiskId="2" Name="$(var.Family)" SequenceStart="5000" > <UpgradeImage SourceFile="$(var.NewMsi)" Id="NewPackage" > <TargetImage SourceFile="$(var.BaseMsi)" Order="2" Id="BasePackage" IgnoreMissingFiles="no" Validation = "0x00000912" /> </UpgradeImage> </Family> <PatchSequence PatchFamily="$(var.PatchFamily)" Sequence="$(var.PatchVersion)" Supersede="yes" ProductCode="$(var.ProductCode)"/> </PatchCreation> </Include>

हमने भाग 1 में पर्याप्त विस्तार से पैचक्रिएशन संरचना की जांच की । लेकिन यहां आप कम से कम 2 बहुत महत्वपूर्ण अंतर देख सकते हैं:

TargetImage तत्व पर मान्यता विशेषता। यह वह विशेषता है जो हमें लंघन पैच की अनुमति देता है। इसका विस्तार से वर्णन यहाँ किया गया है । इसलिए, कई संस्करणों को अपडेट करने की अनुमति देने के लिए, आपको आमतौर पर उनमें से सभी को निर्दिष्ट करने की आवश्यकता होती है ( टारगेटइमेज तत्वों के साथ), जो बदले में पैच के आकार को बढ़ाता है। हमारी आवश्यकताओं और संगठनात्मक उपायों (संस्करणों के सिद्धांत) को ध्यान में रखते हुए, हम केवल 912 के मान के साथ पिछले समर्थन विधानसभा और सत्यापन ध्वज को इंगित करने में कामयाब रहे। यह मान इंगित करता है कि स्थापित उत्पाद में पैच को लागू करने के लिए, शर्त पूरी करनी होगी: UpgradCode , ProductCode और Magor और पैच के मामूली संस्करण (जिसमें हम अपडेट करते हैं) और इंस्टॉल किए गए संस्करण से मेल खाना चाहिए (लेकिन बिल्ड संख्या - नहीं)। इस प्रकार, मामूली संस्करण के भीतर लंघन अद्यतन की अनुमति दी जाएगी! मुझे पाँच दो! मान्यता मूल्यों की एक विस्तृत श्रृंखला पर ले जा सकते हैं और आप एक बहुत ही दिलचस्प प्रभाव प्राप्त कर सकते हैं। का आनंद लें!
PatchCreation फ़ाइल उन चर का भी उपयोग करती है जो पहले घोषित नहीं किए गए हैं, उदाहरण के लिए: var.PatchFamily , var.PatchVersion । उनका उपयोग चरण 4 में हमारे लिए स्पष्ट हो जाएगा।

और चरण 2 में एक निश्चित Incom.WixExtensions प्रोजेक्ट (फ़ोल्डर में) है। यह Wix के विस्तार के साथ एक परियोजना है। यह तार्किक रूप से यहीं मौजूद होना चाहिए, और इसका उपयोग चरण 3 में स्पष्ट हो जाएगा।

चरण 3. हम कुछ ग्राहक के लिए स्थापना एकत्र करते हैं

सबसे पहले, Wix फ़ाइलों को उन चरों के साथ कनेक्ट करें जिन्हें हमने पहले घोषित किया था।

  <?define WixCommonPath="$(var.ProjectDir)..\"?> <?include $(var.WixCommonPath)\Deploy.Variables.wxi?> <?include $(var.WixCommonPath)\Deploy.Yasen.Variables.wxi?>

फिर हम सॉफ्टवेयर संस्करण और वर्तमान उत्पाद कोड और अपडेट लाइन की घोषणा करेंगे।

  <?define Subject=" "?> <?define ProductVersion="$(incom.FileVersion($(var.Yasen.UI.TargetPath)))"?> <?define UpgradeCode="$(var.YasenUpgradeCode)"?> <?define ProductCode="$(incom.ChangeGuid($(var.YasenProductCode),$(var.ProductVersion), 2))"?>

कृपया ध्यान दें कि UpgradCode का उपयोग "जैसा है" और उत्पाद कोड में किसी प्रकार का रूपांतरण लागू होता है।
इस परिवर्तन का उपयोग करते हुए, हम निम्नलिखित लक्ष्य के लिए प्रयास करते हैं: बिल्ड नंबर बदलते समय , उत्पाद कोड नहीं बदलना चाहिए ताकि एक अंतर पैच बनाया जा सके, और मेजर या माइनर संस्करण बदलते समय, उत्पाद कोड को बदलना चाहिए (यह पहले भाग में वर्णित था)। तदनुसार, हम निम्न कार्य करते हैं: हम एक वैश्विक चर से उत्पाद कोड का उपयोग करते हैं और रूपांतरण फ़ंक्शन को कॉल करते हैं, यह दर्शाता है कि अंतिम संस्करण किस संस्करण पर निर्भर करता है। इसके अलावा, 1 - केवल प्रमुख से , 2 - प्रमुख और मामूली से , और फिर सादृश्य द्वारा 4 के मूल्य तक।

यह ऊपर वर्णित Wix एक्सटेंशन का समय है।
चूंकि इस लेख का उद्देश्य Wix के लिए एक्सटेंशन बनाने की तकनीक का वर्णन करना नहीं है (आप इसे यहां देख सकते हैं), मैं एक संक्षिप्त सारांश दूंगा: एक मूल्यांकन के लिए प्रीप्रोसेसर के लिए एक एक्सटेंशन बनाया गया है जिसे पुनर्निर्धारित विधि के साथ फिर से परिभाषित किया गया है। सटीक उपसर्ग के साथ फ़ंक्शन का उपयोग करते समय इसे विक्स द्वारा बुलाया जाएगा।
इस विधि में, हम 2 कार्य करते हैं:
• फ़ाइल संस्करण प्राप्त करना
• यूनिवर्सल गाइड चेंज फंक्शन

फ़ंक्शन गणना के लिए Wix एक्सटेंशन कोड स्निपेट

 /// <summary> ///   /// </summary> /// <param name="prefix"></param> /// <param name="function"> </param> /// <param name="args"></param> /// <returns> </returns> public override string EvaluateFunction(string prefix, string function, string[] args) { if (prefix == "incom") { switch (function.ToLower()) { case "fileversion": var ver = FileVersionInfo.GetVersionInfo(Path.GetFullPath(args[0])).FileVersion; Console.WriteLine(string.Format("Version of {0}: {1}", args[0], ver)); return ver; case "changeguid": var guid = Guid.Parse(args[0]).ToByteArray(); version = Version.Parse(args[1]); var major = BitConverter.GetBytes((Int16)((version.Major & 0xFF) ^ ((version.Major >> 16) & 0xFF))); var minor = BitConverter.GetBytes((Int16)((version.Minor & 0xFF) ^ ((version.Minor >> 16) & 0xFF))); var build = BitConverter.GetBytes((Int16)((version.Build & 0xFF) ^ ((version.Build >> 16) & 0xFF))); var revision = BitConverter.GetBytes((Int16)((version.Revision & 0xFF) ^ ((version.Revision >> 16) & 0xFF))); var len = 4; if (args.Length > 2) len = int.Parse(args[2]); if (len > 0) { guid[0] = major[0]; guid[1] = major[1]; } if (len > 1) { guid[2] = minor[0]; guid[3] = minor[1]; } if (len > 2) { guid[4] = build[0]; guid[5] = build[1]; } if (len > 3) { guid[6] = revision[0]; guid[7] = revision[1]; } return new Guid(guid).ToString(); } } return base.EvaluateFunction(prefix, function, args); }

इस प्रकार, हमारे कोड अनुमानित रूप से व्यवहार करते हैं और उत्पाद के संस्करण पर निर्भर करते हैं। जब हम कोड को थोड़ा बदल देते हैं - हम संदर्भ असेंबली बनाने के लिए बिल्ड नंबर (प्रत्येक 2-3 सप्ताह में एक बार), कुछ और अधिक गंभीर - माइनर संख्या (लगभग 2-3 बार एक बार) बदल देते हैं। जब सब कुछ पत्राचार किया जाता है, तो मेजर नंबर बदल जाता है (लगभग हर 3-4 साल में एक बार)।

फ़ाइलों को वापस करने के लिए। इसके अलावा, सब कुछ मानक है: ऊपर घोषित चर का उपयोग करके, उत्पाद ब्लॉक बनाएं, फ़ाइलों, घटकों, विशेषताओं को निर्दिष्ट करें, पिछले चरण में वर्णित Deploy.Yasen.ProductContent का उपयोग करें।

 <Product Id="$(var.ProductCode)" Name="$(var.ProductName)" Language="$(var.Language)" Version="$(var.ProductVersion)" Manufacturer="$(var.Manufacturer)" UpgradeCode="$(var.UpgradeCode)" > <?include $(var.WixCommonPath)\Deploy.Yasen.ProductContent.wxi?> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFilesFolder"> <Directory Id="APPLICATIONFOLDER" Name="$(var.ProductName)" DiskId="1" > <!-- Content --> <Component Id="Component1" Guid="{1F4A6EF3-4B65-4405-8E08-D750E5038C75}"> <File Id="File1" Name="content.txt" Source="..\..\Incom.Yasen.Content\content.txt"/> <File Id="File2" Name="Yasen.UI.exe" Source="$(var.Yasen.UI.TargetPath)"/> </Component> </Directory> </Directory> </Directory> <Feature Id="ClientSide" Title=" $(var.ProductName)" Level="1" Absent="disallow"> <ComponentRef Id="Component1"/> </Feature> </Product>

चरण 4. एक पैच बनाना

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

 Incom.MakeMsp.exe "YasenSetup1.msi" "YasenSetup1.0.1.msi" "Deploy.Yasen.PatchCreation.xml" "Patch.msp"

सामान्य तौर पर, एल्गोरिथ्म इस प्रकार है:
1. दोनों एमएसआई को एक अस्थायी फ़ोल्डर में कॉपी करें

कोड का टुकड़ा

 Task.WaitAll( Task.Run( () => { Console.WriteLine("Start copying RTM..."); File.Copy(args[0], rtmFilePath, true); Console.WriteLine("Finished copying RTM..."); }) , Task.Run( () => { Console.WriteLine("Start copying latest..."); File.Copy(args[1], latestFilePath, true); Console.WriteLine("Finished copying latest..."); }));

2. याद रखें, चरण 2 में, पैचक्रिएट का निर्माण करते समय , हमने अज्ञात चर का उपयोग किया था? उन्हें पहचानने का समय आ गया है। ऐसा करने के लिए, उपयोगिता एक Wix संरचना के साथ एक अस्थायी फ़ाइल बनाती है, जहाँ इन चरों के मान लिखे जाते हैं।

एक पैच बनाने के लिए चर के साथ एक फ़ाइल बनाने के लिए कोड का एक टुकड़ा

 var productName = MsiReader.GetMSIParameters(latestFilePath, "ProductName"); var wixPachCreationReference = string.Format( @"<?xml version=""1.0"" encoding=""utf-8""?> <Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'> <?define Family='{0}'?> <?define PatchFamily='{0}'?> <?define PatchId='{1}'?> <?define ProductCode='{2}'?> <?define PatchVersion='{3}'?> <?define BaseMsi='{4}'?> <?define NewMsi='{5}'?> <?include {6}?> </Wix>", new string(Transliterate(productName).Where(char.IsLetterOrDigit).Take(8).ToArray()), Guid.NewGuid().ToString(), MsiReader.GetMSIParameters(latestFilePath, "ProductCode"), MsiReader.GetMSIParameters(latestFilePath, "ProductVersion"), Path.Combine(rtmPath, "rtm.msi"), Path.Combine(latesPath, "last.msi"), Path.GetFullPath(args[2]) );

लिप्यंतरण के साथ उत्पाद का नाम पैचफ़ैमिली के रूप में उपयोग किया जाता है। पैचआईड नया गाइड है। ProductCode , PatchVersion - अंतिम msi , BaseMsi और NewMsi से निकाला गया - अस्थायी msi का पथ (एक अस्थायी फ़ोल्डर में कॉपी किया गया)। अंत में, पैचक्रिएशन के साथ फाइल पर ही शामिल करें ।

3. इसके बाद, भाग 1 में वर्णित संकलन चरणों का प्रदर्शन किया जाता है।
प्रशासनिक स्थापना:

 exec("msiexec", string.Format("/a \"{0}\" /qn TARGETDIR=\"{1}\\\"", rtmFilePath, rtmPath)); exec("msiexec", string.Format("/a \"{0}\" /qn TARGETDIR=\"{1}\\\"", latestFilePath, latesPath));

संकलन और एक पैच बनाना:

 exec("candle", string.Format("\"{0}\" -out \"{1}\\patch.wixobj\"", Path.Combine(tempDir, "desc.xml"), tempDir)); exec("light", string.Format("\"{0}\\patch.wixobj\" -out \"{0}\\patch.pcp\"", tempDir)); exec("msimsp", string.Format("-s \"{0}\\patch.pcp\" -p \"{1}\" -l \"{0}\\msimsp.log\"", tempDir, args[3]));

चरण 5. सब कुछ और सब कुछ का संकलन

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

परिणाम का उपयोग करना

CompileAll.bat चलाने के बाद परिणाम।

पैच अपडेट करें

आप केवल DblClick द्वारा संस्करण 1 को स्थापित कर सकते हैं। परिणाम:

आप DblClick का उपयोग करके एक पैच भी स्थापित कर सकते हैं:

स्थापित अद्यतन देखने से यह पता चलेगा:

पूर्ण पैक अद्यतन

अगर हमें पूर्ण msi पैकेज का उपयोग करते हुए 1.0.0 से 1.0.1 तक के संस्करण को अपडेट करने की आवश्यकता है, तो हमें निम्नलिखित मापदंडों के साथ कंसोल का उपयोग करना होगा:

 msiexec /i YasenSetup1.0.1.msi REINSTALL=ALL REINSTALLMODE=vomus

यहां:
अद्यतन - इंगित करता है कि अद्यतन के दौरान इस पैकेज द्वारा कौन सी सुविधाओं को फिर से स्थापित किया जाएगा (हम संकेत करते हैं कि सभी)। यदि हम इस संपत्ति को निर्दिष्ट नहीं करते हैं, तो जब आप पैकेज (और स्थापित पुराने संस्करण) को चलाने की कोशिश करते हैं, तो संदेश "एक और इंस्टॉल किया गया है।" ( विवरण )
REINSTALLMODE - एक संपत्ति जो इंगित करती है कि फाइलों का पुनर्स्थापना (अपडेट) कैसे होगा। ( विवरण )। हमारे मामले में, यह है:
v - आपको स्थानीय भंडारण में पैकेज को कैश करना होगा। तथ्य यह है कि प्रत्येक उत्पाद ( ProductCode ) के लिए, Windows को पैकेज का मान याद है। जहां से उत्पाद वितरित किया गया था। यदि उत्पाद पहले से ही स्थापित है और सामग्री और संस्करण में भी एक समान पैकेज स्थापित करने का प्रयास किया जाता है, लेकिन एक अलग पैकेज के साथ। (सिर्फ समाधान का पुनर्निर्माण), तो पैकेज का कैश्ड मान। पैकेज के पैकेज से मेल नहीं खाएगा । नई स्थापना का चेतावनी और चेतावनी जारी की जाएगी कि यह स्थापित है एक और संस्करण। एक v के साथ, Package.Id अनुपालन के लिए जाँच नहीं की जाएगी।
यदि वर्तमान संस्करण नए से कम है या फाइल गायब है, तो o - फाइल को फिर से लिखें।
m - रजिस्ट्री कुंजियाँ अधिलेखित करें ( HKEY_LOCAL_MACHINE और HKEY_CLASSES_ROOT )
यू - रजिस्ट्री कुंजी को ओवरराइट करता है ( HKEY_CURRENT_USER और HKEY_USERS )
s - सभी शॉर्टकटों को फिर से लिखना और आइकन कैश को फिर से लिखना।

इस असुविधाजनक अद्यतन विधि से बचने और केवल काम करने के लिए DblClick प्राप्त करने के लिए विकल्प हैं, लेकिन यह पूरी तरह से एक और कहानी है।

संक्षेप में कहना

इसलिए, समस्या को हल करने के लिए, निम्नलिखित कदम उठाए गए:
1) अंतिम उपयोगकर्ताओं के लिए Wix इंस्टॉलेशन लिखने के लिए विशेष आवश्यकताएं विकसित की गई हैं, जिसमें शामिल हैं:
एक। साझा फ़ाइलों में संभव है कि सब कुछ बाहर निकालें , मॉड्यूल मर्ज करें और शामिल निर्देश का उपयोग करें।
ख। बेस वैल्यू के आधार पर Product.ProductCode जनरेट करें।
2) पैच बनाने के लिए एक ही प्रोजेक्ट बनाएं।
3) एक विशेष उपयोगिता बनाएं जो पैच बनाने में मदद करेगी।

अंतिम परिणाम

विक्स एक बड़े सिरदर्द को हल करने में मदद करता है, जिसके लिए बहुत धन्यवाद।
बेशक, कुछ चीजें छाया में बनी हुई हैं, लेकिन सबसे महत्वपूर्ण और मूल्यवान पाठक को प्रस्तुत किया गया है।

आपका धन्यवाद

संदर्भ:
GitHub पर सभी स्रोत

पैचविक्स का उपयोग करके Wix पर पैच बनाना। भाग २