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

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

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

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

Если везде, где используется конфиг, эти пути должны быть одинаковыми, можно изменить в одном месте: в значении параматра по-умолчанию. Если же они могут быть разными, то и надо менять в каждом месте независимо: что вас смущает Дублировать же сеттинги указанные, например, при инсталляции — дело инсталятора, то есть кода, которому обновить один файл или два не должно составить труда.

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

skip

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

но расширения пишутся к совершенно буржуйской программе (если хочется конкретики, то ArcGIS)
и лезть в ее конфиги нет никакого желания, и возможности тоже, кстати

про возможность связать config DLL с отдельным AppDomain я в курсе, но в данном случае это не вариант — ArcMap и ArcCatalog написаны вообще не на .NET и общаюсь я с ними через COM-wrappers
а уж как они грузят расширения — только программистам ESRI известно

так что пришлось написать свои обработчики config-файлов, для чтения настроек мне их хватает

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

А>но расширения пишутся к совершенно буржуйской программе (если хочется конкретики, то ArcGIS)
А>и лезть в ее конфиги нет никакого желания, и возможности тоже, кстати

А>про возможность связать config DLL с отдельным AppDomain я в курсе, но в данном случае это не вариант — ArcMap и ArcCatalog написаны вообще не на .NET и общаюсь я с ними через COM-wrappers
А>а уж как они грузят расширения — только программистам ESRI известно

Ну вот сколько специфики хоста. Учтём ещё специфику конфигураций дотнета: версионность, привязка к пользователю, роаминг и прочее: написать универсальный тул на все случаи жизни было бы ой как не просто.

А>так что пришлось написать свои обработчики config-файлов, для чтения настроек мне их хватает

Так всё правильно: написать решение под свою конкретную узкую задачу не так и сложно. Всё "логично" и это не "извращения".

Мог бы ты конкретно что-нибудь сказать о том, чего не хватает Configuration API, что бы в твоём случае было бы проще подцепить в расширении файл конфигурации? Вообще говоря, всё что нужно — это SettingsProvider — реализация абстрактного класса — что тут "извращенческого" и "не логичного"-то?

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

skip

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

"извращенческого" и "не логичного" — это не мои слова, а топик-стартера, так что вопрос не ко мне

вообще, с моей точки зрения, было бы логично дать возможность читать/писать config-файлы для DLL в стиле app-config
я много чего читал на эту тему, когда столкнулся с проблемой, но так и не нашел внятного объяснения, почему в MS этого не сделали

очень нелогично в данном случае выглядит поведение студии: app-config файл для DLL создается без всякого писка, и редактируется средствами студии вполне себе хорошо, и обертки создаются как надо
и можно долго даже не подозревать о том, что на самом деле в твоей DLL параметры не читаются из конфигурационного файла, а тупо берутся из вшитых при компиляции ресурсов

ведь на самом деле при написании оберток врукопашную приходится вновь и вновь делать то, что уже давно сделано и прекрасно работает для app-config

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

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

А>"извращенческого" и "не логичного" — это не мои слова, а топик-стартера, так что вопрос не ко мне

Пардон: слова я взял отсюда

Автор: Андрей
Дата: 29.06.10

.

А>вообще, с моей точки зрения, было бы логично дать возможность читать/писать config-файлы для DLL в стиле app-config
А>я много чего читал на эту тему, когда столкнулся с проблемой, но так и не нашел внятного объяснения, почему в MS этого не сделали

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

А>очень нелогично в данном случае выглядит поведение студии: app-config файл для DLL создается без всякого писка, и редактируется средствами студии вполне себе хорошо, и обертки создаются как надо
А>и можно долго даже не подозревать о том, что на самом деле в твоей DLL параметры не читаются из конфигурационного файла, а тупо берутся из вшитых при компиляции ресурсов

А просто надо понимать, для чего создаётся студией App.config в проекте-библиотеки (создаётся для примера того, что переносить в конфиг хоста)
и понимать, что редактировать его следует не руками, а через дизайнер. Все непонятки должны сами уйти.

А>ведь на самом деле при написании оберток врукопашную приходится вновь и вновь делать то, что уже давно сделано и прекрасно работает для app-config

Оно так прекрасно работает потому, что app.config один на домен. Не совсем очевидно, как на отдельно-взятую библиотеку должны распространятся какие-то свои конфигурации. Вот например, твоей библиотеки требуется сконфигурить конфигурация секций <system.net> или какой-нить <cryptographySettings> или хоть бы <system.diagnostics>. каким образом рантайм должен для вызовов из твоей библиотеки подстраиваться этак, а для вызовов из другой подстраиваться иначе? Или рантайм должен сам смёрджить все конфиги в один при старте и предоставлять всем что-то общее? Тогда как быть с конфликтами, когда две библиотеки на законных, заметь, основаниях, имеют противоречивые настройки? Да и как рантайм смог бы определить, какие библиотеки будут загружаться, а какие не будут? Не-не-не.

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

skip

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

вот здесь-то и возникает засада: мощный и настраиваемый во все стороны Configuration API оказывается совершенно бесполезным
теперь-то я понимаю, что Configuration API совсем для другого предназначен, из-за этого и проблемы

