विजुअल स्टूडियो में डेवलपर विशिष्ट app.config / web.config फाइलें

Question

हमारे पास कई .NET प्रोजेक्ट हैं जहां हम कॉन्फ़िगरेशन फ़ाइलों में कुछ सेटिंग्स संग्रहीत करते हैं।

अब प्रत्येक डेवलपर के पास अपनी स्वयं की कॉन्फ़िगरेशन फाइलें होंगी जो स्थानीय डेटाबेस से जुड़ने के लिए थोड़ा अलग (अलग कनेक्शन स्ट्रिंग्स, अलग WCF एंडोर्समेंट लिस्ट) आदि)

फिलहाल हम एप्लिकेशन / web.config फ़ाइलों की जांच करते हैं और उन्हें हमारी आवश्यकताओं के अनुरूप संशोधित करते हैं।

यह समय-समय पर कई समस्याओं का कारण बनता है जब कोई व्यक्ति TFS से नवीनतम संस्करण प्राप्त करते समय अपनी स्वयं की सेटिंग्स या ढीले कस्टम कॉन्फ़िगरेशन में जाँच करेगा ।

आप इस तरह की स्थितियों से कैसे निपटेंगे? या आपको यह समस्या बिल्कुल नहीं है?

Comments

मैं फिर से खोलने के लिए मतदान कर रहा हूं, क्योंकि यह दृश्य स्टूडियो डेवलपर्स के लिए एक सामान्य समस्या है और इसमें सीधे उपकरण शामिल हैं, डेवलपर्स उपयोग कर रहे हैं। (इसलिए वोट्स)

— क्रिश्चियन गोल्हार्ट

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

— डिस्कजंकी

Answer 1

हम एक प्रणाली का उपयोग करते हैं जो इस पृष्ठ पर मौजूदा उत्तरों में से कई को जोड़ती है, साथ ही स्कॉट हंसेलमैन के इस सुझाव पर आकर्षित करती है ।

संक्षेप में, हमने जो किया वह एक सामान्य ऐप था ।config / web.config, और व्यक्तिगत फ़ाइलों में अधिकांश विशिष्ट सेटिंग्स, जैसा कि यहां अन्य उत्तरों द्वारा सुझाया गया है। हमारे SMTP सेटिंग्स के लिए, app.config शामिल हैं

<system.net>
  <mailSettings>
    <smtp configSource="config\smtp.config" />
  </mailSettings>
</system.net>

इस फ़ाइल में है स्रोत नियंत्रण में। हालाँकि, इस तरह की अलग-अलग फाइलें, नहीं हैं:

<?xml version="1.0" encoding="utf-8" ?>
<smtp deliveryMethod="Network">
  <network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" />
</smtp>

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

इसलिए हम स्रोत नियंत्रण में .config फ़ाइलों का एक संस्करण रखते हैं, जिसका नाम .config.default फ़ाइलें हैं। एक ताजा स्रोत का पेड़ इस तरह दिखता है:

फिर भी, डेवलपर के लिए वास्तव में कोई उपयोग नहीं है, क्योंकि विज़ुअल स्टूडियो के बाद वे सिर्फ अर्थहीन पाठ फ़ाइलें हैं। इसलिए बैच फ़ाइल, copy_default_config.bat.config.default फ़ाइलों से .config फ़ाइलों का एक प्रारंभिक सेट बनाने का ख्याल रखती है:

@echo off
@REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders.
for /r %%f in (*.default) do (
    if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y)
)
echo Done.

स्क्रिप्ट सुरक्षित रूप से फिर से चलने योग्य है, ऐसे डेवलपर्स में जिनके पास पहले से ही उनकी .config फाइलें हैं, उन्हें अधिलेखित नहीं किया जाएगा। इसलिए, कोई भी इस बैच फ़ाइल को पूर्व-बिल्ड इवेंट के रूप में चला सकता है। .Default फ़ाइलों के मान एक नए इंस्टाल के लिए बिल्कुल सही नहीं हो सकते हैं, लेकिन वे एक उचित शुरुआती बिंदु हैं।

अंतत: प्रत्येक डेवलपर जो समाप्त करता है वह कॉन्फिग फाइलों का एक फ़ोल्डर होता है जो कुछ इस तरह दिखता है:

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

Comments

