सी # विंडोज़ सेवाओं के लिए क्लिकऑन परिनियोजन?

Question

विंडोज सेवा को तैनात करने में सक्षम होने के लिए कुछ सर्वोत्तम प्रथाएं क्या हैं जिन्हें अपडेट करना होगा?

मेरे पास एक विंडोज सेवा है जिसे मैं तैनात कर दूंगा लेकिन बीटा प्रक्रिया के दौरान कुछ डिबगिंग और नए संस्करणों की आवश्यकता हो सकती है। इसे संभालने का सबसे अच्छा तरीका क्या है? आदर्श रूप में, मैं विंडोज सेवाओं के लिए एक क्लिकऑन-शैली परिनियोजन समाधान ढूंढना चाहता हूं लेकिन मेरी समझ यह है कि यह अस्तित्व में नहीं है। विंडोज सेवा के लिए क्लिकऑन में सबसे नज़दीक क्या हो सकता है?

Answer 1

एक साधारण समाधान जिसका मैं उपयोग करता हूं केवल सेवा को रोकना है और फ़ाइलों को अपने बिन फ़ोल्डर से फाइल फ़ोल्डर में कॉपी करना है।

सेवा को रोकने के लिए एक बैच फ़ाइल, फिर फ़ाइलों को कॉपी करने के लिए एक साथ फेंकना आसान होना चाहिए।

Net stop myService 
xcopy \\myServerWithFiles\*.* c:\WhereverTheServiceFilesAre 
net start myService 

Answer 2

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

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

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

Answer 3

मैं Proxy Design Pattern का उपयोग कर इस पर "प्लगइन" दृष्टिकोण का उपयोग करने का सुझाव दूंगा।

इस पद्धति का उपयोग करते समय, एक स्वतंत्र धागा अद्यतन के लिए एक फ़ोल्डर पर पुष्टि कर सकें। आपको अपनी असेंबली परिनियोजन पर ShadowCopy का उपयोग करने की आवश्यकता होगी। जब आपकी सेवा अपडेट-थ्रेड आपकी सेवा का एक नया संस्करण मुठभेड़ करती है, तो यह वर्तमान उत्पादन असेंबली को अनलोड कर देगी और सेवा को रोक दिए बिना नया संस्करण लोड करेगी। और भी अधिक! यदि आपकी असेंबली में कोई ब्रेकिंग कोड नहीं है, तो आपकी सेवा को कभी भी अंतर नहीं दिखना चाहिए।

Answer 4

मैं एक सामान्य सेटअप प्रोजेक्ट बनाने का सुझाव दूंगा, और उस सेटअप प्रोजेक्ट में विंडोज़ सेवा प्रोजेक्ट आउटपुट जोड़ूंगा।

अधिक जानकारी के लिए कृपया http://support.microsoft.com/kb/816169 देखें।

Answer 5

मेरे पास एक ऐसी प्रणाली है जिसका उपयोग हम यहां काम पर करते हैं जो सेवाओं के साथ बहुत अच्छी तरह से काम करता है। हमारे तैनात सिस्टम में किसी भी समय लगभग 20-30 सेवाएं हैं। काम पर हम टॉपशेल्फ़ नामक एक उत्पाद का उपयोग करते हैं, जिसे आप यहां देख सकते हैं http://topshelf-project.com/

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

डी एक कमांड चलाया जाता है: \ सेवाएं \ ServiceName.exe Core.Profiles.Debug या
डी: \ सेवाएं \ ServiceName.exe Core.Profiles।अलग-अलग लॉगिंग कॉन्फ़िगरेशन प्राप्त करने के लिए उत्पादन

।

हमारी बिल्ड स्क्रिप्ट हमारी प्रत्येक सेवा के लिए install.cmd और uninstall.cmd स्क्रिप्ट बनाता है जो हम करते हैं, हम फ़ाइलों को सर्वर पर प्रतिलिपि बनाते हैं और स्क्रिप्ट चलाते हैं। अगर हम डीबग आउटपुट देखना चाहते हैं तो हम सेवा को रोकते हैं और एक्सई पर डबल क्लिक करते हैं और हमें सभी आउटपुट पढ़ने के लिए कंसोल मिलता है।

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

हालांकि, अगर आपको 100% सेवा उपलब्धता की आवश्यकता है तो मेरा सुझाव एक अनावश्यक प्रणाली है। कोई फर्क नहीं पड़ता कि आप अपडेट के लिए अपनी सेवा को कैसे कॉन्फ़िगर करते हैं, आप स्वचालित विफलता प्रणाली के बिना डाउनटाइम के कारण हार्डवेयर विफलता से बच नहीं सकते हैं। यदि कहा गया था कि सिस्टम स्थापित किया गया था तो मेरी अनुशंसित अद्यतन रणनीति 1 नोड को बंद करने, अपडेट करने, परीक्षण करने, दूसरे नोड को बंद करने, अद्यतन करने, परीक्षण करने और दूसरी नोड को चालू करने के लिए चालू होगी। आप यह सब एक सरल लिपि के साथ कर सकते हैं। यह आपकी आवश्यकता से अधिक जटिल प्रणाली हो सकती है, लेकिन यदि आप एक साधारण पुनरारंभ के लिए ऑफ़लाइन सेवा नहीं ले सकते हैं जिसमें 5 सेकंड लगते हैं तो आपको हार्डवेयर समस्याओं से निपटने के लिए वास्तव में कुछ सिस्टम की आवश्यकता होती है क्योंकि मैं गारंटी दे सकता हूं कि यह अंत में होगा।