Куда в .NET модно сохранять пользовательские настройки? Есть три варианта:
1. В реестр. С точки зрения MS, идеологически неправильно. Кроме того, этот способ конфликтует с Zero-Impact Installation (удалить сборку с помощью del assebly.exe уже нельзя — в системе останется мусор в реестре)
2. XML файл в каталоге со сборкой. Всё здорово, но на NT, 2000 и XP возникают проблемы с доступом к этому файлу на запись.
3. XML-файл в %CSIDL_APPDATA% и схожие локации. Ничем не лучше реестра. Чистое удаление сборки можно произвести только деинсталлятором.

Т. е., насколько я понимаю, Zero-Impact приложения вообще не должны сохранять пользовательские настройки? А MS рекомендует все сборки сделать такими... Где хранить?

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

А>Т. е., насколько я понимаю, Zero-Impact приложения вообще не должны сохранять пользовательские настройки? А MS рекомендует все сборки сделать такими... Где хранить?

Для этого есть изолированое хранилище. Нужно использовать его а не изобреться велосипед.

TK>Для этого есть изолированое хранилище. Нужно использовать его а не изобреться велосипед.

А оно будет чиститься при удалении каталога с прогой?
А такие настройки можно будет перенести на другой комп или сбекапить удобно для юзера?

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

TK>>Для этого есть изолированое хранилище. Нужно использовать его а не изобреться велосипед.
Isolated Storage хранится в CSIDL_APPDATA, так что ничем не лучше 3-го пункта.

IT>А оно будет чиститься при удалении каталога с прогой?
Нет. Проверил. Даже более того, не поддерживается изоляция по версии сборки. При инсталляции новой версии сборки куда-либо в другой каталог она получит тот же Store, что и старая версия сборки. В результате, если они обе присутствуют в системе, будет конфликт настроек, который оччень трудно разрешить. Такое поведение Isolated Storage легко проверить через storeadm.exe

IT>А такие настройки можно будет перенести на другой комп или сбекапить удобно для юзера?
Нет, конечно. Хотя Roaming обеспечить можно.

Так что — ничуть не лучше 3 первоначального пункта.

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

TK>>Для этого есть изолированое хранилище. Нужно использовать его а не изобреться велосипед.

IT>А оно будет чиститься при удалении каталога с прогой?

А какая разница? Вы не задумавались о том, что посещая эту страничку можно сохранить на Вашем компьютере до 128кб данных? А если их две? 256к. Вы много задумавались где это хранится, когда будет удалено и т.п.?

IT>А такие настройки можно будет перенести на другой комп или сбекапить удобно для юзера?

Конечно современные пользователи используют для этого File And Settings Transfer Wizard. или роаминговые профили.

Если очень нужно, то прога должна сама предоставлять возможность для экспорта/импорта настроек...

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

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

TK>>>Для этого есть изолированое хранилище. Нужно использовать его а не изобреться велосипед.
А>Isolated Storage хранится в CSIDL_APPDATA, так что ничем не лучше 3-го пункта.

Какая разница где это хранится? Никто не обещает точного расположения...

IT>>А оно будет чиститься при удалении каталога с прогой?
А>Нет. Проверил. Даже более того, не поддерживается изоляция по версии сборки. При инсталляции новой версии сборки куда-либо в другой каталог она получит тот же Store, что и старая версия сборки. В результате, если они обе присутствуют в системе, будет конфликт настроек, который оччень трудно разрешить. Такое поведение Isolated Storage легко проверить через storeadm.exe

А зачем ей получать другое хранилище? Это даст больше проблем, чем принесет. И потом, кто запрещает для разных сборок использовать разные потоки?

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

TK>А какая разница? Вы не задумавались о том, что посещая эту страничку можно сохранить на Вашем компьютере до 128кб данных? А если их две? 256к. Вы много задумавались где это хранится, когда будет удалено и т.п.?
1. Мне достаточно того, что это БУДЕТ удалено. С Isolated Storage при простом удалении сборки эти данные НИКОГДА не будут удалены.
2. В составе UI Internet Explorer есть средства для просмотра и удаления настроек. В том числе выборочного. Что мы имеем в Isolated Storage? Единственная утилита — storeadm, которая, мало того, что поставляется только с SDK, единственное, что умеет — удалять ВСЕ настройки разом для данного пользователя.

TK>Конечно современные пользователи используют для этого File And Settings Transfer Wizard. или роаминговые профили.
TK>Если очень нужно, то прога должна сама предоставлять возможность для экспорта/импорта настроек...
Бесспорно. Хотя совместимость с Files And Settings Transfer Wizard тоже не помешает. Одна проблема — чтобы их импортировать/экспортировать, их надо уметь где-то хранить... Вот тут то мы и возвращаемся к первоначальному вопросу.

TK>А зачем ей получать другое хранилище? Это даст больше проблем, чем принесет. И потом, кто запрещает для разных сборок использовать разные потоки?

То есть получается нельзя поставить два экземляра одной и той же программы? Для одного и того же юзера?

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