क्यों नहीं सीधे मुख्य .config रिपॉजिटरी में हैं, लेकिन व्यक्तिगत नहीं हैं?

— ग्रेड

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

— जिपरसन

@ गेविन, मुझे एक त्रुटि मिलती है यदि मैं आपके द्वारा बताए गए बैट फ़ाइल को चलाने का प्रयास करता हूं: 'e @ इको' को आंतरिक या बाहरी कमांड, ऑपरेशनल प्रोग्राम या बैच फ़ाइल के रूप में मान्यता नहीं दी जाती है।

— ऑस्टिन

@ ऑस्टिन, आपको '@echo' से पहले कुछ नॉन-प्रिंट करने योग्य कचरा लगता है, जिसका कुछ हिस्सा यूनिकोड बाइट ऑर्डर मार्क से संभव है? हो सकता है कि कॉपी / पेस्ट में कुछ गड़बड़ हो गई हो, या बैच फ़ाइल को एन्कोडिंग में सहेजा गया हो जिसे ठीक से पढ़ा नहीं जा सकता है।

— गैविन

Answer 2

अपने Web.config में अन्य फ़ाइलों से स्रोत का उपयोग करें

<configuration>
    <connectionStrings configSource="ConnectionStrings.config" />
...
</configuration>

संस्करण नियंत्रण में web.config रखें और इसे ConnectionStrings.config के लिए न करें। अब सभी डेवलपर्स के पास कनेक्शन स्ट्रिंग के लिए एक फाइल है।

आप यह उन सभी सेटिंग्स के लिए कर सकते हैं जो स्थानीय निर्भर हैं।

Comments

इसने मेरे लिए अच्छा काम किया। इसे भी देखें: davidgiard.com/2012/05/25/… कनेक्शनस्ट्रीमर्स.कॉन्फिग फ़ाइल को ऐप या वेब कॉन्फिग के समान फ़ोल्डर में होना चाहिए। साथ ही, आपको आउटपुट पर 'यदि नया है' कॉपी करने के लिए इसके गुणों को बदलना होगा। और ConnectionStrings.config फ़ाइल को तत्वों को खोलने और बंद करने के साथ पूर्ण खंड की आवश्यकता है। आपको फ़ाइल को अनदेखा करने के लिए संस्करण नियंत्रण भी सेट करना होगा ताकि प्रत्येक उपयोगकर्ता-विशिष्ट हो।

— जेफरी रफगार्डन

मैंने <appSettings फ़ाइल = ".."> का उपयोग किया क्योंकि मुझे सेटिंग्स को मर्ज करना पड़ा

— Spikolynn

@JeffreyRoughgarden यदि आप समाधान एक्सप्लोरर में ConnectionStrings.config फ़ाइल को शामिल करते हैं, तो क्या फ़ाइल को फाइलस्टर्म पर मौजूद नहीं होना चाहिए? और अगर ऐसा होता है, तो इसका मतलब है कि आपने इसे स्रोत नियंत्रण में जाँच लिया है। यह वह प्रारंभिक समस्या है जिससे हम दूर होने की कोशिश कर रहे थे।

— Jez

Answer 3

यहाँ web.config फ़ाइलों और Visual Studio 2010 के लिए एक समाधान है:

1) AfterBuildइस तरह से एक लक्ष्य जोड़ने के लिए मैन्युअल रूप से अपने वेब अनुप्रयोग .csproj फ़ाइल संपादित करें :

  <Project>
   ...
    <Target Name="AfterBuild">
      <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
      <TransformXml Source="obj\$(Configuration)\tempweb.config"
                  Transform="web.$(USERNAME).config"
                  Destination="obj\$(Configuration)\tempweb2.config" />
      <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile>
      <ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile>
      <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
    </Target>
  </Project>

यह लक्ष्य वर्तमान में लॉग किए गए वर्तमान डेवलपर के अनुरूप Web.config फ़ाइल को बदल देगा - इसलिए $(USERNAME)चर - 1 में बनाई गई संबंधित फ़ाइल के साथ)। यह स्थानीय Web.config को तभी बदलेगा, जब प्रत्येक बिल्ड पर सामग्री बदल गई हो (पुनरारंभ से बचने के लिए), भले ही स्थानीय Web.config स्रोत नियंत्रित हो, इसीलिए यह OverwriteReadOnlyFilesTrue पर सेट होता है। यह बात वास्तव में विचारणीय है।

