c# वर्तमान उपयोगकर्ता प्रोफ़ाइल पर फ़ोल्डर और फ़ाइल बनाएं, व्यवस्थापक प्रोफ़ाइल से




windows wix (3)

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


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

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

यह कार्यक्षमता उस स्थिति से संबंधित है जहां उपयोगकर्ता खाते हैं जो अभी तक नहीं बनाए गए हैं, इसलिए स्पष्ट रूप से आप अभी तक उनके प्रोफ़ाइल फ़ोल्डर में फाइलें नहीं डाल सकते हैं।

दूसरों की तुलना में यह सबसे अच्छा तरीका है या नहीं, यह ऐप के विशिष्ट विवरणों पर निर्भर करेगा।


मैं बस संक्षेप में बताऊंगा कि दूसरों ने मूल रूप से क्या उल्लेख किया है, fleshing चीजों को "थोड़ा संदर्भ" बनाने की कोशिश कर रहे हैं।

शायद एक महत्वपूर्ण tidbit के लिए नीचे Win10 रैंसमवेयर संरक्षण सुविधा के उल्लेख पर एक नज़र है कि यह विंडोज परिवर्तन उपयोगकर्ता-प्रोफ़ाइल फ़ाइलों की तैनाती को कैसे प्रभावित कर सकता है

