Всем привет!
В свой WinForms проект добавляю Settings-файл. В этом файле создаю строковый параметр со Scope="Application" (например "MyString"). В проект автоматически добавился файл app.config.
При компиляции рядом с EXE-ником создается файл <имя_exe-шника>.config, где содержится инициализация этого параметра "MyString".
Теперь, если в *.config файле изменить значение параметра "MyString" (например, через Блокнот), то при обращении к этом параметру получаем новое значение.
Вроде все как надо!

Проблема возникает, когда я вместо те же манипуляции выполняю с проектом, который компилируется в DLL-ку (Class Library), подключаю эту DLL-сборку статически к другому EXE-шнику.
При таком сценарии значение параметра "MyString" берется не из файла <имя_dll-ки>.config, а из settings-файла, входящего в состав исходников. Т.е. после редактирования config-файла изменения не игнорируются.

Подскажите плиз: что я не так делаю? Почему обращение к параметрам config-файла, описанным в settings EXE-шного файла отрабатывают корректно, а те же обращения к так же описанным параметрам, но DLL-ки НЕ отрабатывают?

А>Подскажите плиз: что я не так делаю? Почему обращение к параметрам config-файла, описанным в settings EXE-шного файла отрабатывают корректно, а те же обращения к так же описанным параметрам, но DLL-ки НЕ отрабатывают?

вроде потому, что config-файл управляется приложением, т.е. Application, ты же сам выбрал — Scope="Application"
разве твоя dll является application? она у тебя библиотека...
чтобы работать с отделным конифгом в методах классов твоей библиотеки надо самому в какой-то момент создать объект соответствующий класс настроек, и в какой-то момент освободить его, нутипа singlton
ведь приложение так и делает за тебя, именно приложение...

Здравствуйте, Аноним, Вы писали:

skip

потому что не рассчитаны config-файлы на работу с DLL-ками

сам в свое время с этим столкнулся
способов решения проблемы в инете множество, но у всех есть свои недостатки, порой весьма существенные

Здравствуйте, shakm, Вы писали:
S>чтобы работать с отделным конифгом в методах классов твоей библиотеки надо самому в какой-то момент создать объект соответствующий класс настроек, и в какой-то момент освободить его, нутипа singlton

Ну-у-у, блин! Я совсем недавно открыл для себя config-файлы, осознал все их удобство, а теперь будьте добры назад к:

class Options
{
  public string FilePath {get; set;}
  public int Timeout {get; set;}
....
}

... вернуться????
Ну почему у них ВСЕ через "это" самое место???????

Здравствуйте, <Аноним>, Вы писали:
А>Ну-у-у, блин! Я совсем недавно открыл для себя config-файлы, осознал все их удобство

Поделись в чем их удобство?

Проблема собственно в том, что .NET реализация провайдера настроек читает последние из файла приложения (app.config).
Можно сделать так (в app.config приложения):

<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <!- Подключили секцию для библиотеки -->
      <section name="MyLib.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
    </sectionGroup>
  </configSections>

  <applicationSettings>
    <MyLib.Properties.Settings>
      <setting name="MySeting" serializeAs="String">
        <value>Test</value>
      </setting>
    </MyLib.Properties.Settings>
  </applicationSettings>
<configuration>

Из отрицательных моментов:
При добавлении настройки в Settings.cs библиотеки через дизайнер, в app.config оно разумеется не попадет — надо копировать руками.

Здравствуйте, Аноним, Вы писали:
А>Ну почему у них ВСЕ через "это" самое место???????
А по-моему — логично, что библиотека конфигурится приложением, которое ее использует. Не? Для глобальных настроек, действующих на все приложения, есть всякие там machine.config.

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Аноним, Вы писали:
А>>Ну почему у них ВСЕ через "это" самое место???????
MC>А по-моему — логично, что библиотека конфигурится приложением, которое ее использует. Не? Для глобальных настроек, действующих на все приложения, есть всякие там machine.config.

с одной стороны — логично
а с другой — не очень

например, я пишу расширение для некой системы, главное приложение знать не знает о существовании моей dll — и как в этом случае быть?
лезть в application-config?
так это может быть не позволено политиками, да и много других ограничений и проблем вылазит

