विकास बनाम उत्पादन: कनेक्शन स्ट्रिंग्स

Question

मैं SQL सर्वर को एक अलग मशीन पर ले जाने की प्रक्रिया में हूं। वर्तमान में हम एक ही बॉक्स पर हमारे वेब सर्वर और एसक्यूएल सर्वर चला रहे हैं। तो हमारे पास आईआईएस और एसक्यूएल सर्वर के साथ एक उत्पादन सर्वर है और फिर एक अलग विकास सर्वर है जो इस सेटअप को प्रतिबिंबित करता है।

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

अब मैं एक ही बॉक्स (माईडीबी, माईडीबी-देव) पर डीबी दोनों चलाने की सोच रहा हूं। क्या हर बार जब हम तैनाती या संकलन करते हैं तो web.config और app.config को संपादित किए बिना इसे करने का कोई आसान तरीका है? क्या यह कुछ दृश्य स्रोत सुरक्षित संभाल सकता है?

Answer 1

यहां उपयोग किया गया समाधान है। वेब मेंकॉन्फ़िग, जगह निम्नलिखित "शामिल हैं" पंक्ति:

<connectionStrings configSource="WebCS.config"/> 

फिर, WebCS.config फ़ाइल बनाने और यह डालें:

<connectionStrings> 
<add name="ConnString" 
    connectionString="Data Source=YourServer;Initial Catalog=YourDB;etc.. 
    providerName="System.Data.SqlClient"/> 
</connectionStrings> 

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

Answer 2

मैं यहां आपके प्रश्न को पूरी तरह से समझ नहीं सकता हूं, लेकिन ऐसा लगता है कि जब आप एप्लिकेशन को तैनात करते हैं, तो आप वेब.कॉन्फिग को फिर से तैनात नहीं कर सकते हैं जब तक कि web.config में कोई बदलाव नहीं किया जाता है । दूसरे शब्दों में, सभी फ़ाइलों को पर को web.config फ़ाइल को छोड़कर निर्देशिका में कॉपी करें।

यदि आपको तैनाती के बीच web.config फ़ाइल को बदलना है, तो आपको प्रत्येक सर्वर के लिए web.config को संपादित करने की आवश्यकता होगी।

वैकल्पिक रूप से, आप web.config के अलावा कनेक्शन स्ट्रिंग को स्टोर करने के लिए प्रत्येक मशीन पर एक और स्थान पा सकते हैं।

Answer 3

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

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

स्रोत नियंत्रण के साथ, सामान्य अभ्यास वेब.config को बाहर करना है और एक टेम्पलेट फ़ाइल है जिसे कॉन्फ़िगरेशन फ़ाइल बनाने के आधार के रूप में उपयोग किया जा सकता है, उदा। web.config.template। Web.config में संरचनात्मक परिवर्तन करते समय, आपको web.config.template में परिवर्तन करना चाहिए, फिर dev और prod के लिए इसकी प्रतियां बनाना चाहिए, और इसके अनुसार dev और prod सेटिंग्स को लागू करें।

Answer 4

मैं निर्माण और तैनाती के लिए NANT का उपयोग करता हूं। मैं .config.template नामकरण सम्मेलन का उपयोग कर टेम्पलेट्स में अपनी .config फ़ाइलों को बना देता हूं। मेरे पास "पर्यावरण" नाम की एक NANT संपत्ति है जिसे मैंने कमांड लाइन कॉल से NANT पर सेट किया है। मेरे build.xml के शीर्ष पर, मैंने "पर्यावरण" संपत्ति (जैसे स्विच स्टेटमेंट) के आधार पर "db.connectionstring" संपत्ति सेट की है। निर्माण कार्य में, मैं निर्माण निर्देशिका आउटपुट के लिए टेम्पलेट में "db.connectionstring" स्ट्रिंग को स्पॉट में धक्का देने के लिए grep का उपयोग करता हूं। इस तरह, मुझे केवल कॉल करने की आवश्यकता है:

nant -D:environment=dev 

यह .config फ़ाइलों का एक dev-विशिष्ट सेट प्राप्त करता है।

आप ग्रेप पसंद नहीं है, इस का पालन करें:

http://www.haidongji.com/2008/11/11/use-nant-to-replace-values-in-other-xml-config-files/

एक्सएमएल फाइल के लिए यह केवल काम करता है। Grep अधिक सामान्य है। मेरे पास वास्तव में तैनाती पर्यावरण के आधार पर अलग-अलग डेटाबेस नाम हैं, और grep मुझे पर्यावरण के आधार पर SQL डेटाबेस में विभिन्न डेटाबेस नाम डालने देता है।

Answer 5

web.config में बाहर की जांच ConnectionStrings तत्व की configSource विशेषता

आसान पर्याप्त

Answer 6

करना चाहिये कि बस तो मैं स्पष्ट कर रहा हूँ, अपने वर्तमान वातावरण दो सर्वर, यानी

है

देव एप्लिकेशन/DB सर्वर
उत्पादन एप्लिकेशन/DB सर्वर

और आप इस

है जैसे कि यह कुछ बनाने की सोच रहे हैं

अनुप्रयोग सर्वर (देव + उत्पादन)
डीबी सर्वर (देव + उत्पादन)

अगर ऐसी बात है, मैं DB और दो अलग-अलग सर्वर में आवेदन अलग करने के लिए आप हूं - जब एक ही सर्वर वातावरण से आगे बढ़ यह पहला कदम है क्योंकि यह बाद में आसान अपग्रेड के लिए अनुमति देता है यदि आपको एक प्रदर्शन के लिए एक डीबी सर्वर के सामने एकाधिक डीबी सर्वर या (अधिक सामान्यतः) लोड बैलेंस एकाधिक वेबसर्वर क्लस्टर करने की आवश्यकता होती है।

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

Answer 7

क्या आप वेब कनेक्शन कॉन्फ़िगर में सभी कनेक्शन स्ट्रिंग डाल सकते हैं और फिर एप्लिकेशन में मुख्य बिंदु पर यह निर्धारित कर सकते हैं कि ऐप सर्वर के आधार पर किस का उपयोग करना है?

Answer 8

विकास के लिए, Web.Debug.config फ़ाइल का उपयोग करें, और उत्पादन के लिए, Web.Release.config का उपयोग करें। प्रत्येक अपनी अलग कनेक्शन स्ट्रिंग को परिभाषित कर सकता है।