COMMON APPROACHES

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

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

    • 1: प्रति-मशीन टेम्पलेट

      • प्रति- उपयोगकर्ता स्थान के लिए कॉन्फ़िगर फ़ाइल स्थापित करें, जो सभी उपयोगकर्ताओं के लिए पठनीय है, फिर फ़ाइल को वहां से कॉपी करें और एप्लिकेशन लॉन्च का उपयोग करके उपयोगकर्ताप्रोफाइल में डाल दें, प्रति उपयोगकर्ता एक बार प्रति-कार्य करने के लिए एप्लिकेशन का उपयोग करें।
      • यह अनुशंसित दृष्टिकोण है। यदि आप इस तरह से एक दृष्टिकोण का उपयोग करने की आवश्यकता है, तो आप प्रति उपयोगकर्ता अद्यतन लागू करने के लिए तर्क के साथ अपने आवेदन को भी अपडेट कर सकते हैं: http://forum.installsite.net/index.php?showtopic=21552
      • जब कॉपी हो रही है तो आप हमेशा सही उपयोगकर्ता संदर्भ में चल रहे होंगे, और आपको जटिल MSI प्रतिरूपण, कंडीशनिंग और अनुक्रमण जटिलताओं के बारे में चिंता करने की ज़रूरत नहीं है।
      • इस दृष्टिकोण का एक अच्छा लाभ यह है कि यह तब भी काम करेगा जब एप्लिकेशन लॉन्च के समय इंस्टॉलेशन स्रोत (MSI) गायब हो।
    • 2: लॉन्च पर फ़ाइल बनाएँ - "आंतरिक चूक"

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

      • MSI स्वयं-मरम्मत का उपयोग करके प्रति उपयोगकर्ता कॉन्फ़िगरेशन फ़ाइल रखें। यह एक विज्ञापित प्रविष्टि बिंदु को लागू करने पर होता है जैसे कि विज्ञापन को लॉन्च करने के लिए उपयोग किए जाने वाले विज्ञापन शॉर्टकट।
      • जिस समय मरम्मत होती है, स्थापना स्रोत तक पहुंच की आवश्यकता होती है। बॉक्स पर अपनी एमएसआई फ़ाइल को कैश करना सुनिश्चित करें।
      • टर्मिनल सर्वर (अक्षम सुविधा) पर स्व-मरम्मत काम नहीं कर सकती है। मुझे यह परीक्षण किए हुए कई साल हो चुके हैं। मुझे यकीन नहीं है कि इन दिनों सर्वर बॉक्स से कैसे कॉन्फ़िगर किए जाते हैं।
      • जब तक कॉन्फ़िगर नहीं किया जाता है, तो अनइंस्टॉल वास्तविक उपयोगकर्ता को चलाने वाले उपयोगकर्ता के लिए कॉन्फ़िगरेशन फ़ाइल की स्थापना रद्द कर सकता है या, गंभीर रूप से, यह एक प्रमुख अपग्रेड के दौरान हो सकता है (जो वास्तव में आपके उत्पाद की स्थापना रद्द करें और पुनर्स्थापित करें)। दूसरे शब्दों में: घटक को स्थायी रूप से सेट करें (और कभी अधिलेखित न करें) - या आपकी फ़ाइल अपग्रेड के दौरान अधिलेखित दिखाई दे सकती है (लेकिन यह वास्तव में अनइंस्टॉल और पुनर्स्थापित है)।
      • HKCU रजिस्ट्री सेटिंग्स के लिए जरूरी नहीं कि आपको इंस्टॉलेशन स्रोत उपलब्ध हो। स्टीफन क्रूगर की व्याख्या की जाँच करें: http://www.msifaq.com/a/1011.htm प्रक्रिया उपयोगकर्ताप्रोफ़ाइल फ़ाइलों की स्थापना को ट्रिगर करने के लिए समान है (लेकिन फिर स्थापना स्रोत की आवश्यकता है)। एक संबद्ध चर्चा - मामले में यह सहायक है
      • हालांकि मेरे द्वारा HKCU\Software\MyCompany\MyApplication\Version\HKCU_KeyPath = [ComputerName] होने पर, मैंने रजिस्ट्री कुंजी पथ मान सेट करने पर विचार किया है: HKCU\Software\MyCompany\MyApplication\Version\HKCU_KeyPath = [ComputerName] ताकि मुख्य पथ मान को "चलती लक्ष्य" बनाया जा सके ताकि स्व-मरम्मत हो जब उपयोगकर्ता एक नए कंप्यूटर में प्रवेश करता है (मौजूदा एचकेसीयू सेटिंग्स में रोमिंग प्रोफाइल लाने के बावजूद) मज़बूती से ट्रिगर किया गया।
      • जैसा कि मैंने कहा, जब से मैंने इस दृष्टिकोण को छोड़ दिया है, तब से अप्रशिक्षित है - क्योंकि यह विंडोज के हर नए अपडेट के लिए निर्भर होना कम विश्वसनीय है। अप्रत्याशित परिणामों के साथ, हर बार कुछ अजीब बदल जाता है।
      • यद्यपि 100% संबंधित नहीं है, मैं उदाहरण के रूप में विंडोज 10 में नई रैंसमवेयर सुरक्षा सुविधा का उल्लेख कर सकता हूं - यह उपयोगकर्ता डेटा फ़ोल्डरों को लिखने की कोशिश कर रहे किसी भी एमएसआई के लिए आंतरायिक रनटाइम त्रुटियों का कारण लगता है। यह देखा जाना बाकी है कि तैनाती की कितनी समस्याएं होंगी - जबकि हम अब तक रुक-रुक कर नतीजे देखते हैं - क्या होगा जब वे डिफ़ॉल्ट रूप से सुविधा को चालू करते हैं?
      • और, ऊपर की तर्ज पर, थर्ड पार्टी सिक्योरिटी सॉफ्टवेयर भी कुछ फाइल सिस्टम एक्टिविटी को ब्लॉक करके तैनाती में रुकावट प्रदान करते हैं और कुछ कारणों से झंडे वाली फाइलें (झूठी सकारात्मक सहित) को स्व-मरम्मत करते हैं, जो कभी भी पूरी नहीं हो सकती हैं व्यर्थ दौड़ना।
      • एक संक्षिप्त सारांश के रूप में , यहां कुछ कारण बताए गए हैं कि यह स्वयं-मरम्मत के माध्यम से उपयोगकर्ता-रहित फ़ाइलों की तैनाती से बचने के लिए अधिक से अधिक उपयोगी हो जाता है:
        • रोमिंग प्रोफाइल जटिलताओं
        • रैंसमवेयर प्रोटेक्शन फ़ीचर हस्तक्षेप
        • सुरक्षा सॉफ्टवेयर हस्तक्षेप (विशेष रूप से गलत मैलवेयर सकारात्मक)।
        • स्वयं की मरम्मत पर टर्मिनल सर्वर प्रतिबंध
        • डेटा रीसेट या सेटिंग्स प्रमुख उन्नयन के दौरान मुद्दों की स्थापना रद्द करें
        • हो सकता है कि आपको वही एहसास मिले जो मुझे मिलता है: और भी बहुत कुछ है, और यह लगातार बिगड़ता रहेगा।
        • मेरे दो सेंट : अपने आवेदन के लिए बेहतर डेटा फ़ाइल प्रबंधन के बारे में तुरंत अपने प्रबंधक से बात करें और तैनाती के दौरान "स्मार्ट" होने के सभी प्रयासों को छोड़ दें। यदि संभव हो तो केवल एमएसआई के साथ प्रति मशीन फ़ाइल को तैनात करें।
        • भविष्य में यह वरीयता संभावना बदल सकती है क्योंकि परिनियोजन तकनीक में परिवर्तन होता है और प्रति उपयोगकर्ता केवल (शायद) ही इंस्टाल किया जाता है।
        • पहले लिखी गई समस्या का लंबा विवरण: MSI का उपयोग करते समय उपयोगकर्ता-प्रोफ़ाइल या HKCU में फ़ाइलों की तैनाती को सीमित करना एक अच्छा विचार क्यों है?
        • और सामान्य रूप से तैनाती की समस्याओं के बारे में पूरी गन्दी बातचीत: मैं अपने वाईएक्स / एमएसआई तैनाती समाधान में सामान्य डिजाइन की खामियों से कैसे बचूँ?
    • 4: सक्रिय सेटअप ( अब अनुशंसित नहीं, कृपया पढ़ें )

      • सक्रिय सेटअप का उपयोग करके कॉन्फ़िगर फ़ाइल को रखें। यह उपयोगकर्ता लॉगिन पर होता है (जो तब लॉगआउट और लॉगिन की आवश्यकता होती है जब तक आप यह सुनिश्चित न करें कि फ़ाइल वर्तमान उपयोगकर्ता प्रोफ़ाइल पर स्थापित है)।
      • यह दृष्टिकोण की एक भिन्नता के प्रभाव में है। आप सभी उपयोगकर्ता द्वारा पठनीय, प्रति फ़ाइल स्थान पर विन्यास फाइल को स्थापित करना चाहिए।
      • फिर आप प्रति उपयोगकर्ता एक बार "कुछ चलाने योग्य" चलाने के लिए रजिस्ट्री में एक कार्य पंजीकृत करते हैं। आप एक बैच फ़ाइल, निष्पादन योग्य, स्क्रिप्ट या मेरे पसंदीदा दृष्टिकोण MSI मरम्मत के रूप में कुछ भी चला सकते हैं जो उपयोगकर्ताप्रोफ़ाइल फ़ाइल को डालने का प्रबंधन करेगा (इस मामले में आपको प्रति मशीन स्थान पर फ़ाइल की आवश्यकता नहीं है, लेकिन पहुंच स्थापना स्रोत के रूप में सक्रिय सेटअप चलाता है)।
      • वर्तमान उपयोगकर्ता के लिए इंस्टॉल के दौरान लगाई गई एक कॉन्फ़िग फ़ाइल को अधिलेखित न करें। या सक्रिय उपयोगकर्ता द्वारा प्रश्न में उपयोगकर्ता के लिए चलाए गए HKCU कुंजी को लिखने के बाद इस उपयोगकर्ता के लिए चलने से सक्रिय सेटअप अक्षम करें (नीचे लिंक देखें)।
      • इस प्रक्रिया को मेरे उत्तर में यहाँ दिया गया है: विंडोज सर्वर 2003 पर हर प्रोफाइल की रजिस्ट्री को अपडेट करने का प्रयास। यह सब एक HKLM कुंजी पर आधारित है जो प्रति उपयोगकर्ता एक बार चलाई जाती है। विस्तार से जुड़े उत्तर की जाँच करें, और वहाँ कुछ बाहरी लिंक हैं जो बहुत अधिक विवरण प्रदान करते हैं।
      • अद्यतन : टर्मिनल सर्वर पर स्थापित करते समय आप सर्वर को "इंस्टॉल मोड" में रखते हैं और फिर प्रति-उपयोगकर्ता रजिस्ट्री प्रविष्टियाँ HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install को लिखी जाती हैं और फिर प्रत्येक उपयोगकर्ता के HKCM को hive में लिखी जाती हैं। वे लॉग इन करते हैं। यह ActiveSetup के साथ संघर्ष कर सकता है - मुझे पता है। मुझे कभी इसका परीक्षण करने का मौका नहीं मिला। टर्मिनल सर्वर के लिए पैकेजिंग आम तौर पर एक समर्पित, विशेषज्ञ सर्वर टीम द्वारा की जाती है।
    • 5: MsiProvideComponent

      • फिल का MsiProvideComponent दिलचस्प है, मैंने कभी इसका इस्तेमाल नहीं किया। मुझे।

