А почему бы и нет?t.NET "настройки приложения" хранятся в реестре?

Принятие зависимости от реестра предотвращаетразвертывание XCOPY .

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

• реестр огромен, поэтому найти соответствующую информацию (даже с помощью поиска) может быть затруднительно.
• при изменении реестра можно случайно повлиять на другие приложения.
• при повреждении реестра могут пострадать все приложения (включая ОС).
• Вам нужны специальные инструменты для поиска, изменения и даже копирования реестра.

Я предпочитаю конфигурационные файлы.

Это потому, что реестр-уродливый кошмар для использования, и людям это не понравилось. Он также не поддерживал развертывание xcopy. С помощью xml-файлов для настройки вы можете перемещать приложение с компьютера на компьютер без необходимости установки. Это была одна из самых больших жалоб на написание кода еще в 90-х годах.

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

Одно непосредственное (но важное) преимущество:

С помощью файлов конфигурации plain пользователи могут легко восстановить свои настройки в случае переустановки / восстановления из резервной копии. Это намного сложнее сделать из значений реестра.

Одним из больших преимуществ перемещения в конфигурационные файлы над реестром является возможность параллельной установки одной и той же программы. С помощью реестра информация о центральной конфигурации будет перекрываться для этих повторяющихся установок, но с помощью файлов конфигурации информация хранится в секрете для каждой конкретной установки. Это правда, что пользовательские переопределения конфигурации потенциально могут перекрываться (поскольку они хранятся в папке данных приложения пользователя, а не в пути установки), но представьте себе сценарий, в котором разные пользователи используют разные установки, и в этом случае эта потенциальная проблема становится неуместной.

Я думаю, что одной из главных причин этого были обновления приложений. При установке обновления (например, с помощью ClickOnce) новые параметры фактически переходят в новую папку. Когда вы удаляете его, новая папка удаляется, а старые настройки все еще остаются. Если бы вместо этого использовался реестр, то не было бы никакого способа сделать это "управление версиями."

Другие причины могут включать:

• разрешения (настройки приложения всегда идут в AppData / LocalAppData, который не требует привилегии)
• Простота обслуживания / резервного копирования
• переносимость (довольно сложно работать с реестром, используя .NET Compact Framework, и да поможет вам Бог, если вы пытаетесь поддерживать Mono).

Мне кажется, что реестр - это одна из тех вещей, которые "казались хорошей идеей в то время" - по всем многим причинам, уже перечисленным другими. Нет ничего плохого в том, чтобы понять, что что-то не было такой уж великой идеей, и вместо этого использовать альтернативу, которая проще и удобнее, даже если это может показаться шагом назад в некоторых отношениях.

Я слышал довольно существенный слух о том, что формат хранения данных, используемый sharepoint и team foundation server, поддерживаемый SQL, первоначально предназначался для замены файловой системы windows в windows 7. Если бы это был план, то windows получила бы / (будет ли когда-нибудь?) получить транзакционное хранилище данных для хранения списков данных. Этот метод хранения данных, вероятно, будет превосходить реестр во всех отношениях.

Учитывая это, вряд ли удивительно видеть, как Microsoft минимизирует использование реестра по мере продвижения платформы .net framework.

Вместо того, чтобы просто использовать реестр

Реестр не являетсяпростым . На моем компьютере это 40 МБ двоичный беспорядок, и я надеюсь, что биты внутри него не передумают.

Разве это не именно то, что реестр был предназначен для?

Да. Но опять же, библиотеки DLLбыли предназначены для предоставления общей функциональности различным приложениям.

Я думаю по-новому .файл конфигурации помогает:

• предоставьте приложениям гибкость для предоставления своих собственных конфигураций в качестве замены конфигураций по умолчанию, предоставленных-рассмотрим случай web.конфигурация, переопределяющая машину.config
• Иногда невозможно изменить параметры реестра, так как у вас может не быть необходимых прав. Таким образом, конфигурационный файл позволяет вносить изменения, применимые для вашего собственного приложения, без необходимости дополнительного права
• с записью реестра несколько приложений потенциально могут использовать одну и ту же конфигурацию. Но если вы измените его для вашего приложения, вы можете вызвать непреднамеренное поведение для других приложений, и у вас может не быть полной информации об этом

Просто некоторые мысли, которые приходят в голову...

HTH.

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

Переносимость приложений может быть одной из причин. Папки приложений могут быть скопированы с одного компьютера на другой, и настройки будут идти вместе с приложением. Полезно при запуске приложений с usb-накопителей на нескольких компьютерах.

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

Я думаю, что основная причина исходит из"опыта COM". Весь принцип состоял в том, чтобы иметь компонентные объекты, зарегистрированные централизованно в реестре, чтобы любое приложение могло использовать его без необходимости копировать dll. Это быстро приводит нас к версионным проблемам. Несколько приложений могут вряд ли стоит использовать разные версии одного и того же компонента.

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

С .Net и взрывающейся емкостью жестких дисков и пропускной способностью, дублирование файлов больше не является проблемой. Наличие зависимостей, скопированных в вашу папку project значительно упрощает развертывание приложений. То же самое относится и к файлам конфигураций. Вы можете разместить несколько копий/версий одного и того же приложения без проблем с ограниченной архитектурой компьютера / пользователя реестра.

Microsoft предложила оба способа, потому что они имеют разные возможности. Например, если вы создадите какое-то приложение для использования в Active Directory, вы можете легко изменить настройки для тысяч компьютеров, даже если ваше приложение установлено в разных каталогах. Если вы выбрали xml, вы должны знать папки приложений для каждого компьютера или создать какой-нибудь умный скрипт, чтобы найти их. Но как многие говорили xml лучше для переносимости, настройки резервного копирования и прочего.

Итак, лучшего способа нет. Разработчики, которым нужен реестр-используют его напрямую. Это не так уж и сложно. Вероятно, именно поэтому Microsoft не делала настройки приложений в реестре.

Я думаю, что существует огромная проблема безопасности Настройки Приложения (.config files) - это то, что можно редактировать в любом текстовом редакторе и менять каждую вещь.

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

Или сохранить настройки в файле DLL, например.