नेट .config नरक

Question

मैं निम्नलिखित परियोजनाएं हैं:

1. MVC
2. कंसोल आवेदन
3. कक्षा पुस्तकालय
4. विंडोज रूपों आवेदन
5. COM लाइब्रेरी

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

इन सभी परियोजनाओं में एक ही कॉन्फ़िगरेशन को सुलभ करने की आवश्यकता है। मैंने पढ़ा है कि मशीन कॉन्फ़िगरेशन फ़ाइल का उपयोग करने का सुझाव दिया गया है, लेकिन हमारे पास हमेशा उस तक पहुंच नहीं होगी, इसलिए कॉन्फ़िगरेशन फ़ाइलों को हमारे समाधान में अवश्य रहना चाहिए।

मैं पूरी तरह से समझ नहीं पा रहा हूं कि कॉन्फ़िगरेशन फ़ाइलों का निर्माण कैसे होता है। वर्तमान में मैंने एक साधारण प्रोजेक्ट लिखा है जहां मेरे पास निम्न है:

1. क्लास लाइब्रेरी कॉन्फ़िगरेशन फ़ाइलों की सेवा के लिए स्टोर करने के लिए स्टोर करें। ए ने प्रतिबिंब के माध्यम से ऐसा करने का प्रयास किया है।
2. विंडोज एप्लिकेशन जो क्लास लाइब्रेरी से app.config को पढ़ना चाहिए।

जब मैं निम्नलिखित कोड निष्पादित मैं परीक्षण मूल्यों के साथ एक विन्यास फाइल प्राप्त करने की उम्मीद:

_applicationSettings = ConfigurationManager.OpenExeConfiguration(
        System.Reflection.Assembly.GetAssembly(typeof(WCSConfiguration)).Location 
        ).AppSettings;  

क्या मैं बजाय एक खाली आवेदन सेटिंग्स फ़ाइल है।

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <appSettings> 
    <add key="TestTextKey" value="TestTextValue"/> 
    </appSettings> 
</configuration> 

मैं .GetExecutingAssembly() विधि है जो मैं एक कोड है कि वर्तमान में क्रियान्वित किया जा रहा है की एक सभा वापस जाने के लिए उम्मीद का उपयोग कर की कोशिश की है:

कक्षा पुस्तकालय निम्नलिखित App.config है। यह काम नहीं किया, इसके बजाय यह एक विंडोज़ अनुप्रयोग की असेंबली वापस कर दिया है।

GetAssembly(type(WCSConfiguration)) एक सही विधानसभा वापस आ गया है, हालांकि, विन्यास फाइल बिन/डिबग निर्देशिका में याद आ रही थी।

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

मैं भी बोल्ड में COM छोड़ दिया है क्योंकि मुझे यकीन है कि क्या किसी भी config फ़ाइलों बिल्कुल COM पुस्तकालय के लिए उपलब्ध होगा नहीं हूँ। सबसे पहले मैं काम करने के लिए अन्य परियोजनाएं प्राप्त करना चाहता हूं।

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

संपादित करें धन्यवाद है:

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

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

मैं इससे बाहर निकलना चाहता हूं यह एक अच्छा काम करने योग्य समाधान है ताकि इसे ऑनलाइन पोस्ट किया जा सके और अन्य लोगों को जो एक ही समस्या में आते हैं, वे अपने समय के दिन नहीं व्यतीत करेंगे। कहानी IMO की

मनोबल: उपयोग दोनों App.config और Web.config अपने स्वयं के विन्यास फाइल के स्थान स्टोर करने के लिए।

विन्यास की सेवा के लिए कॉन्फ़िगरेशन और डीएलएल पढ़ने/लिखने के लिए सरल एक्सएमएल सीरिएलाइज़र लिखें।

COM ऑब्जेक्ट्स एक लंबी कहानी है और इसे "हैक" के साथ कार्यान्वित किया गया था, क्योंकि COM DLLs में न तो App.config या Web.config उपलब्ध हैं।

Answer 1

नोट ConfigurationManager.OpenExeConfiguration को कॉन्फ़िगरेशन फ़ाइल का फ़ाइल नाम पारित करने की आवश्यकता है, निष्पादन योग्य नहीं।

आपको निष्पादन योग्य के पथ पर .config जोड़ना होगा। Exe असेंबली Assembly.GetEntryAssembly का उपयोग करने के लिए।

आप आपको लगता है कि एक ही नेट प्रक्रिया में बिल्कुल नहीं हैं कोड के कई हिस्सों को भर में साझा करना चाहते हैं विन्यास सेटिंग्स है, तो मेरा सुझाव है:

• उन्हें अपने myStuff.config में रख दें।
• .NET कोड में ConfigurationManager.OpenExeConfiguration का उपयोग myStuff.config खोलने और एक्सेस करने के लिए करें।
• गैर-.NET कोड को लोड करने और सेटिंग्स को पढ़ने के लिए XML पार्सर का उपयोग करने की आवश्यकता होगी। जब तक कि आप कॉन्फ़िगरेशन संरचनाएं बहुत जटिल न हों, तब तक इसे समाहित करना बहुत कठिन नहीं होना चाहिए।
• .NET अनुप्रयोगों के लिए इस कॉन्फ़िगरेशन को साझा करने वाले प्रत्येक एप्लिकेशन के app.config में myStuff.config पर पथ रखें। (गैर- .NET अनुप्रयोग नहीं: उस एप्लिकेशन के लिए क्या काम करता है इस पर निर्भर करता है।)

एक और दृष्टिकोण, जहां कॉन्फ़िगरेशन संरचना समान है लेकिन सेटिंग प्रति-अनुप्रयोग एक कस्टम कॉन्फ़िगरेशन अनुभाग होगा।

Answer 2

कुछ सामान्य बिंदु - उठाए जाने के लिए डीएल की कॉन्फ़िगरेशन फ़ाइल पर भरोसा करने के बजाय dll के कॉन्फ़िगरेशन अनुभाग को app.config फ़ाइल में जोड़ें; और app.config वास्तव में निर्माण पर .exe.config का नाम बदल जाता है, इसलिए आपको यह सुनिश्चित करना होगा कि उस नाम की एक फ़ाइल उपलब्ध है।

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