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

Question

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

Answer 1

. Конфигурация .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.

• Раскрытие тайны конфигурации .NET 2.0
• Расшифровка загадок конфигурации .NET 2.0
• Раскрытие тайны конфигурации .NET 2.0

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

Марк

Answer 2

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

• Просто сделать настройки доступными для всех приложений, которые используют он dll может быть достигнуто путем помещения их в файле Machine.config (в C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG для .Net2.0

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

Answer 3

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

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

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

Answer 4

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

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

В случае сервера Quartz, если у вас есть какая-либо конкретная информация о конфигурации, которая должна храниться в файле конфигурации, вы должны поместить ее в файл конфигурации Quartz.NET. Мы создали несколько «рабочих» приложений, каждое из которых имеет свои биты информации о конфигурации, поэтому теперь наш конфигурационный файл Quartz.NET изобилует всеми этими несвязанными настройками. Наличие специфичного для DLL файла конфигурации значительно уменьшит беспорядок на сервере Quartz.NET. Единственный другой вариант, который я вижу, - это добавить все эти индивидуальные настройки в таблицу БД настроек, но для консолидации и обслуживания кода для наших целей предпочтительны отдельные файлы конфигурации.

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

Answer 5

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