Где хранить строку подключения, используемую многими приложениями на одном компьютере?

Question

В моем магазине мы используем для хранения строк соединений в файле .config. Но когда нам пришлось обновить его в нескольких приложениях на одной машине, кто-то предложил сохранить его в реестре Windows.

Это хорошая идея? Каковы последствия (безопасность)?

Answer 1

Вы можете сохранить его в machine.config. Все файлы .config будут наследовать любые строки подключения, определенные в них, если они явно не очищены.

Answer 2

Мы храним общие данные в реестре в зашифрованном виде. Модификация Machine.config - очень страшная операция. ;) Одним из недостатков является безопасность реестра. И 64-битные окна могут сделать работу с реестром очень странной. особенно в режиме WoW.

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

Answer 3

Может быть, у вас просто есть общий компонент (WCF или другой), на который вы ссылаетесь для строк подключения. Таким образом, вам нужно будет хранить строку только в одном месте.

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

Answer 4

Я согласен с методом machine.config. Однако более простой способ сделать это - создать каталог где-нибудь в вашей файловой системе с зашифрованным XML-файлом. Например, используйте Dpapi, а затем просто создайте общий класс, который читает, расшифровывает файл и возвращает строку подключения. Не забудьте использовать запасной метод для получения данных конфигурации, если кто-то удалит этот файл. Как указывалось ранее, machine.config может быть перезаписан, то же самое относится и к этому подходу. Права доступа к каталогу могут использоваться для установки ограничений на чтение и запрета записи всем, кроме разработчиков. Это должно держать его в безопасности от «случайно» перезаписаны и в то же время гарантировать, что никто не может прочитать данные там (хотя это спорный вопрос без ключа)