Почему.NET “параметры настройки приложения” не хранится в реестре?
Некоторое время назад в девяностых, Microsoft представила Windows Registry. Приложения могли сохранить настройки при другой крапивнице. Была крапивница для и определенных для пользователя объемов всего приложения, и они были помещены в соответствующие местоположения, так, чтобы профили роуминга работали правильно.
В.NET 2.0 и, у нас есть эта вещь под названием Параметры настройки приложения. Приложения могут использовать их для хранения настроек в XML-файлах, app.exe.config и user.config. Это для и определенных для пользователя объемов всего приложения, и они помещаются в соответствующие местоположения, так, чтобы профили роуминга работали правильно.
Знакомый звук? Какова причина, что эти Параметры настройки приложения поддерживаются XML-файлами, вместо того, чтобы просто использовать реестр? Разве это не точно, для чего был предназначен реестр?
Единственная причина, о которой я могу думать, состоит в том, что реестр является определенным для Windows, и.NET пытается быть платформенно независимой. Действительно ли это было (или) причина или является там другими соображениями, что я пропускаю?
16 ответов
Я не думаю, что это один ответ, я думаю, что это комбинация:
- Реестр на момент его создания выглядел хорошей идеей для хранить все настройки для всех программ в одном месте, в отличие от файлов .ini, которые обычно использовались ранее. В то время, когда это увеличивало производительность, поскольку чтение небольших файлов .ini с медленных жестких дисков было дорогостоящим, использование одного файла реестра несколько увеличивало производительность. Теперь все по-другому, поскольку жесткие диски работают намного быстрее, и все больше и больше настроек сбрасывается в реестр, что создает нагрузку на систему.Вы увидите это, если вы установите и удалите много программ в Windows, она начинает замедляться, и в конечном итоге вы, вероятно, переформатируете.
- Неправильная запись в реестр даже в текущих пользовательских настройках может разрушить вашу систему.
- Реестр не помогает копировать развертывание программ без специального кода, чтобы справиться с отсутствием ключей реестра ... Это включает удаление программ путем простого удаления папки во многих случаях.
- Для установки приложения могут потребоваться дополнительные разрешения, если ему нужен доступ к реестру.
- Файл .config легко разрешает приложение по умолчанию и пользовательские настройки, которые могут быть изменены при первом запуске программы конечным пользователем.
- Позволяет .NET потенциально работать на другие системы без кода ОС. Это можно увидеть в Silverlight и изолированном хранилище.
- Повышенная безопасность за счет использования изолированного хранилища для приложения и пользователей.
- Предоставляет Microsoft возможность в будущем иметь ОС только с управляемым кодом без многих старых зависимостей. Подумайте о структуре как о слое между любой ОС и управляемым кодом.
Я думаю, что новый способ использования файла .config помогает следующим образом:
- Предоставление приложениям гибкости в предоставлении собственных конфигураций вместо конфигураций по умолчанию при условии - рассмотрим случай, когда web.config переопределяет machine.config
- Иногда бывает невозможно изменить параметры реестра, поскольку у вас может не быть необходимых прав. Таким образом, файл конфигурации позволяет вам вносить изменения, применимые к вашему собственному приложению, без дополнительных прав
- . С помощью записи в реестре несколько приложений потенциально могут использовать одну и ту же конфигурацию. Но если вы измените его для своего приложения, вы можете вызвать нежелательное поведение в других приложениях, и у вас может не быть полной информации об этом
Просто некоторые мысли, которые приходят в голову ...
HTH.
Я слышал довольно существенный слух о том, что формат хранения данных, используемый sharepoint и сервером Team Foundation, поддерживаемый SQL, изначально предназначался для замены файловой системы Windows в Windows 7. Если бы это был план, то окна получили бы / (когда-нибудь?) Получат хранилище транзакционных данных для хранения списков данных. Этот метод хранения данных, вероятно, во всех отношениях превосходит реестр.
Учитывая это, неудивительно, что Microsoft минимизирует использование реестра по мере продвижения инфраструктуры .net.
Я думаю, что одной из основных причин этого были обновления приложений. Когда вы устанавливаете обновление (то есть с помощью ClickOnce), новые настройки фактически переходят в новую папку. Когда вы его удаляете, новая папка удаляется, а старые настройки остаются. Если бы вместо этого использовался реестр, не было бы возможности выполнить такое «управление версиями».
Другие причины могут включать:
- Разрешения (настройки приложения всегда входят в AppData / LocalAppData, что не требует прав)
- Простота обслуживание / резервное копирование
- Переносимость (довольно сложно работать с реестром с помощью .NET Compact Framework, и бог вам помощи, если вы пытаетесь поддерживать Mono).
Это потому, что реестр - ужасный кошмар в использовании, и людям он не нравился. Он также не поддерживает развертывание xcopy. Используя XML-файлы для настройки, вы можете перемещать приложение с компьютера на компьютер без использования установщика. Это была одна из самых больших жалоб при написании кода в 90-х годах.
В реестре вы должны предоставить кому-либо разрешение на его изменение при установке приложения, что во многих организациях запрещено. Чтобы изменить настройку приложения, вы также должны знать, где искать в реестре, что в лучшем случае во многих случаях сложно. С помощью файла конфигурации он прямо здесь отделен от большинства других приложений. Обычно все необходимые настройки находятся прямо здесь, чтобы их можно было легко просмотреть и изменить.
Другая причина в том, что для редактирования реестра вам потребуется большее количество разрешений. Если вы просто редактируете файл конфигурации приложения, вам нужны только права на этот файл.
вместо простого использования реестра
Реестр НЕ простой . На моем ПК это двоичный беспорядок размером 40 МБ, и я надеюсь, что биты внутри него не передумают.
Разве не для этого был предназначен реестр?
Да. Но опять же, DLL были предназначены для предоставления общих функций различным приложениям.
- Реестр огромен, поэтому найти нужную информацию (даже при поиске) может быть затруднительно.
- При изменении реестра можно случайно повлиять на другие приложения.
- Если реестр поврежден, это может повлиять на все приложения (включая ОС).
- Вам нужны специальные инструменты для поиска, изменения и даже копирования реестра.
Я предпочитаю файлы конфигурации.
Переносимость приложения может быть одной из причин. Папки приложений можно скопировать с одного компьютера на другой, и настройки будут соответствовать приложению. Полезно при запуске приложений с флешек на нескольких компьютерах.
Одно непосредственное (но важное) преимущество:
С помощью простых файлов конфигурации пользователи могут легко восстановить свои настройки в случае переустановки / восстановления из резервной копии. Сделать это из значений реестра намного сложнее.
Я думаю, что существует огромная проблема безопасности, связанная с настройками приложения (файлы .config), поскольку их можно редактировать в любом текстовом редакторе и менять все.
Предположим, что строка подключения сохранена, и кто-то удалил или изменил все значения в файле конфигурации, тогда в приложении будет много proplem, поэтому файл конфигурации должен быть защищен.
или сохраните настройку, например, в файле DLL.
Одним из больших преимуществ перехода к файлам конфигурации над реестром является возможность параллельной установки одной и той же программы. В реестре центральная информация о конфигурации будет перекрываться для этих повторяющихся установок, но при использовании файлов конфигурации информация остается конфиденциальной для каждой конкретной установки. Верно, что переопределения конфигурации для конкретного пользователя могут потенциально перекрываться (поскольку они хранятся в папке данных приложения пользователя, а не в конкретном пути установки), но представьте сценарий, в котором разные пользователи используют разные установки, и в этом случае эта потенциальная проблема становится не имеющий отношения.
Мне кажется, что реестр один из тех вещей, которые «казались хорошей идеей в то время» - по множеству причин, уже перечисленных другими. Нет ничего плохого в том, чтобы понять, что в конце концов что-то было не такой уж хорошей идеей, и вместо этого использовать альтернативу, которая проще и удобнее, даже если в некоторых отношениях это может показаться шагом назад.
Рискну предположить, что решающим фактором была простота удаленного развертывания.
Я не думаю, что это вопрос независимости от платформы. Многие приложения были разработаны в прошлом для Linux, Mac и Windows, некоторые из них использовали файлы конфигурации, а другие - реестр.
Я думаю, что основная причина кроется в «опыте COM». Весь принцип заключался в том, чтобы объекты компонентов регистрировались централизованно в реестре, чтобы любое приложение могло использовать их без необходимости копировать dll. Это быстро привело нас к проблемам с версией. Несколько приложений вряд ли могли использовать разные версии одного и того же компонента.
С конфигурациями в реестре у вас та же проблема. Наличие двух версий одного и того же приложения может стать настоящей проблемой, если разработка не была выполнена правильно. У нас были проблемы такого рода при использовании нескольких версий Oracle давным-давно.
С .Net и стремительно увеличивающейся емкостью жестких дисков и полосой пропускания дублирование файлов больше не является проблемой. Копирование зависимостей в проект папки значительно упрощает развертывание приложения. То же самое касается файлов конфигурации. Вы можете разместить несколько копий / версий одного и того же приложения без проблем с ограниченной машинно-пользовательской архитектурой реестра.
Зависимость от реестра предотвращает развертывание XCOPY .