Проблема с config файлами в .NET 2.0

[el_Wild]

Необходима помощь в решении одной проблемы:

Есть приложение, к примеру, MyApplication. Естественно, у него есть свой файл app.config (после компиляции MyApplication.exe.config), который содержит различные настройки этого приложения.

Это приложение использует библиотеку классов (dll) MyLibrary. Библиотека в свою очередь содержит свой app.config (после компиляции MyLibrary.dll.config).

Во время отладки (при запуске из VS) все отлично, приложение работает со своим конфигом, библиотека со своим. Но при запуске вне студии библиотека работает только с MyApplication.exe.config, а свой даже не видит. Естественно, не находя там "своих" свойств она грузит их default значения.

Суть вопроса как заставить библиотеку грузить свой файл?

К сожалению, решение: продублировать свойства из MyLibrary.dll.config в MyApplication.exe.config, не подходит.

Заранее спасибо!

[Tigra]

Есть такая партия))
Конфиги привязаны к домену приложения. Либу - в отдельный AppDomain.
Или можно в либе конфиг просто парсить, как xml

[el_Wild]

Конфиг парсить как xml пробовал, но там есть другая проблема, т.е. совйства уровня Application (к ним же относятся и ConnectionStrings) только для чтения. Приходилось руками добавлять им метод set, в этом случае при каждом изменении свойств через дизайнер все затиралось и приходилось все делать по новой.

А вот на счет либу в отдельный AppDomain -- спасибо. Попробую.
А другие способы существуют?

[Guffy]

надо рыть в сторону написания наследника LocalFileSettingsProvider
там есть метод

public override SettingsPropertyValueCollection GetPropertyValues(SettingsContext context, SettingsPropertyCollection properties)

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

private SettingsPropertyValueCollection GetSettingValuesFromFile(string configFileName, string sectionName, bool userScoped, SettingsPropertyCollection properties)

но он приватный...

можно вообще написать ему аналог public class MyLocalFileSettingsProvider : SettingsProvider, IApplicationSettingsProvider


либо плюнуть на всю богодельню с дизайнером и ApplicationSettingsBase - и писать в рукопашную своих наследников от ConfigurationSection (это не сложно), и потом самому разбираться с ConfigurationManager

ИМХО: на AppDomain Вы получите кучу геммороя на кроссдоменных вызовах (междоменный ремотинг), естественно, с потерей производительности. если это не критично - вперед.

[el_Wild]

Спасибо за помощь! Проблему решил.
Написал свой SettingsProvider.

[the_crabolocker]

Есть другой способ: объявить и создать соответствующую секцию в основном файле конфигурации приложения, т.е. в файле MyApplication.exe.config.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGrou p, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="SettingsDemo.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
<section name="CustomLibrary.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
</configSections>
<applicationSettings>
<SettingsDemo.Properties.Settings>
<setting name="LocalString" serializeAs="String">
<value>This is local string</value>
</setting>
</SettingsDemo.Properties.Settings>
<CustomLibrary.Properties.Settings>
<setting name="String1" serializeAs="String">
<value>This is string1</value>
</setting>
<setting name="String2" serializeAs="String">
<value>This is string2</value>
</setting>
</CustomLibrary.Properties.Settings>
</applicationSettings>
</configuration>

А за подробностями сюда: http://infosysblogs.com/microsoft/2006/10/settings_in_net_fwk_20.html

Удачи!