но когда я с этим впервые столкнулся, я был также обескуражен, как топик-стартер

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

ведь позволяет же Configuration API хранить пользовательские настройки для приложения: и читать, и писать без проблем

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

А>в данном случае меня абсолютно не интересуют глобальные настройки

Замечательный, полезнейший ответ

А>мне интересны мои личные параметры, про которые кроме меня никто больше не знает и никто их не использует

И никто кроме тебя не сможет лучше решить, что с ними делать: как их хранить и как загружать. Например, кому-то может понадобиться всё то же самое, только что б можно было бы через UI настраивать — а там возникают новые трудности, связанные с тем, как и где хранить эти изменения. Лучше тебя самого это определить не сможет никто — вот и определяй сам.

А>вот здесь-то и возникает засада: мощный и настраиваемый во все стороны Configuration API оказывается совершенно бесполезным
А>теперь-то я понимаю, что Configuration API совсем для другого предназначен, из-за этого и проблемы

Не для "совсем другого", а для других сценариев. Это во-первых. Во-вторых, пользователь может сам реализовать недостающие ему сценарии. Это действительно мощный API, хоть и немного странный.

А>но когда я с этим впервые столкнулся, я был также обескуражен, как топик-стартер

В первый раз в жизни? Если бы я ругал или считал не логичным всё, что меня обескураживает, моя жизнь была бы много тяжелее Ну мало ли ошибся — бывает, многие через это прошли.

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

Нет, потому что всем от настроек нужно разное. Согласись, что если бы все делали бы всё так, как предполагается по Configuration и другим API, то гемороя бы небыло. Геморой появляется тогда, когда кто-то не разабравшись наваяет что-то своё. Очень странно разрабатывать API, который бы обещал простую жизнь при любом этом "наваянном". Пойми: в твоём случае быть может проще всего пользоваться обычной Xml Serialization — зачем тебе Configuration API со всеми своими мощностями-то не могу я понять Нет вот надо все эти мощности но на "мои личные параметры", в которых нет ничего сложного по сравнению со сложностями, которые решают встроенный настройки.

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

А>согласись, что можно было дать возможность хранить в конфигурационных файлах свои данные и работать с ними без геморроя с постоянным написанием собственных велосипедов
А>ведь позволяет же Configuration API хранить пользовательские настройки для приложения: и читать, и писать без проблем

непойму чего собственно так уперлись в app settings, можно же использовать user setings, ну настроит их каждый юзер один раз под себя (даже удобнее), зато никаких велосипедов

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

_FR>Почему это плохо
Ну это же чужой конфиг. Если при установке расширение его поломает будет очень неприятно, а если всё свое, то всегда можно файлы удалить и всё будет как было. Но может быть это мои личные тараканы.

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

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

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

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

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

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

Автор: _FRED_
Дата: 30.06.10

про глобальные настройки — если они понадобятся, как вы думаете их нужно задавать? Только через главный конфиг. Обсуждать только пользовательские настройки ой как не интересно — они решаются SettingsProvider-ом.

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

Так я не понял? Вы соми свои приложения разрабатываете или плугины пишите для чего-то другого? Если экзюки пишите сами — поступать очень просто. Будьте добры точнее сформулировать свои запросы, ибо тема стольль обширна, а каждому нужно чего-то своего.

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

А>>согласись, что можно было дать возможность хранить в конфигурационных файлах свои данные и работать с ними без геморроя с постоянным написанием собственных велосипедов
А>>ведь позволяет же Configuration API хранить пользовательские настройки для приложения: и читать, и писать без проблем

OE>непойму чего собственно так уперлись в app settings, можно же использовать user setings, ну настроит их каждый юзер один раз под себя (даже удобнее), зато никаких велосипедов

Во-первых, connectionStrings всё-таки глобальная штука. Во-вторых — там теже проблемы. Смотри: есть плугин к "ЧёртеЗнаетЧто Студио" при установке которого пользователь вводит (или автоматически определяются) различные переметры. Из инсталятора их нужно куда-то сохранить, что бы их программы потом было не сложно их получить (на счёт того, нужно ли менять, мне так и не ответили). AppSettings я, по крайней мере, называю всё вместе — и пользовательское и глобальное. Не виду, как именно UserSettings могли бы задачу решить — то, где они сохраняются тоже та ещё история

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

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

Мвайкрософт-то как раз много более сферический, чем разработчик какого-то конкретного продукта. Или кто-то пишет плугины "к Майкрософту"?

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

_FR>Во-первых, connectionStrings всё-таки глобальная штука.

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

_FR>Во-вторых — там теже проблемы. Смотри: есть плугин к "ЧёртеЗнаетЧто Студио" при установке которого пользователь вводит (или автоматически определяются) различные переметры. Из инсталятора их нужно куда-то сохранить, что бы их программы потом было не сложно их получить (на счёт того, нужно ли менять, мне так и не ответили). AppSettings я, по крайней мере, называю всё вместе — и пользовательское и глобальное. Не виду, как именно UserSettings могли бы задачу решить — то, где они сохраняются тоже та ещё история

