为什么.NET“应用程序设置”不存储在注册表中？

Question

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

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

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

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

Answer 1

依赖注册表会阻止XCOPY Deployment。

Answer 2

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

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

Answer 3

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

Answer 4

• 注册表很庞大，因此找到相关信息（即使搜索）也很麻烦。
• 修改注册表时，可能会意外影响其他应用程序。
• 如果注册表已损坏，则所有应用程序可能都会受到影响（包括操作系统）。
• 您需要使用专用工具来搜索，修改甚至复制注册表。

我更喜欢配置文件。

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

其他原因可能包括：

• 权限（应用程序设置始终进入AppData / LocalAppData，不需要任何权限）
• 易于维护/备份
• 可移植性（使用.NET Compact Framework处理注册表相当困难，如果您尝试支持Mono，上帝会帮助您。）

Answer 9

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

Answer 10

我听到一个相当实质性的传闻，即由share支持的sharepoint和团队基金会服务器使用的数据存储格式最初是为了取代Windows 7中的Windows文件系统。如果这是计划，那么windows会有获得/（有一天会？）获得一个用于存储数据列表的事务数据存储。这种数据存储方法可能在各方面都优于注册表。

鉴于此，看到Microsoft在使用.net框架时最小化注册表的使用并不令人惊讶。

Answer 11

  

而不是简单地使用注册表

注册表不是简单。在我的电脑上，这是一个40MB的二进制混乱，我希望它里面的内容不会改变主意。

  

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

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

Answer 12

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

Answer 13

我猜想远程部署的简易性是一个决定因素。

Answer 14

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

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

使用注册表中的配置，您会遇到同样的问题。如果开发没有正确完成，那么拥有相同应用程序的两个版本可能是一个真正的问题。很久以前我们使用多个版本的Oracle就遇到过这种问题。

凭借.Net以及硬盘和带宽的爆炸式容量，文件复制不再是一个问题。将依赖项复制到文件夹项目中可以大大简化应用程序部署。这同样适用于配置文件。您可以托管同一应用程序的多个副本/版本，而不会出现注册表有限的计算机/用户体系结构的问题。

Answer 15

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

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

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

HTH。

Answer 16

Microsoft提出了两种方法，因为它们具有不同的功能。 例如，如果您创建了一些在Active Directory中使用的应用程序，则可以轻松修改数千台计算机的设置，甚至可以修改安装到不同目录的应用程序。如果选择xml，您应该知道每台PC的应用程序文件夹，或者创建一些智能脚本来查找它们。 但是很多人说xml更便于携带，设置备份和其他。

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

Answer 17

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

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

例如，

或以DLL文件存储设置。