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

Ответ 1

Я не думаю, что это один ответ. Я думаю, что это комбинация:

• Реестр на момент его создания выглядел как хорошая идея сохранить все настройки для всех программ в одном месте, как и против .ini файлов, которые обычно используются ранее. В то время эта повышенная производительность, так как маленький файл .ini с медленных жестких дисков был дорогостоящим, один файл реестра несколько повышал производительность. В настоящее время это отличается от того, что жесткие диски намного быстрее и все больше и больше настроек были сброшены в реестр, что обусловливает нагрузку на систему. Вы увидите это, если вы установите и удалите большое количество программ в окнах, которые он начнет замедляться, и в конечном итоге вы, вероятно, закончите переформатирование.
• Неправильная запись в реестр даже в текущих настройках пользователя может испортить вашу систему.
• Реестр не помогает xcopy развертывать программы без специального кода для устранения недостающих ключей реестра... Это включает удаление программ, просто удалив папку во многих случаях.
• Большие разрешения могут потребоваться для установки приложения, если ему нужен доступ к реестру.
• Файл .config легко позволяет использовать по умолчанию приложение и пользовательские настройки, которые могут быть изменены при первом запуске программы конечным пользователем
• Позволяет .NET потенциально запускаться на других системах без кода ОС. Это можно увидеть в Silverlight и изолированном хранилище.
• Большая безопасность благодаря использованию изолированного хранилища для приложения и пользователей
• Предоставляет Microsoft возможность в будущем иметь управляемую кодовую ОС без многих старых зависимостей. Подумайте о структуре как слое между любой ОС и управляемым кодом.

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

вместо простого использования реестра

Реестр НЕ прост. На моем ПК это двоичный беспорядок на 40 Мбайт, и я надеюсь, что в нем не изменится бит.

Разве это не то, для чего предназначен реестр?

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

Ответ 12

Я думаю, что новый способ файла .config помогает:

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

Только некоторые мысли, которые приходят на ум...

НТН.

Ответ 13

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

Ответ 14

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

Ответ 15

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

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

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

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

Ответ 16

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

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

Ответ 17

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

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

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