.NET विंडोज सेवा के लिए सेटिंग्स को संग्रहीत करने के लिए सर्वोत्तम अभ्यास: सेवा प्रॉपर्टी सेटिंग्स, सीरियलाइजेशन,

Question

मैं एक .NET विंडोज सेवा पर काम कर रहा हूं, जहां मैं सेटिंग्स को स्टोर करने की कोशिश कर रहा हूं जिसका उपयोग तब किया जाएगा जब सेवा शुरू हो जाएगी और जब यह हो चल रहा है। मैंने एसओ पर पोस्ट के माध्यम से खोज की है और पाया है कि परियोजना के गुणों में सेटिंग्स का उपयोग कंसोल और विनफॉर्म अनुप्रयोगों के उपयोग के लिए बहुत अच्छा है। हालांकि, Google और SO चुप हैं जब यह इन सेटिंग्स को विंडोज सेवा के साथ संग्रहीत करने से संबंधित है।

क्या कोई भी जानता है कि .NET सेवा में इन सेटिंग्स का उपयोग करना उचित है या नहीं? यदि नहीं, तो मेरी अगली सबसे अच्छी पसंद Serialization है? क्या किसी के पास सेवा में सेटिंग्स के लिए व्यावहारिक उपयोग हैं और पाया है कि एक विशिष्ट विधि का उपयोग करना सबसे अच्छा है?

Answer 1

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

हमारे पास इस मुद्दे का एक उदाहरण था: मैंने वेब सेवा उपभोग करने वाले कोड का परीक्षण करने के लिए एक परीक्षण सर्वर पर एक वेब सेवा में अपनी विकास मशीन की ओर इशारा किया। जब कोड हमारे परीक्षण सर्वर पर ले जाया गया था, तो कोई समस्या प्रकट नहीं हुई - क्योंकि परीक्षण सर्वर को उसी परीक्षण सेवा पर उसी वेब सेवा पर अभी भी इंगित किया गया था। हालांकि, जब हमने एप्लिकेशन को उत्पादन सर्वर पर ले जाया और उत्पादन सर्वर पर इंगित करने के लिए web.config को फिर से कॉन्फ़िगर किया, तो हमें खराब परिणाम मिलना शुरू हो गया। यह तय करने के लिए काफी प्रयास किए गए कि भले ही हमने वेब सर्वर के उत्पादन सर्वर के कार्यान्वयन पर इंगित करने के लिए एप्लिकेशन को फिर से कॉन्फ़िगर किया था, फिर भी यह परीक्षण सर्वर पर वेब सेवा से कनेक्ट हो रहा था। यह तब तक नहीं था जब तक हमने सेटिंग्स को बदल दिया। मेरी विकास मशीन पर सेटिंग्स और उस एप्लिकेशन को पुनः संकलित किया जो उसने काम किया था। इसके अलावा, हमने यह भी ध्यान दिया कि यदि विफल होने की बजाय, उत्पादन वेब सेवा से कनेक्ट होने वाली DNS समस्याएं थीं, तो यह सेटिंग में निर्दिष्ट मूल सेटिंग्स पर वापस आ गईं, जब से हमने हमारे एप्लिकेशन में वेब सेवा प्रॉक्सी बनाई थी - प्रॉक्सी जेनरेटर वास्तव में उन्हें हार्ड कोड। नतीजतन जब नेटवर्क आबादी थी, आसानी से कनेक्शन विफलताओं का निदान करने की बजाय, यह बस परीक्षण सर्वर पर वापस गिर गया और हमें समझ में नहीं आया डेटा समस्याएं शुरू हुईं। मुझे यकीन नहीं है कि यह एक ज्ञात समस्या है या यदि यह तय किया गया है, लेकिन यह निश्चित रूप से कुछ है जिसके बारे में आपको अवगत होना चाहिए।

नतीजतन, तब से, मैं हमेशा स्थिर करने के लिए सेवा गुण सेट और एक सहायक विधि का इस्तेमाल किया web.config सीधे से सही सेटिंग्स को पढ़ने के लिए और उन्हें प्रोग्राम के रूप में लिखा इस समस्या को नाकाम करने के लिए लगता है के रूप में किया है।

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

Answer 2

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

Answer 3

मुझे प्रोजेक्ट के गुणों में सेटिंग का उपयोग न करने का कोई कारण नहीं दिखता है क्योंकि आप WinForms ऐप के लिए करेंगे। हम यह करते हैं, और यह ठीक काम करता है।

Answer 4

मैं सामान्य रूप से जानकारी मैं अपने सेवा यानी बंदरगाह में की जरूरत है स्टोर करने के लिए रजिस्ट्री का उपयोग आदि

string lsbkey = @"Software\mycompany\adas"; 

RegistryKey adaskey = Registry.LocalMachine.OpenSubKey(lsbkey, false); 

try 
{ 
    object regip = adaskey.GetValue("IP"); 
    object regport = adaskey.GetValue("PORT"); 
    localip = regip.ToString(); 
    localport = int.Parse(regport.ToString()); 
} 
catch (NullReferenceException ne) 
{ 
    localip = null; 
    localport = 0; 
    writelog(@"Aborting Service, IP or PORT doesn't exist in \local machine\software\mycompany\adas : "+ne.Message); 
    status = 0; 

}