вот и приходится извращаться — писать свои обертки для config-файлов (или вообще плевать на файлы и пользоваться старым добрым реестром Windows)

Здравствуйте, Андрей, Вы писали:
А>например, я пишу расширение для некой системы, главное приложение знать не знает о существовании моей dll — и как в этом случае быть?
А machine.config не подходит?

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Андрей, Вы писали:
А>>например, я пишу расширение для некой системы, главное приложение знать не знает о существовании моей dll — и как в этом случае быть?
MC>А machine.config не подходит?

хм, надо будет посмотреть как вариант
может и подойдет

но опять же, непонятно как быть с записью изменений — или в этом случае будет также как с app.config?
то есть изменения будут писаться в пользовательскую копию файла?

покурю на досуге в эту сторону, спасибо за наводку

Здравствуйте, Андрей, Вы писали:
А>но опять же, непонятно как быть с записью изменений
Вот тут я еще не копался. По идее, он как минимум свой для каждой установленной версии рантайма.

Здравствуйте, Андрей, Вы писали:

А>>>Ну почему у них ВСЕ через "это" самое место???????
MC>>А по-моему — логично, что библиотека конфигурится приложением, которое ее использует. Не? Для глобальных настроек, действующих на все приложения, есть всякие там machine.config.

А>с одной стороны — логично
А>а с другой — не очень

А>например, я пишу расширение для некой системы, главное приложение знать не знает о существовании моей dll — и как в этом случае быть?

А расширение запускается часом не в отдельном домене?

А>лезть в application-config?
А>так это может быть не позволено политиками, да и много других ограничений и проблем вылазит

Во-вторых, именно "расширению" было бы логично завязываться вообще не на конфиг-файл, а на некий сервис настроек, который для расширения предоставляет хост. А уж хост может уже сохранять где сочтёт нужныт (в том же user.config).
В-третьих, при некоторой ловкости рук можно добиться того, что бы [по предыдущему сценарию] генерируемый студией Settings-класс для расширения менеджерился бы тем самым хостом.

А>вот и приходится извращаться — писать свои обертки для config-файлов (или вообще плевать на файлы и пользоваться старым добрым реестром Windows)

Так что, ИМХО, при написании расширения проблемой является не фреймворк или средство разработки, а система, к которой расширения пишется — зачастую именно её особенности приводят к трудностям.

Портить же machine.config категорически не советую. Если каждое расширение для каждого продукта, что стоит у меня на компе, пользовалось бы machine.config, то тот давно превратился бы в помойку.

Здравствуйте, _FRED_, Вы писали:

_FR>Во-вторых, именно "расширению" было бы логично завязываться вообще не на конфиг-файл, а на некий сервис настроек, который для расширения предоставляет хост. А уж хост может уже сохранять где сочтёт нужныт (в том же user.config).
_FR>В-третьих, при некоторой ловкости рук можно добиться того, что бы [по предыдущему сценарию] генерируемый студией Settings-класс для расширения менеджерился бы тем самым хостом.

Ой, а можно поконкретнее как это применить в моему случае. Есть DLL-ка, которая выполняет полезные действия. Для выполнения этих действий нужно хранить например пути к нескольким каталогам, количество секунд, через которые должен происходить опрос этих каталогов, строка соединения с SQL-сервером и т.п.
В "боевом" режиме эта DLL-ка будет работать в виде службы. Отлаживать DLL-ку лучше обычным EXE-шником.

Итого имеем:
1. Создаю для DLL-ки свой setting-файл со всеми путями, интервалами времени, строками соединения и пр.
2. Подключаю DLL-ку (в том же домене) к WinForm'овскому EXE-шнику и отлаживаю.
3. После отладки, подключаю DLL-ку к EXE-шнику службы и ставлю на "боевое дежурство".

Мне для такого примитивного случая придется заморачиваться с неким дополнительным сервисом настроек???? Или я чего-то не понял?

Здравствуйте, Аноним, Вы писали:

_FR>>Во-вторых, именно "расширению" было бы логично завязываться вообще не на конфиг-файл, а на некий сервис настроек, который для расширения предоставляет хост. А уж хост может уже сохранять где сочтёт нужныт (в том же user.config).
_FR>>В-третьих, при некоторой ловкости рук можно добиться того, что бы [по предыдущему сценарию] генерируемый студией Settings-класс для расширения менеджерился бы тем самым хостом.

