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

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

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

из exe, где этот плагин используется

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

Что будет если exe "вообще не на .NET" — хз. Но согласись это извращение, а требовать чтобы стандартный Settings api поддерживал все извращения — это было бы странно.

_FR>А так, конечно-же, вполне иногда приемлемый вариант.

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

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

не понял, какие у топикстартера проблемы с дублированием. Его проблема в том, что он почему-то решил что dll берет параметры из <имя_dll-ки>.config, тогда как все dll приложения берут их из <имя exe>.config и user.config, опять же общего для exe и всех dll

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

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

Тогда отлично user settings подойдёт. На такой сценарий всё как раз прекрасно расчитано.

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

Это ты Андрею скажи — это он недоволен, что на его экзотический случай не предусмотрено "компонента"

OE>не понял, какие у топикстартера проблемы с дублированием. Его проблема в том, что он почему-то решил что dll берет параметры из <имя_dll-ки>.config, тогда как все dll приложения берут их из <имя exe>.config и user.config, опять же общего для exe и всех dll

Нет, после того, как ему объяснили в чём дело, ему не понравилось, что нужно по нескольку раз одно и то же указывать: здесь

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

.