>Может что - нибудь вроде ini - файла сделать?

Да хоть хоть в Isolated Storage в XML формате!
Предлагаю вам сходить на http://www.codeproject.com Насколько помню там полно было готовых примеров для сохранения настроек - начиная от AppConfig и заканчивая реестром. Даже вроде попадались простые решения, когда создается класс, с необходимыми свойствами (настройками), который потом просто сериализуется и десериализуется в XML формате.

> Microsoft Configuration Management Block.

Ага про этот я и забыл, там даже вроде, если мне память не изменяет, шифрование настроек предусмотрено.

>Не понимаю чем это некрасиво писать в реестр?
INI файл кстати менее универсален - например, длясохранения настроек разных пользователей придется вручную изгалятся с секциями, вместо того чтобы нармально записать настройки каждого пользователя в соотв. ветку реестра...

Ну во первых, одно из рекомендаций MS по dot NET это принцип xcopy.
А во-вторых, разве сложно писать в разные файлы для каждого пользователя или в разные секции при использовании INI файла или XML файла.

>Условие сохранения настроек в соотв. ветке реестра является кстати одним из требований для получения для софта статуса "Compatible with Microsoft Windows <XP/2000>"

А мы все уже пишем Compatible with MS Windows 2003 and Longhorn :-)

>XML файлы самые удобные для хранения конфы.

Однако производительность у INI файлов выше чем у XML, если это является критическим моментом. А у реестра на сколько я помню производительнось еще выше чем у INI :-)

P.S. сам использую XML для сохранения настроек :-)

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

А если в число настроек входит строка подключения к этой БД :-)

>не ну эти вещи надо разделять, строку можно хранить в реестре, все остальное в бд

ИМХО Тогда получается винегрет.

Если использовать туже самую БД с которой необходимо работать, то специальная таблица для настроек клиенсткого приложения, как то не будет вписываться в реальную структуру БД.

Если использовать другую специально созданную для этого БД - это лишние затраты

Так же - смотря что подразумевать под настройками, например если в число настроек входит внешний вид форм пользовательского приложения. То я хотел бы выдать сообщение о том что БД не доступна так, как это "нравиться" определенному пользователю, а не по дефолтным настройкам этой формы (Так как считать настройки определенного пользователя из БД в этом случае я не смогу).

В этом способе слишком много негативного чтобы он практически использовался, хотя мне попадались коммерческие приложения которые использовали СУБД для своих настроек, но это были сугубо "заточенные" под это СУБД "тулзы".

>хотя это для многопользовательских прог

Для многопользовательских прог придумана папка Document and Settings (см. также "блуждающие пользователи") и очень легко получить доступ к Isolated Storage и хранить настройки для каждого пользователя в отдельных файлах в этой папке.

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

База данных - как отражение сущностей реального мира, ИМХО таблица с настройками сюда не очень вписывается.

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

А если баз данных с которыми осуществляет работу приложение несколько?
Тогда хранить настройки сразу во всех БД, или настраивать репликацию?
А также: При недоступности базы данных с настройками закрывать приложение и не давать работать с базами, которые доступны? Или работать, но только уже
с дефолтными настройками пользователя. Или избыточно помимо базы данных хранить настройки еще и в реестре, ini, xml файлах?

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

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

И все же я не хороню эту идею, но у нее намного больше минусов чем плюсов :-)