2) Web.[developer windows login].configप्रोजेक्ट में प्रत्येक डेवलपर के लिए एक फ़ाइल बनाएं । (उदाहरण के लिए निम्नलिखित स्क्रीनशॉट में मेरे पास दो डेवलपर हैं जिनका नाम smo और smo2 है):

ये फाइलें (1 प्रति डेवलपर) स्रोत-नियंत्रित हो सकती हैं। उन्हें मुख्य Web.config पर निर्भर के रूप में चिह्नित नहीं किया जाना चाहिए क्योंकि हम उन्हें व्यक्तिगत रूप से जांचना चाहते हैं।

इस फ़ाइल में से प्रत्येक मुख्य Web.Config फ़ाइल पर लागू करने के लिए एक परिवर्तन का प्रतिनिधित्व करता है। परिवर्तन सिंटैक्स यहाँ वर्णित है: Web.config परिवर्तन सिंटैक्स वेब अनुप्रयोग प्रोजेक्ट परिनियोजन के लिए । हम इस शांत Xml फ़ाइल ट्रांसफ़ॉर्मेशन कार्य का पुनः उपयोग करते हैं जो विज़ुअल स्टूडियो के साथ आउट-ऑफ-द-बॉक्स आता है। इस कार्य का उद्देश्य पूरी फ़ाइल को अधिलेखित करने के बजाय Xml तत्वों और विशेषताओं को मर्ज करना है ।

उदाहरण के लिए, यहाँ एक नमूना है web.[dev login].configजो 'MyDB' नाम के कनेक्शन स्ट्रिंग को बदलता है, बाकी Web.config फ़ाइल की परवाह किए बिना:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
    </connectionStrings>
</configuration>

अब, यह समाधान सही नहीं है क्योंकि:

• निर्माण के बाद, डेवलपर्स के पास स्रोत नियंत्रण प्रणाली की तुलना में स्थानीय रूप से एक अलग Web.Config हो सकता है
• नया नियंत्रण प्राप्त करने के लिए उन्हें स्थानीय लेखन को बाध्य करना पड़ सकता है। स्रोत नियंत्रण प्रणाली से कॉनफिग
• डेवलपर्स को मुख्य web.config में / बाहर की जाँच नहीं करनी चाहिए। यह कुछ लोगों के लिए आरक्षित होना चाहिए।

लेकिन कम से कम, आपको केवल एक अद्वितीय मुख्य web.config प्लस एक परिवर्तन फ़ाइल प्रति डेवलपर को बनाए रखना होगा।

App.config (वेब ​​नहीं) फ़ाइलों के लिए एक समान दृष्टिकोण लिया जा सकता है लेकिन मैंने आगे विस्तार नहीं किया।

Comments

मैंने अपना Web.config का नाम बदलकर Web.base.config कर दिया, एक नई Web.config फ़ाइल बनाई, फिर चरण 1 में <Copy SourceFiles = "web.config"> से <Copy SourceFiles = "web .base.config" में बदल दिया। ऐसा करने से, मेरे पास एक स्थानीय web.config हो सकता है जिसे स्रोत नियंत्रण में अनदेखा किया जा सकता है।

— एस। बग्गी

यह अभी भी आदर्श नहीं है, लेकिन मैं इसे दूसरे समाधान के लिए पसंद करता हूं

— JMK

क्या आपको लगता है कि web.default.configजब web.$(USERNAME).configमौजूद नहीं है तो इसका उपयोग करना संभव है? इस शानदार उत्तर के लिए धन्यवाद।

— क्रिश्चियन गोल्हार्ट

Answer 4

हम वातावरण के बीच web.config में अंतर से बचने के लिए machine.config का उपयोग कर रहे हैं।

Comments

बल्कि मशीन को बदलने से बचना चाहते हैं

— ।config

Answer 5

फ़ाइल को अनदेखा करने के बारे में कैसे, इसलिए यह कभी चेक इन नहीं होता है? मैंने एक समान समस्या में भाग लिया है और Subversion में अनदेखा सूची में web.config जोड़ा है।

TFS में, हालांकि यह थोड़ा कठिन है, इस पोस्ट को देखें कि यह कैसे करना है।

