2009-02-26 10 views
25

जिस तरह से मैं वर्तमान में इसे संभालता हूं, वह कई कॉन्फ़िगरेशन फाइलें हैं:आप एकाधिक वातावरण के लिए एकाधिक web.config फ़ाइलों को कैसे संभालते हैं?

web.config 
web.Prod.config 
web.QA.config 
web.Dev.config 

जब प्रोजेक्ट विभिन्न वातावरण में तैनात हो जाता है तो मैं सही सेटिंग्स के साथ संबंधित फ़ाइल का नाम बदलता हूं।

किसी के पास इस तरीके को बेहतर तरीके से संभालने के सुझाव हैं?

संपादित करें: यहां कुछ चीजें हैं जो प्रत्येक कॉन्फ़िगरेशन में बदलती हैं:

  • डब्ल्यूसीएफ क्लाइंट एंडपॉइंट यूआरएल और सुरक्षा
  • कस्टम डेटाबेस कॉन्फ़िगरेशन
  • सत्र कनेक्शन स्ट्रिंग
  • log4net सेटिंग्स
+0

तरह से मैं यह कर रहा है यही कारण है, कि web.config और वेब dev.config को छोड़कर एक ही बात कर रहे हैं। – tvanfosson

उत्तर

17

स्कॉट गु इस पर एक article एक बार था -

  • 2 और 3 का संयोजन (उदाहरण के आवेदन सर्वर नाम के लिए सेटिंग्स वातावरण के आधार पर का एक हिस्सा ओवरराइड)। उन्होंने जो समाधान प्रस्तुत किया था वह चयनित बिल्ड कॉन्फ़िगरेशन के आधार पर सही कॉन्फ़िगरेशन को कॉपी करने के लिए प्री-बिल्ड इवेंट का उपयोग करना था।

    मैंने यह भी देखा कि एसओ पर यहां पहले से ही question समान है।

  • 0

    यह वास्तव में इस बात पर निर्भर करता है कि पर्यावरण के बीच क्या अंतर है एस जो आपको विभिन्न web.config फ़ाइलों का उपयोग करने के लिए प्रेरित कर रहा है। क्या आप अधिक जानकारी दे सकते हैं कि प्रत्येक पर्यावरण को वर्तमान में एक अलग क्यों चाहिए?

    +0

    मुझे लगता है कि प्रत्येक पर्यावरण को विशेष डेटाबेस कनेक्शन, राज्य सेवा कॉन्फ़िगरेशन और अन्य विभिन्न कॉन्फ़िगर करने योग्य वस्तुओं की आवश्यकता होगी जो आपके पर्यावरण में भारी निर्भर करती हैं। –

    0

    जिस तरह से हम यह कर दिया गया कर दिया है AppSettings अनुभाग ओवरराइड करने के लिए है:

    <appSettings file="../AppSettingsOverride.config"> 
        <add key="key" value="override" />  
        ... 
    </appSettings> 
    

    appSettings अनुभाग के लिए यह केवल काम करता है और इसलिए केवल एक हद तक उपयोगी है। मैं अधिक मजबूत समाधान में बहुत दिलचस्पी लेता हूं।

    संपादित नीचे

    बस इस देखा: http://channel9.msdn.com/shows/10-4/10-4-Episode-10-Making-Web-Deployment-Easier/

    VS2010 config रूपांतरण जो बहुत भयानक लग रही है, कई विन्यास एक पूरा हवा बनाना चाहिए है।

    +0

    यह दिलचस्प है - क्या आप अपनी प्रत्येक AppSettingsOverride.config फ़ाइलों को प्रबंधित करते हैं स्रोत नियंत्रण भी? अपनी विधि का उपयोग करने और अलग web.config फ़ाइलों का उपयोग करने के बीच क्या अंतर है? –

    +0

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

    1

    विजुअल स्टूडियो में, मैं xcopy बिल्ड इवेंट बनाता हूं और मैं सभी कॉन्फ़िगरेशन फ़ाइलों को एक/config फ़ोल्डर में संग्रहीत करता हूं। यदि आप बिल्ड कॉन्फ़िगरेशन के बाद अपनी फ़ाइलों का नाम देते हैं तो आपको केवल सभी कॉन्फ़िगरेशन के लिए एक ईवेंट की आवश्यकता होती है: यानी /config/web.$(Configuration).config

    0

    हमारे पास कुछ कामकाज हैं (उनमें से सभी नहीं हैं web.config के साथ किया गया लेकिन एक ही विचार)

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

    अधिकांश अलग-अलग संस्करण प्रबंधन सॉफ़्टवेयर (उपवर्तन, गिट, आदि) के माध्यम से आप विशिष्ट फ़ाइलों को अनदेखा कर सकते हैं।

    इस प्रकार, तोड़फोड़ में, मैं होगा:

    configure.template.php - इस फ़ाइल संस्करणीकृत और इस तरह खाली DSN के configure.php रूप टेम्प्लेटेड विन्यास डेटा, शामिल है - इस फ़ाइल में नजरअंदाज कर दिया है, ताकि इसमें परिवर्तन ट्रैक नहीं किया जाता है।

    तोड़फोड़ में, जिस तरह से यह करने के लिए है:

    SVN पे SVN: ध्यान न दें। यह आपके संपादक को खोल देगा, फिर आप config.php

    सहेजें, बाहर निकलें, अपने परिवर्तनों की जांच करें, और आप जाने के लिए अच्छे हैं।

    1

    इससे निपटने का मेरा पसंदीदा तरीका configSource विशेषता के साथ है। माना जाता है कि मैं केवल इसे एक तत्व (<connectionStrings>) पर उपयोग करता हूं लेकिन यह web.config के विभिन्न हिस्सों में स्वैप करने और बाहर करने का एक आसान तरीका प्रदान करता है (जो मैं वेबसेट प्रोजेक्ट के माध्यम से इंस्टॉल समय के दौरान करता हूं)।

    1

    मैं भी का उपयोग web.DEV.config, web.TEST.config, web.PROD.config आदि

    मैं अगर अपनी परियोजनाओं नहीं कर रहे हैं इस तरह से सबसे आसान, सरल और सीधी-सपाट रास्ता खोजने जटिल। मुझे चीजों को निष्क्रिय से ज्यादा जटिल बनाना पसंद नहीं है।

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

    http://aspnet.4guysfromrolla.com/articles/120104-1.aspx

    http://nant.sourceforge.net/

    मैं इसे CruiseControl.net और NUnit के साथ इस्तेमाल किया स्वत: दैनिक इकाई परीक्षण सत्यापन के साथ बनाता है प्रदर्शन करने के लिए और सोचा कि वे एक साथ अच्छी तरह से काम किया।

    संबंधित मुद्दे