windows - जब-और क्यों-आपको विंडोज रजिस्ट्री में डेटा स्टोर करना चाहिए?




registry (10)

(चर्चा के देर से लेकिन) संक्षिप्त उत्तर: समूह नीति।

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

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

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

अपने स्वयं के अनुप्रयोगों को लिखते समय, क्या - अगर कुछ भी - क्या मुझे पुरानी शैली की कॉन्फ़िगरेशन फ़ाइलों की बजाय रजिस्ट्री में रखना चुनना चाहिए, और क्यों?


.NET में वास्तव में कभी ज़रूरत नहीं है।

यहां 2 उदाहरण दिए गए हैं जो यह दिखाने के लिए प्रोजेक्ट प्रोटीज़ का उपयोग कैसे करें।

ये उदाहरण विंडोज उपयोगकर्ता प्रोजेक्ट प्रॉपर्टीज द्वारा करते हैं, लेकिन यह एप्लिकेशन द्वारा भी किया जा सकता है / किया जा सकता है।

यहां अधिक:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE


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

मैं विचार के स्कूल से आया हूं जो कहता है कि जहां भी इसे स्थापित किया जाता है, वहां से एक प्रोग्राम को चलाने योग्य होना चाहिए, कि स्थापना मशीन के भीतर पूरी तरह से चलने योग्य होनी चाहिए, या यहां तक ​​कि किसी अन्य मशीन तक भी चलाना चाहिए और इसके चलते प्रभावित नहीं होना चाहिए।

कोई कॉन्फ़िगर करने योग्य विकल्प, या आवश्यक डीएलएस इत्यादि, अगर उन्हें साझा नहीं किया जाता है, तो स्थापना निर्देशिका की उपनिर्देशिका में रहना चाहिए, ताकि संपूर्ण स्थापना आसानी से स्थानांतरित हो।

मैं कार्यक्रमों की तरह बहुत छोटी उपयोगिता का उपयोग करता हूं, इसलिए यदि इसे यूएसबी स्टिक पर स्थापित नहीं किया जा सकता है और किसी अन्य मशीन में प्लग किया जा सकता है और बस चलाया जाता है, तो यह मेरे लिए नहीं है।


क्या आप दुनिया की कुछ विंडो स्थिति और Windows रजिस्ट्री में हाल ही में उपयोग की जाने वाली वस्तुओं की एक सूची स्टोर करते हैं, तो क्या दुनिया खत्म हो जाएगी? यह अभी तक मेरे लिए ठीक काम किया है।

HKEY-CURRENT-USER छोटी मात्रा में छोटे उपयोगकर्ता डेटा को स्टोर करने के लिए एक शानदार जगह है। यही वह है। ऐसा लगता है कि मूर्खतापूर्ण अपने उद्देश्य के उद्देश्य से उपयोग नहीं करना है क्योंकि दूसरों ने इसका दुरुपयोग किया है।


माइक्रोसॉफ्ट नीति:

  • विंडोज 95 से पहले, हमने एप्लिकेशन डेटा के लिए आईएनआई फाइलों का इस्तेमाल किया था।
  • विंडोज 95 में - एक्सपी युग, हमने रजिस्ट्री का इस्तेमाल किया।
  • विंडोज विस्टा से, हम आईएनआई फाइलों का उपयोग करते हैं हालांकि वे अब एक्सएमएल आधारित हैं।

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


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

  • आपके एप्लिकेशन को अनइंस्टॉल करने के बाद आपके एप्लिकेशन का ट्रेस छोड़ना (उदाहरण के लिए एप्लिकेशन को फिर से स्थापित करने के मामले में उपयोगकर्ता की वरीयताओं को याद रखें)
  • विभिन्न अनुप्रयोगों के बीच कॉन्फ़िगरेशन सेटिंग्स साझा करें - घटक

रजिस्ट्री पढ़ता है और लिखता है थ्रेडसेफ लेकिन फाइलें नहीं हैं। तो यह इस बात पर निर्भर करता है कि आपका प्रोग्राम सिंगल थ्रेडेड है या नहीं।


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


कब - आपको विरासत एकीकरण के कारण मजबूर होना पड़ता है या क्योंकि आपके ग्राहक का सिसडमिन कहता है "यह ऐसा होगा" या क्योंकि आप एक पुरानी भाषा में विकसित हो रहे हैं जो एक्सएमएल का उपयोग करना अधिक कठिन बनाता है।

क्यों - मुख्य रूप से क्योंकि रजिस्ट्री को पोर्टेबल के रूप में पोर्टेबल नहीं है क्योंकि एप्लिकेशन के बगल में बैठे कॉन्फ़िगरेशन फ़ाइल की प्रतिलिपि बनाई जाती है (और इसे लगभग वही कहा जाता है)।

