26

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

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

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

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

4

17 回答 17

28

依赖注册表会阻止XCOPY 部署。

于 2010-04-08T13:32:32.257 回答
24

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

  • 创建时的注册表看起来是一个好主意，将所有程序的所有设置存储在一个地方，而不是以前通常使用的 .ini 文件。当时，由于从慢速硬盘读取小 .ini 文件的成本很高，因此提高了性能，单个注册表文件在一定程度上提高了性能。现在情况有所不同，因为硬盘驱动器的速度要快得多，并且越来越多的设置已转储到注册表中，从而成为系统的负担。如果您在 Windows 中安装和卸载大量程序，您会看到这一点，它开始变慢，最终您可能会重新格式化。
  • 即使在当前用户设置中，对注册表的错误写入也会破坏您的系统。
  • 注册表无法帮助 xcopy 部署没有特定代码来处理缺少注册表项的程序...这包括在许多情况下通过简单地删除文件夹来删除程序
  • 如果需要访问注册表，则安装应用程序可能需要更大的权限
  • .config 文件可以轻松地允许最终用户在第一次运行程序时修改默认应用程序和用户设置
  • 允许 .NET 潜在地在没有操作系统特定代码的其他系统上运行。这可以从 Silverlight 和独立存储中看出。
  • 通过为应用程序和用户使用隔离存储来提高安全性
  • 使 Microsoft 有可能在未来拥有一个只有托管代码的操作系统，而没有许多旧的依赖项。将框架视为任何操作系统和托管代码之间的一层。
于 2010-04-08T15:16:43.880 回答
15

另一个原因是，为了编辑注册表，您必须拥有更高的权限。如果您只是编辑应用程序配置文件，则只需要对该文件具有权限。

于 2010-04-08T13:29:06.587 回答
12
  • 注册表很大，因此查找相关信息（即使搜索）可能很麻烦。
  • 修改注册表时可能会不小心影响到其他应用程序。
  • 如果注册表损坏，所有应用程序都可能受到影响（包括操作系统）。
  • 您需要专用工具来搜索、修改甚至复制注册表。

我更喜欢配置文件。

于 2010-04-08T13:32:59.673 回答
7

这是因为注册表是一个丑陋的噩梦，人们不喜欢它。它也不支持 xcopy 部署。通过使用 xml 文件进行配置，您可以将应用程序从一台机器移动到另一台机器，而无需安装程序。这是 90 年代对编写代码的最大抱​​怨之一。

使用注册表，当您安装在许多组织中被禁止的应用程序时，您必须授予某人修改它的权限。要修改应用程序的设置，您还必须知道在注册表中查找的位置，这在许多情况下是最困难的。使用配置文件，它就与大多数其他应用程序隔离开来。通常，您需要的所有设置都在那里，便于查看和修改。

于 2010-04-08T13:33:21.683 回答
5

一个直接（但重要）的优势：

使用plain配置文件，用户可以在重新安装/从备份恢复的情况下轻松恢复他们的设置。从注册表值中执行此操作要困难得多。

于 2010-04-08T13:29:53.877 回答
3

通过注册表移动到配置文件的一大优势是允许并行安装同一程序。使用注册表，这些重复安装的中央配置信息将重叠，但使用配置文件，信息对每个特定安装保持私有。确实，特定于用户的配置覆盖可能会重叠（因为它们存储在用户的应用程序数据文件夹中，而不是特定于安装路径），但是想象一下不同用户使用不同安装的场景，在这种情况下，这个潜在的问题就变成了无关的。

于 2010-04-09T12:48:48.023 回答
2

我认为造成这种情况的主要原因之一是应用程序更新。当您安装更新（即使用 ClickOnce）时，新设置实际上会进入一个新文件夹。当您卸载它时，新文件夹将被删除，旧设置仍然存在。如果改为使用注册表，则无法执行此“版本控制”。

其他原因可能包括：

  • 权限（应用程序设置总是进入不需要权限的 AppData/LocalAppData）
  • 易于维护/备份
  • 可移植性（使用 .NET Compact Framework 处理注册表相当困难，如果您尝试支持 Mono，请上帝帮助您）。
于 2010-04-08T13:33:42.730 回答
2

