एकाधिक इंस्टेंस और web.configs के साथ सिंगल एएसपीनेट साइट

Question

हमारे पास आईआईएस सर्वर पर चलने वाली एक विरासत एएसपीनेट संचालित साइट है, साइट को केंद्रीय टीम द्वारा विकसित किया गया था और इसका उपयोग कई ग्राहकों द्वारा किया जाता है। प्रत्येक ग्राहक के पास साइट की एएसपीएक्स फाइलों और वेब.कॉन्फिग फ़ाइल की अपनी प्रतिलिपि होती है। इससे समस्याएं पैदा हो रही हैं क्योंकि स्रोत एएसपीएक्स फाइलों की प्रतियों के लिए अच्छी तरह से समर्थन इंजीनियरों द्वारा किए गए परिवर्तन केंद्रीय स्रोत में वापस नहीं जा रहे हैं, इसलिए हमारा कोड बेस अलग हो रहा है। हमारेएप्लिकेशन/स्रोत aspx & डिफ़ॉल्ट web.config
Customer1/स्रोत aspx & web.config
Customer2/स्रोत aspx & web.config
Customer3/स्रोत aspx & web.config
: हमारे वर्तमान फ़ोल्डर संरचना तरह दिखता है Customer4/स्रोत aspx & web.config
...

यह कुछ मैं प्रत्येक ग्राहक सिर्फ एक स्वनिर्धारित web.config फ़ाइल होने और सभी ग्राहकों के एसी साझा करने के लिए बदलना चाहते हैं है स्रोत फाइलों के ommon सेट। तो कुछ की तरह: हमारेएप्लिकेशन/स्रोत aspx & डिफ़ॉल्ट web.config
Customer1/web.config
Customer2/web.config
Customer3/web.config
Customer4/web.config
...

तो मेरा सवाल यह है कि, मैं इसे कैसे स्थापित करूं? मैं एएसपीनेट और आईआईएस के लिए नया हूं क्योंकि मैं आमतौर पर घर पर PHP और apache का उपयोग करता हूं लेकिन हम यहां एएसपीनेट और आईएसएस का उपयोग करते हैं।

---

स्रोत नियंत्रण प्रयोग किया जाता है और मैं समर्थन इंजीनियरों का प्रशिक्षण प्राप्त करना चाहते हैं लेकिन वहाँ किसी भी तरह से स्रोत aspx फ़ाइलों की कई प्रतियां होने से बचाने के लिए है? मुझे उस तरह के नकल से नफरत है!

Answer 1

यदि आप एकल ऐप इंस्टेंस पर मृत-सेट हैं, तो आप अपने एकल web.config में एक कस्टम कॉन्फ़िगरेशनसेक्शन का उपयोग करने के बाद जो कर रहे हैं उसे पूरा कर सकते हैं। मूल बातें के लिए देखें:

• http://haacked.com/archive/2007/03/12/custom-configuration-sections-in-3-easy-steps.aspx
• http://msdn.microsoft.com/en-us/library/2tw134k3.aspx

उदाहरण एक्सएमएल हो सकता है:

<YourCustomConfigSection> 
    <Customers> 
    <Customer Name="Customer1" SomeSetting="A" Another="1" /> 
    <Customer Name="Customer2" SomeSetting="B" Another="2" /> 
    <Customer Name="Customer3" SomeSetting="C" Another="3" /> 
    </Customers> 
</YourCustomConfigSection> 

अब आप अपने ConfigSection गुण में

, बेनकाब नाम, SomeSetting, और एक और। जब संपत्ति का उपयोग या सेट किया जाता है, तो उपयोग करने के लिए निर्णय लेने के लिए एक शर्त (अनुरोध डोमेन या कुछ और जो विशिष्ट रूप से ग्राहक की पहचान करता है) का उपयोग करें।

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

Answer 2

बाहरी स्रोत नियंत्रण एप्लिकेशन का उपयोग करें और आवश्यकतानुसार अपडेट रोलिंग रखें।

वास्तव में एक अच्छा विचार नहीं है कि आपकी लाइव साइट को वास्तविक समय में समर्थन इंजीनियरों द्वारा अद्यतन किया जाए।

Answer 3

मुझे पता है कि यह परेशान प्रतीत हो सकता है, लेकिन नकल वास्तव में एक अच्छी बात है। यहां समस्या आपकी प्रक्रिया के साथ है, सिस्टम के सेटअप के तरीके से नहीं।

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

आपको हर जगह तैनात करने के लिए अपनी प्रक्रिया बदलने के लिए देखना चाहिए। इससे लंबे समय तक आपके लिए सब कुछ बहुत आसान हो जाएगा।

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

आपके सिस्टम को काम करने के लिए, आपको एप्लिकेशन को कॉन्फ़िगर करने के लिए कॉन्फ़िगर करने वाली फ़ाइल को पूर्ववत करने में सक्षम होना चाहिए, जो उपयोगकर्ता से किसी प्रकार के इनपुट के बिना संभव नहीं है।