यदि आप .Net2 + का उपयोग कर रहे हैं तो आपको App.Config और User.Config फ़ाइलें मिल गई हैं और आपको रजिस्ट्री में DLL को पंजीकृत करने की आवश्यकता नहीं है, इसलिए इससे दूर रहें।

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

  • समस्या: अनुप्रयोगों को विन्यास योग्य सेटिंग्स की आवश्यकता है।
  • समाधान: Windows फ़ोल्डर में फ़ाइल (WIN.INI) में स्टोर सेटिंग्स - समूह डेटा (Win3.0) में सेक्शन हेडिंग का उपयोग करें।
  • समस्या: WIN.INI फ़ाइल बहुत बड़ी हो गई (और गन्दा हो गया)।
  • समाधान: एप्लिकेशन के रूप में उसी फ़ोल्डर में आईएनआई फ़ाइलों में स्टोर सेटिंग्स (Win3.1)।
  • समस्या: उपयोगकर्ता-विशिष्ट सेटिंग्स की आवश्यकता है।
  • समाधान: उपयोगकर्ता की विंडो निर्देशिका में उपयोगकर्ता-विशिष्ट आईएनआई फ़ाइलों में उपयोगकर्ता-सेटिंग्स स्टोर करें (Win3.11) या एप्लिकेशन आईएनआई फ़ाइल में उपयोगकर्ता-विशिष्ट अनुभाग।
  • समस्या: सुरक्षा - कुछ एप्लिकेशन सेटिंग्स को केवल पढ़ने की आवश्यकता है।
  • समाधान: सुरक्षा के साथ-साथ उपयोगकर्ता-विशिष्ट और मशीन-व्यापी अनुभाग (Win95) के साथ रजिस्ट्री।
  • समस्या: रजिस्ट्री बहुत बड़ी हो गई।
  • समाधान: उपयोगकर्ता-विशिष्ट रजिस्ट्री उपयोगकर्ता के अपने "एप्लिकेशन डेटा" फ़ोल्डर में user.dat पर ले जाया गया और केवल लॉगिन (WinNT) पर लोड हो गया।
  • समस्या: बड़े कॉर्पोरेट वातावरण में आप एकाधिक मशीनों पर लॉग ऑन करते हैं और प्रत्येक को एक सेट करना होगा।
  • समाधान: स्थानीय (स्थानीय सेटिंग्स) और रोमिंग (एप्लिकेशन डेटा) प्रोफाइल (WinXP) के बीच अंतर करें।
  • समस्या: xcopy को अन्य .NET जैसे अनुप्रयोगों को तैनात या स्थानांतरित नहीं किया जा सकता है।
  • समाधान: एप्लिकेशन के रूप में एक ही फ़ोल्डर में APP.CONFIG एक्सएमएल फ़ाइल - पढ़ने के लिए आसान, आसान बनाने के लिए आसान, स्थानांतरित करने में आसान, बदलते समय ट्रैक कर सकते हैं (.Net1)।
  • समस्या: अभी भी उपयोगकर्ता-विशिष्ट डेटा को समान (यानी xcopy तैनाती) तरीके से स्टोर करने की आवश्यकता है।
  • समाधान: USER.CONFIG XML फ़ाइल उपयोगकर्ता के स्थानीय या रोमिंग फ़ोल्डर में और दृढ़ता से टाइप (.Net2)।
  • समस्या: CONFIG फ़ाइलें केस-संवेदी (इंसानों के लिए सहज नहीं) हैं, बहुत विशिष्ट खुले / बंद "टैग" की आवश्यकता होती है, कनेक्शन स्ट्रिंग को रन-टाइम पर सेट नहीं किया जा सकता है, सेटअप प्रोजेक्ट सेटिंग्स (जैसे रजिस्ट्री के रूप में आसानी से) नहीं लिख सकते हैं, आसानी से निर्धारित नहीं कर सकते user.config फ़ाइल और उपयोगकर्ता सेटिंग्स को प्रत्येक नए संशोधन के साथ उड़ाया जाता है।
  • समाधान: रनटाइम पर कनेक्शन स्ट्रिंग सेट करने के लिए ITEM सदस्य का उपयोग करें, इंस्टॉलर के दौरान App.Config को बदलने के लिए इंस्टॉलर क्लास में कोड लिखें और उपयोगकर्ता सेटिंग नहीं मिलने पर एप्लिकेशन सेटिंग्स को डिफॉल्ट के रूप में उपयोग करें।

  • मूल रूप से (WIN3) कॉन्फ़िगरेशन Windows निर्देशिका में WIN.INI फ़ाइल में संग्रहीत किया गया था।
  • समस्या: WIN.INI बहुत बड़ा हो गया।
  • समाधान (विन 31): कार्यक्रम के रूप में एक ही निर्देशिका में व्यक्तिगत आईएनआई फाइलें।
  • समस्या: वह प्रोग्राम किसी नेटवर्क पर स्थापित किया जा सकता है और कई लोगों द्वारा साझा किया जा सकता है।
  • समाधान (Win311): उपयोगकर्ता की विंडो निर्देशिका में व्यक्तिगत आईएनआई फ़ाइलें।
  • समस्या: कई लोग एक विंडोज फ़ोल्डर साझा कर सकते हैं, और इसे वैसे भी पढ़ा जाना चाहिए।
  • समाधान (Win95): प्रत्येक उपयोगकर्ता के लिए अलग-अलग अनुभागों के साथ रजिस्ट्री।
  • समस्या: रजिस्ट्री बहुत बड़ी हो गई।
  • समाधान (विनएक्सपी): व्यक्तिगत डेटा के बड़े ब्लॉक उपयोगकर्ता के अपने एप्लिकेशन डेटा फ़ोल्डर में स्थानांतरित हो गए।
  • समस्या: बड़ी मात्रा में डेटा के लिए अच्छा है, बल्कि छोटी मात्रा के लिए जटिल है।
  • समाधान (.NET): एपीआई के साथ इसे पढ़ने के लिए एप्लिकेशन के रूप में उसी फ़ोल्डर में .config (Xml) फ़ाइलों में संग्रहीत निश्चित, केवल-पढ़ने वाले डेटा की छोटी मात्रा। (पढ़ें / लिखें या उपयोगकर्ता विशिष्ट डेटा रजिस्ट्री में रहता है)






registry