Answer 6

जिस तरह से आप सामना कर सकते हैं वह एक टोकन प्रणाली है और मूल्यों को बदलने के लिए एक रेक स्क्रिप्ट का उपयोग करना है।

एक अधिक अल्पविकसित विधि आपके Web.config (कनेक्शन के साथ समान) में सभी AppSettings के लिए एक AppSettings.config फ़ाइल के लिए एक लिंक हो सकता है।

<appSettings configSource="_configs/AppSettings.config" />

फिर आपके प्रत्येक डेवलपर्स के साथ एक फ़ोल्डर में एक उप फ़ोल्डर में एक संस्करण होता है (यानी / _configs / dave /)। फिर जब कोई डेवलपर अपने कोड पर काम कर रहा होता है तो वे उप फ़ोल्डर से लिंक किए गए फ़ोल्डर की जड़ में कॉपी हो जाते हैं।

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

मैं टोकन पसंद करता हूं, लेकिन उठना और चलना मुश्किल हो सकता है अगर यह केवल एक त्वरित फिक्स होने का मतलब है।

Answer 7

फ़ाइलों को अनदेखा करें और एक Commom_Web.Config और Common_App.Config रखें। बिल्ड एकीकरण के साथ निरंतर एकीकरण बिल्ड सर्वर का उपयोग करना जो इन दोनों को सामान्य नामों में बदल देता है ताकि बिल्ड सर्वर अपना काम कर सके।

Comments

देव मशीनों पर यह करने की आवश्यकता है, इससे पहले कि यह सर्वर बनाने के लिए चला जाता है

— twarz01

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

— आर्थिस

यह जिस चीज का समर्थन नहीं करता है वह है डेवलपर्स एप्लिकेशन को डीबग करना। web.configस्रोत फ़ोल्डर में रूट डीबगिंग के दौरान उपयोग किया जाता है। आप हैं, जैसे, जोड़ा web.configकरने के लिए .gitignoreऔर या तो उन की नकल करने के लिए आवश्यक Commom_Web.Configकरने के लिए web.configवहाँ रास्ते से कर रहे हैं हिस्सा यह उनकी कल्पना करने के लिए और संपादित करें, तो आप। लेकिन तब जब आपको किसी ऐसी चीज को संपादित करने की आवश्यकता होती है जो सभी डेवलपर की मशीनों पर समान होती है, जैसे कि system.web/compilationअनुभाग या विशेष appSettingsजो हर जगह एक जैसी होनी चाहिए, तो यह योजना अलग हो जाती है।

— binki

Answer 8

हमारे पास एक ही समस्या है और हम जो कर रहे हैं वह है

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

Comments

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

— जिपरसन

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

— binki

Answer 9

मान लें कि आप Visual Studio का उपयोग कर रहे हैं, तो आप विभिन्न समाधान कॉन्फ़िगरेशन का उपयोग क्यों नहीं करते हैं? उदाहरण के लिए: आपके पास एक डीबग कॉन्फ़िगरेशन हो सकता है जो Web.config.debug और एक रिलीज़ कॉन्फ़िगरेशन का उपयोग करता है जो Web.config.release का उपयोग करता है। Web.config.debug में कुछ ऐसा होना चाहिए

<appSettings file="C:/Standard_Path_To_Configs/Standard_Name_For_Config.config"> 

फ़ाइल के साथ Standard_Name_For_Config.config, जो कि सभी व्यक्तिगत डेवलपर सेटिंग्स को प्राप्त करता है, जबकि Web.config.release में हमेशा उत्पादन सेटिंग्स होती हैं। आप कुछ स्रोत नियंत्रित फ़ोल्डर में डिफ़ॉल्ट कॉन्फ़िगरेशन संग्रहीत कर सकते हैं और एक नया उपयोगकर्ता उन्हें वहां से ले जा सकते हैं।

Comments

फिर प्रत्येक व्यक्तिगत उपयोगकर्ता जो कभी भी परियोजना में योगदान देगा, उन्हें अपना स्वयं का बिल्ड कॉन्फ़िगरेशन करने की आवश्यकता होगी। यह पैमाने पर नहीं लगता है और योगदान स्वीकार करने वाली परियोजनाओं का समर्थन नहीं करता है।

— binki