वाईएक्स

Question

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

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

मैं अपनी कॉन्फ़िगरेशन फ़ाइलों को एक उपनिर्देशिका या यहां तक ​​कि एक अलग नाम (उदा। डिफ़ॉल्ट.cfg) में स्थापित करना चाहता हूं और फिर फ़ाइलों को उनके सही स्थानों पर कॉपी करने के लिए वाईएक्स में <CopyFile> तत्व का उपयोग करना चाहता हूं। इस तरह, डिफ़ॉल्ट फ़ाइलों को अपग्रेड पर इंस्टॉल और ओवरराइट करने पर हटा दिया जाएगा, लेकिन वास्तविक उपयोगकर्ता फाइलें वही रहेंगी। दुर्भाग्यवश <CopyFile> के साथ, विंडोज इंस्टालर अभी भी गंतव्य फ़ाइल को प्रबंधित (और निकालना) चाहता है।

मैंने मूल रूप से "डिफ़ॉल्ट default.cfg reallocation.cfg कॉपी" करने के लिए WixUtilExtension में QtExec कार्रवाई का उपयोग करने पर भी विचार किया है, लेकिन यह काफी काम नहीं करेगा और यह एक हैक का थोड़ा सा है।

इसे संभालने का सही तरीका क्या है?

Answer 1

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

<Directory Id="MYDIR" Name="MyDir"> 
    <Component Id="update.cmd" Guid="YOUR-GUID"> 
     <File Id="update.cmd" Name="update.cmd" KeyPath="yes" 
       Source="source\update.cmd" /> 
    </Component> 
</Directory> 

<CustomAction Id='RunUpdate' Directory='MYDIR' 
     ExeCommand='[SystemFolder]cmd.exe /c update.cmd' Return='ignore'/> 

<InstallExecuteSequence> 
    <Custom Action='RunUpdate' After='InstallFinalize'>NOT Installed</Custom> 
</InstallExecuteSequence> 

Answer 2

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

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

उदाहरण के लिए, आरपीएम व्यवहार "मरम्मत" पर क्या करता है। उपयोगकर्ता डेटा को रास्ते से बाहर कॉपी करें और इसे एक अच्छी फ़ाइल से प्रतिस्थापित करें? यह शायद सही 60% - 80% सही है। और अनइंस्टॉल करें, फ़ाइल को हटाया जाना चाहिए? यह मुश्किल है अगर उपयोगकर्ता अगले संस्करण में अपग्रेड करने जा रहा है।

फिर से, यह तय करने के लिए बेहतर है कि कॉन्फ़िगरेशन में उनके बदलावों के साथ क्या करना है। IMHO।