在我看来，注册表是“当时似乎是个好主意”的那些东西之一——因为其他人已经列出了许多原因。意识到某事毕竟不是一个好主意并没有错，而是使用更简单、更方便的替代方案，即使在某些方面看起来像是倒退了一步。

于 2010-04-08T13:45:23.397 回答
1

我听到一个相当大的谣言，Sharepoint 和 Team Foundation Server 使用的数据存储格式，由 SQL 支持，最初是为了替换 windows 7 中的 windows 文件系统。如果这是计划，那么 windows 将获得 / (有朝一日会吗？）获得用于存储数据列表的事务性数据存储。这种数据存储方法可能在各方面都优于注册表。

鉴于此，微软在推进 .net 框架时尽量减少注册表的使用也就不足为奇了。

于 2010-04-08T13:42:37.823 回答
1

而不是简单地使用注册表

注册表并不简单。在我的 PC 上，这是一个 40MB 的二进制文件，我希望里面的内容不会改变他们的想法。

这不正是注册表的目的吗？

是的。但话又说回来，DLL旨在为不同的应用程序提供共享功能。

于 2010-04-08T14:38:59.663 回答
0

我认为 .config 文件的新方式有助于：

  • 让应用程序可以灵活地提供自己的配置作为对提供的默认配置的覆盖 - 考虑 web.config 覆盖 machine.config 的情况
  • 有时，可能无法更改注册表设置，因为您可能没有所需的权限。因此，配置文件允许您进行适用于您自己的应用程序的更改，而无需额外的权限
  • 使用注册表项，多个应用程序可能会使用相同的配置。但是，如果您为您的应用程序更改它，您可能会导致其他应用程序出现意外行为并且您可能没有关于此的完整信息

只是想到了一些想法......

HTH。

于 2010-04-08T13:32:55.283 回答
0

我敢猜测，远程部署的便利性是一个决定性因素。

于 2010-04-08T13:33:10.797 回答
0

应用程序的可移植性可能是原因之一。应用程序文件夹可以从一台计算机复制到另一台计算机，并且设置将与应用程序一起使用。在多台计算机上从 USB 闪存驱动器运行应用程序时很有用。

于 2010-04-08T13:52:29.283 回答
0

我不认为这是独立于平台的问题。过去在 Linux、Mac 和 Windows 上开发了许多应用程序，其中一些使用配置文件，而另一些使用注册表。

我认为主要原因来自“COM经验”。整个原则是在注册表中集中注册组件对象，以便任何应用程序都可以使用它而无需复制 dll。这很快导致我们遇到版本控制问题。多个应用程序很难使用同一组件的不同版本。

使用注册表中的配置，您会遇到同样的问题。如果开发不正确，拥有相同应用程序的两个版本可能会成为一个真正的问题。很久以前，我们在使用多个版本的 Oracle 时遇到过此类问题。

随着 .Net 以及硬盘驱动器和带宽的爆炸式增长，文件复制不再是一个问题。将依赖项复制到文件夹项目中可以大大简化应用程序部署。这同样适用于配置文件。您可以托管同一应用程序的多个副本/版本，而不会遇到注册表有限的机器/用户架构的问题。

于 2010-04-08T15:52:58.477 回答
0

微软建议两种方式，因为它们具有不同的功能。例如，如果您创建一些在 Active Directory 中使用的应用程序，您可以轻松修改数千台计算机的设置，甚至您的应用程序安装到不同的目录。如果您选择 xml，您应该知道每台 PC 的应用程序文件夹，或者创建一些智能脚本来查找它们。但正如许多人所说，xml 更好地用于可移植性、设置备份等。

所以，没有最好的办法。需要注册表的开发人员 - 直接使用它。这并不难。可能这就是微软没有在注册表中进行应用设置的原因。

于 2013-07-22T21:28:00.247 回答
-1

我认为应用程序设置（.config 文件）存在一个巨大的安全问题，即可以在任何文本编辑器中进行编辑并更改所有内容。

假设存储了一个connectionString，并且有人删除或更改了配置文件中的所有值，那么应用程序将有很多问题，因此应该保护配置文件。

或将设置存储在 DLL 文件中，例如。

于 2010-04-08T14:04:02.733 回答