.net - 为什么 .NET "application settings"没有存储在注册表中？

Question

早在九十年代的某个时候，微软就推出了 Windows 注册表。应用程序可以将设置存储在不同的配置单元中。有用于应用程序范围和用户特定范围的配置单元，它们被放置在适当的位置，以便漫游配置文件正常工作。

在 .NET 2.0 及更高版本中，我们有一个名为 Application Settings 的东西.应用程序可以使用它们将设置存储在 XML 文件 app.exe.config 和 user.config 中。这些适用于应用程序范围和用户特定范围，它们放置在适当的位置，以便漫游配置文件正常工作。

听起来有点熟？这些应用程序设置由 XML 文件支持，而不是简单地使用注册表的原因是什么？这不正是注册表的目的吗？

我能想到的唯一原因是注册表是特定于 Windows 的，而 .NET 试图独立于平台。这是一个(或那个)原因，还是我忽略了其他考虑因素？

Answer 1

我不认为这是一个答案，我认为这是一个组合:

创建时的注册表看起来是一个好主意，将所有程序的所有设置存储在一个地方，而不是以前通常使用的 .ini 文件。当时，由于从慢速硬盘驱动器读取小的 .ini 文件成本很高，因此提高了性能，单个注册表文件在某种程度上提高了性能。现在情况有所不同，因为硬盘驱动器的速度要快得多，而且越来越多的设置已被转储到注册表中，从而成为系统的负担。如果您在 Windows 中安装和卸载大量程序，您会看到这一点，它开始变慢，最终您可能会重新格式化。

即使在当前用户设置中对注册表的错误写入也会破坏您的系统。

注册表不能帮助 xcopy 部署没有特定代码来处理缺少注册表项的程序...这包括在许多情况下通过简单地删除文件夹来删除程序

如果应用程序需要访问注册表

安装应用程序可能需要更大的权限

.config 文件很容易允许 默认 最终用户可以在第一次运行程序时修改应用程序和用户设置

允许 .NET 潜在地在没有操作系统特定代码的其他系统上运行。这可以从 Silverlight 和独立存储中看出。

通过为应用程序和用户使用隔离存储来提高安全性

为 Microsoft 提供了一种可能的方式，即在 future 拥有一个没有许多旧依赖项的仅托管代码的操作系统。将框架视为任何操作系统和托管代码之间的层。