TK>>А зачем ей получать другое хранилище? Это даст больше проблем, чем принесет. И потом, кто запрещает для разных сборок использовать разные потоки?

DG>То есть получается нельзя поставить два экземляра одной и той же программы? Для одного и того же юзера?

Что мешает использовать изоляцию на уровне домена?

DG>>То есть получается нельзя поставить два экземляра одной и той же программы? Для одного и того же юзера?

TK>Что мешает использовать изоляцию на уровне домена?

А что это такое?

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


DG>>>То есть получается нельзя поставить два экземляра одной и той же программы? Для одного и того же юзера?

TK>>Что мешает использовать изоляцию на уровне домена?

DG>А что это такое?

То, что настройки будут уникальны для конкретного приложения, а не сборки.

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

TK>А зачем ей получать другое хранилище? Это даст больше проблем, чем принесет. И потом, кто запрещает для разных сборок использовать разные потоки?
Есть две сборки: c:\test\test.exe и c:\test2\test.exe. Первая имеет версию 1.0, вторая — 2.0. DTD конфигурационных файлов первой сборки не соответствует DTD файлов второй. Имеем: клиент запускает первую сборку, видит, что DTD не соответсвует её формату, обнуляет настройки, пользователь вынужден вводить их заново. Первая сборка их сохраняет, портя при этом данные второй сборки.

Если тебе не сложно, объясни, что такое "для разных сборок использовать разные потоки"? Какие потоки?

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

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

TK>
DG>>>>То есть получается нельзя поставить два экземляра одной и той же программы? Для одного и того же юзера?

TK>>>Что мешает использовать изоляцию на уровне домена?

DG>>А что это такое?

TK>То, что настройки будут уникальны для конкретного приложения, а не сборки.
Автоматического назначения домена для приложения, просто перенесённого в отдельный каталог не происходит. Или я не прав?

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

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

TK>>А зачем ей получать другое хранилище? Это даст больше проблем, чем принесет. И потом, кто запрещает для разных сборок использовать разные потоки?
А>Есть две сборки: c:\test\test.exe и c:\test2\test.exe. Первая имеет версию 1.0, вторая — 2.0. DTD конфигурационных файлов первой сборки не соответствует DTD файлов второй. Имеем: клиент запускает первую сборку, видит, что DTD не соответсвует её формату, обнуляет настройки, пользователь вынужден вводить их заново. Первая сборка их сохраняет, портя при этом данные второй сборки.

Зачем она это делает?

А>Если тебе не сложно, объясни, что такое "для разных сборок использовать разные потоки"? Какие потоки?

Что мешает передать в IsolatedStorageFileStream другое имя?

TK>Что мешает передать в IsolatedStorageFileStream другое имя?
Основанное на версии сборки? Да, неплохая идея. И она здорово работает для обычных программ (с деинсталлятором). Но основная проблема Zero-Impact сборок состоит как раз в том, что эти настройки никто никогда не удалит. Куда их писать? Я задавал этот вопрос на IDF в Москве и в конференциях news.microsoft.com, но так и не получил достойного ответа. Так что мне всё больше и больше кажется, что Zero-Impact — это фикция, не предназначенная для реального применения.

BTW, не знаешь ли ты альтернативных storeadm.exe утилит управления Isolated Storage?

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

TK>>То, что настройки будут уникальны для конкретного приложения, а не сборки.
А>Автоматического назначения домена для приложения, просто перенесённого в отдельный каталог не происходит. Или я не прав?

Нет, не прав. Изолированное хранилище достаточно гибкий инструмент.

Данное хранилище будет завистить от имени файла приложения:

IsolatedStorageFile.GetStore(IsolatedStorageScope.User | IsolatedStorageScope.Domain | IsolatedStorageScope.Assembly, typeof(System.Security.Policy.Url), typeof(System.Security.Policy.Url))

А вот это от сильного имени:

IsolatedStorageFile.GetStore(IsolatedStorageScope.User | IsolatedStorageScope.Domain | IsolatedStorageScope.Assembly, typeof(System.Security.Policy.StrongName), typeof(System.Security.Policy.StrongName))

TK>Нет, не прав. Изолированное хранилище достаточно гибкий инструмент.

TK>Данное хранилище будет завистить от имени файла приложения:

А пользователь это настроить может? Или это делается только из самой программы?

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

А>2. XML файл в каталоге со сборкой. Всё здорово, но на NT, 2000 и XP возникают проблемы с доступом к этому файлу на запись.

Какие проблемы? Вон в янусе вроде бы никаких проблем не наблюдается.

AVK>Какие проблемы? Вон в янусе вроде бы никаких проблем не наблюдается.

Тебе просто повезло, что Янус используют под админским аккаунтом, в реальной жизни у пользователей нет прав на запись в Program Files.

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

DG>Тебе просто повезло, что Янус используют под админским аккаунтом, в реальной жизни у пользователей нет прав на запись в Program Files.

Значит надо такие права добавлять. Например при инсталляции — инсталлировать то будут все равно под админским аккаунтом. Или не ставить софт в Program Files.