.Net 3.5 с в DLL, используя свой собственный файл конфигурации

Мне нужно, чтобы DLL .NET 3.5 имела свой собственный файл конфигурации. Эта DLL может быть вызвана из разных приложений, поэтому информация (например, строки подключения), хранящаяся в файле конфигурации, должна храниться в файле конфигурации, на который может ссылаться DLL. Что я хочу, когда используется DLL, мне нужно "переключить" файл конфигурации, который используется для ссылки на информацию, чтобы быть файлом конфигурации DLL. Затем, когда DLL завершается с использованием информации о конфигурации, переключатель возвращается к по умолчанию один. DLL написана с помощью .NET 3.5. Я искал, как это сделать, и что я продолжаю находить, это как объединить информацию с приложением exe.конфигурационный файл. В моем случае я не знаю, как эта DLL будет использоваться для изменения любого приложения exe.конфигурационные файлы там. Это решение должно быть самостоятельным. Однако мои базовые классы, используемые для создания DLL (которые содержат бизнес-объекты), ожидают поиска строки подключения и другой информации в файле конфигурации, так что почему мне нужно "переключиться" на мой файл конфигурации DLL в то время, когда он доступен, а затем переключить его обратно, чтобы я не испортил exe-приложение, которое называется DLL.

5 ответов


система конфигурации .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 строится и копируется в место, где вы можете ее получить. В худшем случае вам нужно указать конкретный файл конфигурации и убедиться, что он будет скопирован в выходной каталог, установив его свойство" копировать в выходной каталог " в окне свойств Visual Studio.

вы также должны проверить трехкомпонентную серию Джона Риста в конфигурации .NET 2.0 на CodeProject.

высоко рекомендуется, хорошо написано и очень полезно!

Марк


обычно, когда у вас есть настройки на уровне приложения, вам нужно создать эти настройки на уровне приложения, а затем просочиться через ваши библиотеки. Он добавляет еще несколько строк кода к вашей инициализации для введения зависимостей, но вы все равно пытаетесь это сделать.

вы столкнетесь с большим количеством проблем, чем стоит, если вы попытаетесь включить файл конфигурации только для dll бок о бок с каждым развертыванием вашей библиотеки, и это семантически это не имеет смысла.

Принять Систему.Например, данные...при создании соединения необходимо указать строку подключения, а не создавать отдельный файл конфигурации только для строки подключения, развертываемой бок о бок с системой.Библиотека данных. [и это вызовет массу проблем, так как он, вероятно, находится в GAC в вашей системе в любом случае]


для этого нельзя использовать встроенную систему конфигурации .Net. Он предназначен (как и должно быть ) для настройки процессов приложений, а не отдельных библиотек DLL. Правильный способ сделать это-добавить параметры конфигурации для dll в приложение.система конфигурации для каждого исполняемого приложения, которое" использует " (имеет ссылку на) эту dll. (или в машине.config)

  • просто настройки работает все приложения для спорта, что УСЭТ он в DLL может осуществлять поместив их в машине.config (in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG для .Net2.0

Если вы не хотите делать это таким образом, то вам придется написать свой собственный код, чтобы открыть, прочитать и написать FRM пользовательский Xml-файл (или любой формат, который вы решите использовать), чтобы расширить эти настройки.


самым простым ответом на это было бы поместить значения в машину.конфиг. Таким образом, все приложения, использующие dll, смогут получить доступ к информации через классы конфигурации .net app. Таким образом, если вам абсолютно необходимо переопределить значение для определенного applicatin, вы можете переопределить его в приложении основного приложения.конфигурационный файл.


Я знаю, что этот пост немного старый, но я хотел бросить мой 2 центов. Хотя в майских случаях я бы согласился, что приложение должно предоставлять настройки, а не dll. Я нашел одну ситуацию в то время как dll конкретные конфигурации, кажется, более желательны.

мы используем приложение планирования / задачи Quartz.NET - ... Мы разработали интерфейс для создания и мониторинга заданий на сервере Quartz. Одна из замечательных вещей о Quartz.NET это то, что вы создаете свои" рабочие " программы и скомпилируйте их в DLL, а затем просто поместите их в Quartz.NET папка сервера и через отражение и такие, кварц может начать использовать новую DLL без каких-либо дополнительных настроек для Quartz server...если нет информации, которая должна храниться в файлах конфигурации.

с Quartz server если у вас есть какая-либо конкретная информация о конфигурации, которая должна храниться в файле конфигурации, вы должны поместить ее в Quartz.NET конфигурационный файл. Мы создали несколько приложений "работа", каждый со своим собственные биты информации о конфигурации, поэтому теперь наш Quartz.NET файл конфигурации завален всеми этими несвязанными настройками. Наличие конкретного конфигурационного файла dll значительно уменьшит беспорядок Quartz.NET сервер. Единственный другой вариант, который я вижу, - добавить все эти индивидуальные настройки в таблицу настроек DB, но для консолидации и обслуживания кода для наших целей предпочтительнее отдельные файлы конфигурации.

просто выбрасываю это, чтобы подумать.