क्लो-स्टाइल अप्रोच

  • डेटा भंडारण के साथ प्रतीत होता है कि क्लाउड पर जाने से डेटा फ़ाइल परिनियोजन के लिए सामान्य दृष्टिकोण जल्दी से अप्रचलित हो सकते हैं।

    • 6: सेटिंग्स फ़ाइल डाउनलोड करें

      • सेटिंग फ़ाइल डाउनलोड करें - एक बार आवेदन लॉन्च पर प्रत्येक उपयोगकर्ता के लिए - स्थानीय नेटवर्क डेटाबेस से / साझा करें या इसके बजाय इंटरनेट से - यदि यह एक विकल्प है।
      • दूरस्थ फ़ाइल को एक व्यवस्थापक द्वारा मूल्यों को अद्यतन करने के लिए बनाए रखा जा सकता है यदि नए डिफ़ॉल्ट मान हैं या कुछ को हटाने की आवश्यकता है।
      • आपके एप्लिकेशन द्वारा समझी गई सेटिंग फ़ाइल में कॉन्फ़िगरेशन तंत्र सभी उपयोगकर्ताओं के लिए आवेदन करने के लिए नए "मजबूर" मूल्यों को लागू कर सकता है।
      • HKLM में सर्वरों की सूची के विन्यास की अनुमति दें? पब्लिक प्रॉजेक्ट्स के जरिए MSI में कंफर्टेबल ?
      • या स्थापना के दौरान अपने सेटअप में एक एकल URL सेट करें और उस URL के माध्यम से सर्वर की एक सूची बनाए रखें (आप DNS के माध्यम से इस सर्वर को किस बिंदु पर पुनर्निर्देशित करते हैं ताकि कॉन्फ़िगरेशन फिर से तैनाती के बिना एक sysadmin कार्य है?)। एचकेयू में वर्तमान चयन सेट।
    • 7: रिमोट डेटाबेस से सेटिंग पढ़ें / लिखें

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

