का उपयोग कर मुझे .NET 3.5 DLL की अपनी कॉन्फ़िगरेशन फ़ाइल की आवश्यकता है। इस डीएलएल को कई अलग-अलग ऐप्स से बुलाया जा सकता है, इसलिए कॉन्फ़िगरेशन फ़ाइल में संग्रहीत जानकारी (जैसे कनेक्शन स्ट्रिंग्स) को कॉन्फ़िगरेशन फ़ाइल में रखा जाना चाहिए जिसे डीएलएल संदर्भित कर सकता है। मैं क्या चाहता हूं जब डीएलएल का उपयोग किया जाता है, मुझे कॉन्फ़िगरेशन फ़ाइल को "स्विच" करने की आवश्यकता होती है जिसका उपयोग डीएलएल कॉन्फ़िगरेशन फ़ाइल होने के लिए सूचना का संदर्भ देने के लिए किया जाता है। फिर जब डीएलएल कॉन्फ़िगरेशन जानकारी का उपयोग करने के साथ किया जाता है, तो स्विच को डिफ़ॉल्ट पर वापस कर दिया जाता है। डीएलएल .NET 3.5 का उपयोग कर लिखा गया है। मैं यह खोज रहा हूं कि यह कैसे करें और मैं जो खोज रहा हूं वह यह है कि exe की app.config फ़ाइल के साथ जानकारी कैसे विलय करें। मेरे मामले में, मुझे नहीं पता कि इस डीएलएल का उपयोग किसी भी exe की app.config फ़ाइलों को संशोधित करने के लिए किया जाएगा। इस समाधान को अकेले खड़े होने की जरूरत है। हालांकि, मेरी बेस क्लास डीएलएल (जिसमें व्यावसायिक ऑब्जेक्ट्स शामिल हैं) बनाने के लिए उपयोग की जाती हैं, कॉन्फ़िगरेशन फ़ाइल में कनेक्शन स्ट्रिंग और अन्य जानकारी को देखने की उम्मीद कर रहे हैं, इसलिए मुझे उस समय मेरी डीएलएल कॉन्फ़िगरेशन फ़ाइल में "स्विच" करने की आवश्यकता है एक्सेस किया गया है और फिर इसे वापस स्विच करें ताकि मैं exe ऐप को गड़बड़ न करूं जिसे डीएलएल कहा जाता है।.NET 3.5 DLL अपनी स्वयं की कॉन्फ़िगरेशन फ़ाइल
उत्तर
.NET 2.0 और ऊपर कॉन्फ़िगरेशन सिस्टम आपको क्षमताओं देता है - आप उदा। मांग पर एक विशिष्ट विन्यास फाइल लोड करें। यह थोड़ा और काम है - लेकिन यह काम करता है।
आप कुछ इस तरह कर दिया था:
// set up a exe configuration map - specify the file name of the DLL's config file
ExeConfigurationFileMap map = new ExeConfigurationFileMap();
map.ExeConfigFilename = "ConfigLibrary.config";
// now grab the configuration from the ConfigManager
Configuration cfg = ConfigurationManager
.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
// now grab the section you're interested in from the opened config -
// as a sample, I'm grabbing the <appSettings> section
AppSettingsSection section = (cfg.GetSection("appSettings") as AppSettingsSection);
// check for null to be safe, and then get settings from the section
if(section != null)
{
string value = section.Settings["Test"].Value;
}
आप यह भी सुनिश्चित है कि वर्ग पुस्तकालय DLL के लिए config बनाया जा रहा है और एक स्थान है जहां आप इसे प्राप्त कर सकते हैं पर कॉपी किया बनाने की जरूरत है। सबसे खराब स्थिति आपको एक विशिष्ट कॉन्फ़िगरेशन फ़ाइल निर्दिष्ट करने की आवश्यकता है और यह सुनिश्चित करें कि इसे विजुअल स्टूडियो प्रॉपर्टी विंडो में "आउटपुट निर्देशिका में कॉपी करें" संपत्ति सेट करके आउटपुट निर्देशिका में कॉपी किया गया हो।
आपको कोडप्रोजेक्ट पर .NET 2.0 कॉन्फ़िगरेशन पर जॉन रिस्टा की तीन-भाग श्रृंखला भी देखना चाहिए।
- Unraveling the mysteries of .NET 2.0 configuration
- Decoding the mysteries of .NET 2.0 configuration
- Cracking the mysteries of .NET 2.0 configuration
अत्यधिक की सिफारिश की है, अच्छी तरह से लिखा और अत्यंत उपयोगी!
मार्क
इसका सबसे आसान जवाब मशीन.config में मानों को रखना होगा। इस तरह डीएल का उपयोग करने वाले सभी ऐप्स .net ऐप कॉन्फ़िगरेशन कक्षाओं के माध्यम से जानकारी तक पहुंच पाएंगे। इस तरह से, अगर आपको किसी निश्चित आवेदक के लिए मूल्य को ओवरराइड करने की ज़रूरत है, तो आप इसे मुख्य एप्लिकेशन की app.config फ़ाइल में ओवरराइड कर सकते हैं।
आप इसे करने के लिए अंतर्निहित .NET कॉन्फ़िगरेशन सिस्टम का उपयोग नहीं कर सकते हैं। यह अनुप्रयोग प्रक्रियाओं को कॉन्फ़िगर करने के लिए डिज़ाइन किया गया है (जैसा होना चाहिए), अनिवार्य डीएलएस नहीं। इसके बारे में जाने का सही तरीका है कि डीएल के लिए कॉन्फ़िगरेशन सेटिंग्स को प्रत्येक निष्पादन योग्य एप्लिकेशन के लिए app.config सिस्टम में जोड़ना है जो "उपयोग करता है" (उसमें संदर्भ है)। (या machine.config में)
- , बस सेटिंग्स सुलभ सभी applictions कि uset वह dll उन्हें (Machine.config में डाल सी में से पूरा किया जा सकता करने के लिए कर रही है: \ WINDOWS \ Microsoft। नेट \ Framework \ v2.0.50727 \ लिए .Net2.0
कॉन्फ़िग आप इसे उस तरह से नहीं करना चाहते हैं, तो आप, खोलने पढ़ा है, और frm लिखने के लिए अपने स्वयं के कोड लिखने के लिए होगा एक कस्टम एक्सएमएल फ़ाइल, (या जो भी प्रारूप आप उपयोग करना चुनते हैं) उन सेटिंग्स को निकालने के लिए।
आह, आप कर सकते हैं - यह कुछ काम है, और ऐप.कॉन्फिग कहानी के रूप में काफी महान और निर्बाध नहीं है - लेकिन यह काम करता है। और अधिकांश समय, मैं सहमत हूं - मेजबान ऐप को कॉन्फ़िगर प्रदान करना चाहिए। मैं मामलों को देखता हूं, हालांकि एक अलग लाइब्रेरी-विशिष्ट कॉन्फ़िगरेशन भी बहुत समझ में आ सकता है। –
आम तौर पर जब आपके पास एप्लिकेशन स्तर पर सेटिंग्स होती हैं, तो आपको एप्लिकेशन स्तर पर उन सेटिंग्स को उत्पन्न करने की आवश्यकता होती है, और फिर उन्हें अपने पुस्तकालयों के माध्यम से विभाजित करने की आवश्यकता होती है। यह निर्भरताओं को इंजेक्ट करने के लिए आपके प्रारंभिकरण में कोड की कुछ और पंक्तियों को जोड़ता है, लेकिन आप अनिवार्य रूप से ऐसा करने की कोशिश कर रहे हैं।
यदि आप अपनी लाइब्रेरी की हर तैनाती के साथ केवल डीएलएल पक्ष के लिए कॉन्फ़िगरेशन फ़ाइल शामिल करने का प्रयास करते हैं, तो आप इसके लायक से अधिक समस्याएं चलाने जा रहे हैं, और यह केवल अर्थपूर्ण रूप से बहुत अधिक समझ में नहीं आता है ।
सिस्टम ले लो। उदाहरण के लिए डेटा ... जब आप कनेक्शन बनाते हैं, तो आप कनेक्शन स्ट्रिंग निर्दिष्ट करते हैं, सिस्टम कनेक्शन के साथ साइड को तैनात करने के लिए कनेक्शन स्ट्रिंग के लिए एक अलग कॉन्फ़िगरेशन फ़ाइल नहीं बनाते हैं। डेटा लाइब्रेरी। [और इससे कई समस्याएं पैदा हो सकती हैं क्योंकि यह संभवतः आपके सिस्टम पर जीएसी में रहती है]
मैं जानता हूँ कि इस पोस्ट के लिए थोड़ा पुराना है, लेकिन मैं में मेरी 2 सेंट फेंक करना चाहता था। जबकि मई मामलों में, मैं सहमत होगा कि आवेदन सेटिंग्स, नहीं dll आपूर्ति करनी चाहिए। मुझे एक स्थिति मिली है जबकि डीएलएल विशिष्ट विन्यास अधिक इच्छुक हैं।
हम शेड्यूलिंग/कार्य आवेदक क्वार्ट्ज.NET का उपयोग करते हैं। हमने क्वार्ट्ज सर्वर के खिलाफ नौकरियां बनाने और निगरानी करने के लिए एक इंटरफ़ेस विकसित किया है। Quartz.NET के बारे में महान चीज़ों में से एक यह है कि आप अपना "नौकरी" प्रोग्राम बनाते हैं और उन्हें डीएलएल में संकलित करते हैं और फिर उन्हें क्वार्ट्ज.NET सर्वर फ़ोल्डर में छोड़ दें और प्रतिबिंब के माध्यम से और क्वार्ट्ज नए DLL का उपयोग शुरू करने में सक्षम है क्वार्ट्ज सर्वर के लिए कोई अतिरिक्त बदलाव किए बिना ... यदि कोई जानकारी नहीं है जिसे कॉन्फ़िगरेशन फ़ाइलों में होने की आवश्यकता है।
क्वार्ट्ज सर्वर के साथ यदि आपके पास कोई विशिष्ट कॉन्फ़िगरेशन जानकारी है जो कॉन्फ़िगरेशन फ़ाइल में रखी जानी चाहिए, तो आपको इसे Quartz.NET कॉन्फ़िगरेशन फ़ाइल में रखना होगा। हमने कई "नौकरी" एप्लिकेशन बनाए हैं, प्रत्येक को कॉन्फ़िगरेशन जानकारी के अपने बिट्स के साथ, इसलिए अब हमारी क्वार्ट्ज.NET कॉन्फ़िगरेशन फ़ाइल इन सभी असंबंधित सेटिंग्स से भरी हुई है। एक डीएलएल विशिष्ट विन्यास फाइल होने से Quartz.NET सर्वर के अव्यवस्था को बहुत कम कर दिया जाएगा। एकमात्र अन्य विकल्प जो मैं देखता हूं वह इन सभी व्यक्तिगत सेटिंग्स को डीबी टेबल में जोड़ना है, लेकिन कोड के समेकन और रख-रखाव के लिए, हमारे उद्देश्यों के लिए, व्यक्तिगत कॉन्फ़िगरेशन फ़ाइलें बेहतर हैं।
बस इसके बारे में सोचने के लिए इसे बाहर फेंकना।
हम्म .... यह वास्तव में एक जवाब नहीं है, लेकिन मुझे यह एक अंतर्दृष्टिपूर्ण टिप्पणी मिलती है ... – nalply
- 1. जो की अपनी संपादक कॉन्फ़िगरेशन फ़ाइल
- 2. टीएफएस 2010 .Net 4.0 XmlSerializers DLL .NET 3.5 अनुप्रयोग
- 3. .NET 3.5
- 4. .NET कॉन्फ़िगरेशन फ़ाइल
- 5. क्या मॉड्यूल की अपनी कॉन्फ़िगरेशन फ़ाइल हो सकती है?
- 6. .NET 3.5
- 7. .NET 3.5
- 8. .NET 3.5
- 9. .net 3.5
- 10. .net 3.5
- 11. .NET DLL फ़ाइल से पीडीबी उत्पन्न करें?
- 12. XmlSerializer .NET 3.5 और CF.NET 3.5
- 13. क्या आप .NET 2.0 वेबसाइट के साथ .NET 3.5 DLL का उपयोग कर सकते हैं?
- 14. सी # और .NET 3.5
- 15. .NET 2.0 या 3.5?
- 16. सी # .net सीएफ 3.5
- 17. .NET 3.5 (या 4.0)
- 18. .NET 2.0/3.5
- 19. दृश्य कर्सर (.NET 3.5)
- 20. .NET Framework 3.5
- 21. एक्सएमएलएसरियललाइज़र .NET 3.5 SP1
- 22. .NET: उसी DLL
- 23. .net 1.0 DLL के
- 24. .net 4.0 dll
- 25. एक .NET DLL
- 26. .NET 3.5 SP1
- 27. .NET 3.5/VS 2008
- 28. .Net स्क्रीनसेवर को कॉन्फ़िगरेशन फ़ाइल नहीं मिली
- 29. .NET DLL के
- 30. हाइबरनेट की एक्सएमएल कॉन्फ़िगरेशन फ़ाइल
यह इस दृष्टिकोण का उपयोग करने के लिए वादा करता है। मेरे पास एक सवाल है, क्या मुझे इसे "पूर्ववत" नहीं करना है? क्या मेरी डीएलएल कॉन्फ़िगरेशन लुकअप के लिए "डिफ़ॉल्ट" कॉन्फ़िगरेशन होगी? – user31673
नहीं - आपको कॉन्फ़िगरेशन प्रबंधक से स्पष्ट रूप से "कॉन्फ़िगरेशन" ऑब्जेक्ट का अनुरोध करना होगा, और केवल तभी जब आप इस अलग ऑब्जेक्ट पर काम करेंगे तो आपको उन अलग-अलग सेटिंग्स मिलेंगी। –