А>Ой, а можно поконкретнее как это применить в моему случае. Есть DLL-ка, которая выполняет полезные действия. Для выполнения этих действий нужно хранить например пути к нескольким каталогам, количество секунд, через которые должен происходить опрос этих каталогов, строка соединения с SQL-сервером и т.п.
А>В "боевом" режиме эта DLL-ка будет работать в виде службы. Отлаживать DLL-ку лучше обычным EXE-шником.

А>Итого имеем:
А>1. Создаю для DLL-ки свой setting-файл со всеми путями, интервалами времени, строками соединения и пр.
А>2. Подключаю DLL-ку (в том же домене) к WinForm'овскому EXE-шнику и отлаживаю.
А>3. После отладки, подключаю DLL-ку к EXE-шнику службы и ставлю на "боевое дежурство".

А>Мне для такого примитивного случая придется заморачиваться с неким дополнительным сервисом настроек???? Или я чего-то не понял?

Нет, это самый обычный сценарий. Создаёте Settings-файл в библиотеке. В проeкте библиотеки появится App.config примерно такого содержания:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name="MyLibrary.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <connectionStrings>
    <add name="MyLibrary.Properties.Settings.MyConnectionString"
      connectionString="Data Source = .\SqlExpress; Initial Catalog = MyDatabase; Integrated Security = True;"
      providerName="System.Data.SqlClient" />
  </connectionStrings>
  <applicationSettings>
    <MyLibrary.Properties.Settings>
      <setting name="MySetting" serializeAs="String">
        <value>My Setting Value</value>
      </setting>
    </MyLibrary.Properties.Settings>
  </applicationSettings>
</configuration>

Это — "заготовка" конфигурации со значениями по-умолчанию. При необходимости задать значения для приложения, необходимо в файл конфигурации _приложения_ скопировать необходимые секции.
Для строки соединения — <connectionStrings> (или <add>, если <connectionStrings> в конфигурации приложения уже есть),
для прочих сетингов — <configSections>/<sectionGroup>/<section>. Вроде, ничего сложного.

Здравствуйте, _FRED_, Вы писали:
_FR>необходимо в файл конфигурации _приложения_ скопировать необходимые секции.
_FR>Для строки соединения — <connectionStrings> (или <add>, если <connectionStrings> в конфигурации приложения уже есть),
_FR>для прочих сетингов — <configSections>/<sectionGroup>/<section>. Вроде, ничего сложного.
Если речь идет о расширении относительно независимого приложения, то способ так себе.
Помимо того, что нужно править конфиг основного приложения что уже плохо, так еще нужно как-то продумать как это все будет устанавливаться/удаляться/переживать апгрейды.

Может стоит поискать в сети реализацию какого-нибудь 'custom settings provider'-а который будет искать настройки в том файле в котором нужно нам? или не прокатит?

Здравствуйте, git, Вы писали:

_FR>>необходимо в файл конфигурации _приложения_ скопировать необходимые секции.
_FR>>Для строки соединения — <connectionStrings> (или <add>, если <connectionStrings> в конфигурации приложения уже есть),
_FR>>для прочих сетингов — <configSections>/<sectionGroup>/<section>. Вроде, ничего сложного.
git>Если речь идет о расширении относительно независимого приложения, то способ так себе.

Во-первых, о постороннем приложении речи небыло — зачем передёргивать?

git>Помимо того, что нужно править конфиг основного приложения что уже плохо,

Вообще-то, это приложение выбирает,Ю какими библиотеками оно, приложение, пользуется, поэтому разработчику библиотеки не надо "править конфиг основного приложения".

git>так еще нужно как-то продумать как это все будет устанавливаться/удаляться/переживать апгрейды.

А если речь про что-то плагиноподобное, то я и об этом написал выше

git>Может стоит поискать в сети реализацию какого-нибудь 'custom settings provider'-а который будет искать настройки в том файле в котором нужно нам? или не прокатит?