सारांश

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

मैं अधिक से अधिक स्थानीय (और अलग-थलग) बनाने के लिए क्लाउड-आधारित दृष्टिकोण पसंद करता हूं उपयोगकर्ता सेटिंग्स अतीत की बात करती हैं - लेकिन मैं शायद ही कभी इस तरह से चीजों को तैनात करने में सक्षम हूं। ये क्लाउड एप्रोच फ़ायरवॉल / प्रॉक्सी समस्याओं और नेटवर्क कनेक्टिविटी समस्याओं के साथ समस्याओं का सामना कर सकते हैं - और शायद कई अन्य चीजें जो मुझे अभी तक पता नहीं हैं (अब डेवलपर्स तैनाती विशेषज्ञों, आदि के बजाय डीबीओ के साथ झगड़ा करेंगे ... ;-))। वितरित कंप्यूटिंग की अपनी कमियाँ हैं: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing । इसके अलावा: क्लाउड-आधारित दृष्टिकोणों में यह अभी भी अनुप्रयोगों के लिए एक अच्छा विचार हो सकता है कि सेटिंग्स को डिस्क में बैकअप की अनुमति दी जाए, इसलिए कुछ फ़ाइल प्रबंधन को स्पष्ट रूप से अभी भी ज़रूरत है - या क्या आप सिर्फ डेटाबेस तालिकाओं के एक जोड़े को निर्यात करते हैं? इसके अलावा: यदि आप अपने एप्लिकेशन का एक परीक्षण संस्करण स्थापित करते हैं, तो आप यह चाह सकते हैं कि यह बिना नेटवर्क कनेक्टिविटी के कार्य कर सके - यदि उपयोगकर्ता बहुत तंग फ़ायरवॉल के पीछे है। एक तकनीकीता के कारण आपके उपयोगकर्ता को आपके एप्लिकेशन की विशेषताओं का परीक्षण करने की अनुमति नहीं देना एक बहुत ही महंगी गलती है।

विकल्प 1 और 2 का महान लाभ यह है कि वे तब भी काम करेंगे जब मरम्मत शुरू होने पर मूल स्थापना मीडिया गायब हो। यह घर और छोटे कार्यालय की तैनाती के लिए विशेष रूप से महत्वपूर्ण है, जहां तैनाती केंद्रीयकृत पैकेज शेयर के बिना लापरवाही से हो सकती है। आप इंस्टालेशन के दौरान सिस्टम पर पूरे MSI को कैश करने के लिए कैशिंग विधियों का उपयोग करके (इंस्टालेशन में उपलब्ध है, मैंने वाईएक्स या एडवांस्ड इंस्टॉलर की जांच नहीं की है) इस समस्या के आसपास काम कर सकते हैं।


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







profiles