एएसपी.NET साइट को तैनात करते समय आप कनेक्शन स्ट्रिंग से कैसे निपटते हैं?

Question

अभी हमारे परीक्षण और उत्पादन डेटाबेस एक ही सर्वर पर हैं, लेकिन विभिन्न नामों के साथ। तैनाती का मतलब वेब डेटाबेस को सही डेटाबेस के लिए सभी कनेक्शन स्ट्रिंग्स को बदलने के लिए संपादित करना है। एक कदम जो मैं बहुत बार भूल जाता हूं ...

हमने आखिरकार परीक्षण के लिए एक नया डेटाबेस सर्वर बनाया है, और मैं डेटाबेस को आगे बढ़ा रहा हूं ... लेकिन अब सर्वर अलग होगा और हम अभी भी कनेक्शन स्ट्रिंग मुद्दों से निपटने की जरूरत है।

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

तो मैं बस सोच रहा हूं कि वहां कोई बेहतर तरीका है या नहीं। कुछ ऐसा जो तैनाती आदर्श होगा के लिए एक "उत्पादन" वेब config के साथ निर्माण होगा ...

Answer 1

प्रत्येक परिवेश

के लिए अलग कॉन्फ़िगरेशन के साथ पर्यावरण फ़ोल्डर पर्यावरण के लिए सही एक

Answer 2

मैं आमतौर पर बाहर तैनात तीन अलग-अलग वेब कॉन्फ़िगरेशन हैं: एक मेरी विकास मशीन के लिए, एक क्यूए के लिए, और एक उत्पादन के लिए। विकास एक मेरे स्थानीय SQL डेटाबेस से कनेक्ट होता है (जो बाहर से फ़ायरवॉल किया गया है) और यह डिफ़ॉल्ट web.config है। दूसरों को वेब-prod.config और वेब-qa.config नाम दिया गया है। प्रकाशन के बाद मैं उन दो को हटा देता हूं जिनकी मुझे आवश्यकता नहीं है और सही एक को web.config पर पुनर्नामित करें। अगर मैं भूल जाता हूं, तो ऐप पहली बार डेटाबेस तक पहुंचने का प्रयास करता है, क्योंकि डिफ़ॉल्ट कॉन्फ़िगरेशन संदर्भ एक ऐसा नहीं कर सकता है।

चूंकि आईआईएस .config नाम की एक फ़ाइल को प्रस्तुत करने से इंकार कर देता है, इसलिए मैं सुनिश्चित करता हूं कि वे सभी web.config-prod या web.config-qa कहने के बजाय .config में समाप्त हो जाएं।

Answer 3

मैंने ऐसा अक्सर किया, मैंने उत्पादन सर्वर पर केवल web.config बनाया।

Answer 4

Web Deployment Project का उपयोग करें और wdproj फ़ाइल (यह सिर्फ एक MSBuild फ़ाइल है) को अद्यतन करें, कुछ पोस्ट बिल्ड कार्यों के साथ सही .config फ़ाइल आउटपुट करने के लिए। मैं एक web.config रखने और फिर wdproj फ़ाइल में इस का उपयोग web.release.config:

<Target Name="AfterBuild"> 
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\web.release.config" DestinationFiles="$(OutputPath)\web.config" /> 
    <Delete Files="$(OutputPath)\web.release.config" /> 
</Target> 

More information

एक अधिक आसान समाधान कुछ चाहते configSource property of appSettings and connectionStrings और उपयोग कर रहा है तो कभी नहीं उत्पादन सर्वर पर उस फ़ाइल को अधिलेखित ।

Answer 5

यहाँ एक और बात यह है कि आप की कोशिश कर सकते हैं:

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

Answer 6

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

Answer 7

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

SQL सर्वर के लिए, SQL सर्वर कॉन्फ़िगरेशन प्रबंधक> SQL मूल क्लाइंट कॉन्फ़िगरेशन> उपनाम> नया उपनाम बनाएं पर जाएं।

आप ओरेकल के साथ tnsnames फ़ाइल के साथ एक ही काम कर सकते हैं।

Answer 8

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

Answer 9

मैं उन कुछ स्थानों पर रहा हूं जो उन्हें रजिस्ट्री में संग्रहीत करते हैं।

अब इसे करने के लिए शायद अधिक विस्तृत तरीके हैं लेकिन 1.0/1.1 विरासत स्टोर के साथ मैंने बहुत सारे कोड रजिस्ट्री में तारों को स्टोर किया है।

रजिस्ट्री में कुछ फायदे हैं

1. यह गलत स्थानों के लिए कोड की तैनाती के बाद से ठीक से विन्यस्त नहीं मशीनों चाबियाँ
2. यह समस्या जिसमें एक डेवलपर गलती से एक पैकेज होगा समाप्त की कमी होगी से लोगों रहता है वेब.कॉन्फिग फ़ाइल में विकास कनेक्शन स्ट्रिंग्स के साथ (रात के मध्य में एक फ्रैंटिक फोन कॉल के बाद, जिसमें यह पता चला है कि देर रात सिसडमिन ने पिछले वेब.कॉन्फिग का बैक अप नहीं लिया और डेवलपर को पता या याद नहीं आया उत्पादन तार)
3. यह संभावना को सीमित करता है मशीन के web.config को लाकर कनेक्शन हैरिंग प्राप्त करने में सक्षम हैकर की एकता। इसके अलावा रजिस्ट्री में फाइल सिस्टम की तुलना में सुरक्षा के अधिक स्तर हैं।

Answer 10

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

Answer 11

मैं हाल ही में निरंतर एकीकरण सर्वर पर कॉन्फ़िगरेशन मैनिपुलेशन की ओर झुका रहा हूं। ऐसा इसलिए है क्योंकि हमें एकाधिक web.config, web.qa.config, web.production.config में समस्या का 95% फ़ाइल रखने में समस्याएं थीं जो सिंक में समान होनी चाहिए।

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

हम नेंट का उपयोग कर रहे हैं, इसलिए यह .build फ़ाइल है जिसमें xmlpoke को डीबग = "झूठा" सेट करने के लिए, कनेक्शन स्ट्रिंग्स को बदलने, और कैनरी प्रति में और जो कुछ भी बदलने की जरूरत है, web.config की पैकेजिंग प्रति ।

बिल्ड मशीन के तैनाती को "कैनरी" कहा जाता है क्योंकि कोई समस्या होने पर मरने वाली पहली चीज़ है।