открыли диалог настроек плагина, подкорректировали, нажали Save, в коде — только стандартные функции Settings api, ну и что, что оно сохранится где-то в дебрях Documents and Settings По крайней мере в самом первом сообщении-вопросе не было никаких требований, что параметры должны настраиваться из инсталлятора или еще чего-то критичного для такого сценария.

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

skip

а что, разве user settings работают для DLL?

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

_FR>>Во-первых, connectionStrings всё-таки глобальная штука.

OE>ну по мне так не настолько это принципиально, чтоб городить собственный огород для хранения настроек

_FR>>Во-вторых — там теже проблемы. Смотри: есть плугин к "ЧёртеЗнаетЧто Студио" при установке которого пользователь вводит (или автоматически определяются) различные переметры. Из инсталятора их нужно куда-то сохранить, что бы их программы потом было не сложно их получить (на счёт того, нужно ли менять, мне так и не ответили). AppSettings я, по крайней мере, называю всё вместе — и пользовательское и глобальное. Не виду, как именно UserSettings могли бы задачу решить — то, где они сохраняются тоже та ещё история

OE>открыли диалог настроек плагина, подкорректировали, нажали Save, в коде — только стандартные функции Settings api, ну и что, что оно сохранится где-то в дебрях Documents and Settings

Открыли диалог из инсталятора?

А если хост, как у Андрея и "написаны вообще не на .NET и общаюсь я с ними через COM-wrappers а уж как они грузят расширения — только программистам ESRI известно" — вдруг они домены, в которых .NET-плугины запускают через такую дырку создают, что пути каждый раз будут по-разному вычисляться А так, конечно-же, вполне иногда приемлемый вариант.

OE>По крайней мере в самом первом сообщении-вопросе не было никаких требований, что параметры должны настраиваться из инсталлятора или еще чего-то критичного для такого сценария.

Ну а какая разница при установке руками xml править или редактировать через диалог — у топикстартера проблема была в том, что ему не хочется дублирования — а дублирование будет не в правке хмл, а в заполнении настроек.

Здравствуйте, _FRED_, Вы писали:
_FR>зачем тебе Configuration API со всеми своими мощностями-то не могу я понять
Это вопрос к MS, почему "Configuration API со всеми своими мощностями" не помогает решить простую задачу. Как будто сценарий, когда основная функциональность зашита в библиотеке (и как раз библиотека имеет собственные настройки), а приложения являются тупыми фронтендами (которые в т.ч. шарят все глобальные настройки) — это что-то экзотическое. Тот ж svn так сделан.

_FR>сложностями, которые решают встроенный настройки
Мне вот видится, что configuration api решает какую-то конкретную сложность (где-нить в районе aspnet или sqlclr или еще какого-то продукта, на котором MS в конечном счете зашибает бабки) — но никак не предназначен для облегчения жизни разработчику.

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

А>а что, разве user settings работают для DLL?

точно также как для exe, настройки хранятся в exe-шном user.config

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

MC>Мне вот видится, что configuration api решает какую-то конкретную сложность (где-нить в районе aspnet или sqlclr или еще какого-то продукта, на котором MS в конечном счете зашибает бабки) — но никак не предназначен для облегчения жизни разработчику.

мне облегчает в том числе в приложениях где кроме exe несколько dll и у каждой свои настройки, как то все время обходился только configuration api

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

_FR>>зачем тебе Configuration API со всеми своими мощностями-то не могу я понять
MC>Это вопрос к MS, почему "Configuration API со всеми своими мощностями" не помогает решить простую задачу. Как будто сценарий, когда основная функциональность зашита в библиотеке (и как раз библиотека имеет собственные настройки), а приложения являются тупыми фронтендами (которые в т.ч. шарят все глобальные настройки) — это что-то экзотическое. Тот ж svn так сделан.

С чего ты взял, что задача "простая"? Простая задача должна иметь простое решение. Судя по имеющемуся в данном топике сыр-бору, простого в реализации решения нет. Так почему задача простая? Совсем нет. Конкретный сценарий может быть простым. А то, что "простой" сценарий может не иметь просто решения вполне объяснимо. На месте разработчиков BCL реализовывать кучу простеньких сценариев я бы не взялся. А "кучу" — именно "кучу", потому что мне так и не ответили, требуется ли сохранять так горячо обсуждаемые настройки. Если не требуется — то это один колинкор. Если требуется — то всё соооооовсем другое.

_FR>>сложностями, которые решают встроенный настройки
MC>Мне вот видится, что configuration api решает какую-то конкретную сложность (где-нить в районе aspnet или sqlclr или еще какого-то продукта, на котором MS в конечном счете зашибает бабки) — но никак не предназначен для облегчения жизни разработчику.

Я с этим не согласен, но спорить надоело: мне мои задачи удаётся прекрасно решать имеющимся инструментарием, и когда этот самый инструментарий мне нужно прикрутить, серьёзных проблем, о которых хотелось бы пожаловаться, я не вижу. Наверное, у меня руки не из того места растут или задачи слишком детские. Простите, не буду отвлекать вас от обсуждения серьёзных тем.