Вы мне советуете? Я меня таких провайдеров наделал не мало Но решение без них всегда казалось мне лучше, потому что кастомный провайдер каждый раз был необходим по причине несовершенства какой-то другой части приложения. И избавление от кривизны там позволяло решить задачу более "стандартно", ьез колдунства — а написание своего провайдера весьма колдунская и запутанная штука.

Здравствуйте, _FRED_, Вы писали:

_FR>Во-первых, о постороннем приложении речи небыло — зачем передёргивать?
глаз зацепился в ветке выше за
А>например, я пишу расширение для некой системы, главное приложение знать не знает о существовании моей dll — и как в этом случае быть?
но да, это вопрос не топик стартера.

_FR>А если речь про что-то плагиноподобное, то я и об этом написал выше
это вот это: (?)
_FR>Во-вторых, именно "расширению" было бы логично завязываться вообще не на конфиг-файл, а на некий сервис настроек, который для расширения предоставляет хост.
с одной стороны правильно, с другой интересно как разрулить ситуацию если настройки нужны "вчера", а инфраструктуры нет.

_FR>Вы мне советуете?
Я интересуюсь будет ли работать и насколько трудоемкое решение

_FR>Я меня таких провайдеров наделал не мало Но решение без них всегда казалось мне лучше, потому что кастомный провайдер каждый раз был необходим по причине несовершенства какой-то другой части приложения.
Это понятно, но интересно было бы посмотреть такую реализацию (мало ли), может кинете пару ссылок если есть?

Здравствуйте, git, Вы писали:

_FR>>А если речь про что-то плагиноподобное, то я и об этом написал выше
git>это вот это: (?)
_FR>>Во-вторых, именно "расширению" было бы логично завязываться вообще не на конфиг-файл, а на некий сервис настроек, который для расширения предоставляет хост.
git>с одной стороны правильно, с другой интересно как разрулить ситуацию если настройки нужны "вчера", а инфраструктуры нет.

В таком случае не понятна критика [?] в сторону майкрософта про неудобность настроек Все претензии: к разработчику хоста, к которому пишется расширение.

_FR>>Вы мне советуете?
git>Я интересуюсь будет ли работать и насколько трудоемкое решение

Будет, не шибко. Если реализовывать все фичи сеттингов, то работа кропотливая. Но я вот не видел ещё что бы кто-то пользовался бы какими-о фичами сетингов окромя заполнение датагрида в дизайнере. А это не сложно.

_FR>>Я меня таких провайдеров наделал не мало Но решение без них всегда казалось мне лучше, потому что кастомный провайдер каждый раз был необходим по причине несовершенства какой-то другой части приложения.
git>Это понятно, но интересно было бы посмотреть такую реализацию (мало ли), может кинете пару ссылок если есть?

А что там сложного? Нужно написать свой SettingsProvider. Пример реализации во фреймворке есть.

Здравствуйте, git, Вы писали:

_FR>>необходимо в файл конфигурации _приложения_ скопировать необходимые секции.
_FR>>Для строки соединения — <connectionStrings> (или <add>, если <connectionStrings> в конфигурации приложения уже есть),
_FR>>для прочих сетингов — <configSections>/<sectionGroup>/<section>. Вроде, ничего сложного.
git>Если речь идет о расширении относительно независимого приложения, то способ так себе.

Кстати вот тоже не понятно:

git>Помимо того, что нужно править конфиг основного приложения что уже плохо,

Почему это плохо ИМХО, совершенно не очевидно и совсем не плохо, благо Configuration позволяет.

git>так еще нужно как-то продумать как это все будет устанавливаться/удаляться/переживать апгрейды.

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

Здравствуйте, _FRED_, Вы писали:

_FR>Это — "заготовка" конфигурации со значениями по-умолчанию. При необходимости задать значения для приложения, необходимо в файл конфигурации _приложения_ скопировать необходимые секции.

Таким образом, для WinService-стартера (EXE-шник) будет свой config-файл (в который надо скопировать интересующие меня секции из app.config моей DLL-ки), для тестового WinForms-EXE-шника — свой config-файл (куда тоже надо скопировать те же секции)? А потом мне надо будет поменять значение какого-нибудь настраиваемого пути и придется править его в config-ах обоих EXE-шников???
Не смертельно, конечно, в два файла идентичные изменения внести, но мне хотелось бы этого избежать!