Answer 4

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

Answer 5

यदि मैं सही ढंग से समझता हूं, ऐसा लगता है कि आपके पास एकाधिक तैनाती है (प्रत्येक ग्राहक के लिए एक) जहां केवल अंतर ही web.config है, है ना?

सबसे पहले, हालांकि मुझे आपकी अनूठी स्थिति नहीं पता, मैं आम तौर पर आपको अलग-अलग इंस्टॉलेशन के साथ रहने का आग्रह करता हूं। यह आमतौर पर अधिक लचीलापन की अनुमति देता है। मेरे सिर के ऊपर से: क्या आप कभी भी अनुकूलन, या विभिन्न संस्करणों को चलाने वाले विभिन्न ग्राहकों के पास जा रहे हैं? क्या आप सुनिश्चित कर रहे हैं? यहां लचीला रहने का सबसे आसान तरीका अलग-अलग इंस्टॉलेशन के साथ चलना है।

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

उसने कहा, मान लीजिए कि आप इसके साथ आगे बढ़ना चाहते हैं।

आपने यह नहीं कहा कि सभी ग्राहक एक आम डेटाबेस साझा करते हैं, लेकिन मैं नहीं सोच रहा हूं, क्योंकि उस प्रकार की प्रणाली को डिजाइन करना अक्सर अतिरिक्त जटिलता के लायक नहीं है (जो कि किसी भी आकार की प्रणाली में गंभीर हो सकता है) इसलिए लोग अक्सर उन्हें अलग रखने का विकल्प चुनते हैं।

इसका मतलब यह है कि आपने कहीं अपनी कनेक्शन स्ट्रिंग को स्टोर किया है। आमतौर पर यह web.config होगा ... तो यह हमारी योजना को तोड़ने लगता है।

वास्तव में, इस स्थिति का स्पष्ट लालित्य लगभग चुनौतियों से लगभग हमेशा जंगली रूप से ऑफसेट होता है। अगर मैंने इसके बारे में काफी सोचा था, तो शायद मैं एक और डेटाबेस पेश करके इस तरह से एक रास्ता खोज सकता हूं जो समझदारी से कनेक्शन स्ट्रिंग का प्रबंधन करता है या शायद आपकी सभी लॉगिन जानकारी को web.config में रखता है (जो संभव है लेकिन ... आदर्श नहीं है) हालांकि, मेरा आंत कहता है कि काम बर्बाद हो जाएगा क्योंकि कुछ दिन आप इस बात पर वापस आ जाएंगे कि आप इसे कैसे कर रहे हैं।

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

मुझे बताएं कि मुझे कुछ याद आ रहा है!

Answer 6

ठीक है, आप हार्डलिंक्स का उपयोग करने का प्रयास कर सकते हैं: http://msdn.microsoft.com/en-us/library/aa365006.aspx ... आपने इसके लिए पूछा।

एक और सवाल है कि ब्याज की हो सकती है: Techniques For Distributing ASP.NET User Controls Across Projects

Answer 7

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

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

Answer 8

मैं इसे लागू कर रहा हूं जैसा कि हम बोलते हैं।

मुख्य web.config में, मेरे पास प्रति स्थापना 1 आइटम है। यह मुझे प्रत्येक क्लाइंट (और कस्टम मास्टरपेज, सीएसएस, छवियों, आदि) के लिए बनाए गए कस्टम कॉन्फ़िगरेशन फ़ाइल की ओर इंगित करता है।

WebConfigurationManager.OpenWebConfiguration का उपयोग करके, मैं अपने उपनिर्देशिका में नए वेब कॉन्फिगर खोलता हूं। मैं सिस्टम.Web.HttpContext.Current.Request.Url.OriginalString का उपयोग कर उपयोग करने के लिए कौन सा उपयोग करना चाहता हूं, और यूआरएल को निर्धारित करता हूं जो मुझे बुलाता है। उस यूआरएल के आधार पर, मुझे पता है कि कौन सा web.config उपयोग करना है।

उस बिंदु से ग्राहक सभी एक ही कोडबेस का उपयोग करते हैं। उनके पास भी अपने डेटाबेस हैं।

जब हम अपडेट करते हैं तो 30-40 इंस्टॉलेशन अपडेट करने का विचार मुझे मौत से डराता है। हम 30-40 कोडबेस का समर्थन नहीं करना चाहते हैं, इसलिए मास्टर पेज, सीएसएस और छवियों से परे अनुकूलन नहीं होगा।

मैंने एक कस्टम क्लास lib लिखा है जो जानता है कि उचित वेब कॉन्फ़िगर पर कैसे स्विच करें, और हमारे सभी सेटिंग्स के साथ बनाए गए कस्टम सेक्शन को पढ़ें।

मेरे पास अब एकमात्र मुद्दा फॉर्म प्रमाणीकरण कुकी है। मुझे इसे भी स्विच करने में सक्षम होना चाहिए। दुर्भाग्य से, नाम के लिए संपत्ति केवल