为什么将文件部署到我的 MSI 或安装文件的用户配置文件或 HKCU 是个好主意？
部署是大多数开发的关键部分。请给这个内容一个机会。我坚信，通过对应用程序设计进行微小的更改，可以使部署更合乎逻辑和更可靠，从而使部署更合乎逻辑和更可靠，从而大大提高软件质量 -这就是这个"答案"的全部内容 - 软件开发。
这是一个问答式问题，由一个太长的答案分开：如何避免WiX/MSI部署解决方案中的常见设计缺陷？
如上所述，本节从现有答案中分离出来，范围更广：如何避免WiX/MSI部署解决方案中的常见设计缺陷？(旨在帮助开发人员做出更好的部署决策的答案)。
9.过度使用每用户文件和注册表部署。
某些应用程序无法为计算机上的所有用户正常运行，因为在安装期间添加的用户特定数据未正确添加到其他用户的配置文件和注册表中。换句话说，该应用程序仅适用于安装该软件的用户。这显然是一个严重的设计错误。
有几种方法可以"修复"此问题，但是由于一些基本原因，部署每用户文件和设置的整个问题有些混乱：
- 如何引用多次安装的组件计数？(对于计算机上的每个用户)
- 卸载时如何处理已安装的数据和设置？ 如何处理要安装的新文件和设置，这些文件和设置
- 与磁盘和注册表中的文件和设置不同，并且具有用户所做的更改？你肯定不会自动覆盖吗？
没有真正明确的答案，但有几种替代方法可以处理"问题"。我的首选选项是 2 和 3，因为我认为 Windows 安装程序不应该部署、跟踪或尝试修改或更糟的是，根本不卸载用户数据和设置 - 用户数据不应该涉：
9.1 使用 Windows 安装程序自我修复或类似程序
第一个选项是通过安装程序本身或类似安装程序的功能正确部署设置和文件以及 HKCU 注册表项。有两种主要方法可以做到这一点：依靠通常由通告的快捷方式触发的Windows安装程序">自我修复"，或使用Microsoft活动安装程序。
自我修复是当您启动快捷方式以启动应用程序时发生的情况，Windows 安装程序启动，并且在安装"某些内容"时会看到一个进度条。通常添加的是 HKCU 注册表项和用户配置文件。
还有另一种选择可以实现这一点，它被称为活动设置，也是Microsoft功能。它本质上注册了"可运行的东西"，以便在登录时为每个用户运行一次。这可用于设置每用户数据。活动设置允许执行"任何可运行的内容" - 例如，将文件复制到用户配置文件。.
这两个选项都意味着用户数据和设置被复制到原地一次 - 从那时起，它们通常不会被触及，但在"自我修复"的情况下，对于实际运行应用程序卸载的任何用户，可能会被卸载(除非安装程序设计为不这样做)。
尽管使用自我修复和活动设置设置用户数据是使应用程序正常运行的"既定"方法，但使用 Windows 安装程序组件跟踪用户数据似乎是错误的。为什么？因为它实际上是用户数据，一旦初始化就不应该预。
因此，我对整个问题的诚实看法是尽量避免完全部署用户特定的数据或注册表项和值，这就是接下来描述的另外两种用户数据部署方法。
9.2用户数据的应用程序初始化
第二种选择，也是我发现更干净的一种选择，是更改应用程序可执行文件，以便能够根据默认设置和从每台计算机位置复制的模板或基于应用程序内部默认值(从源代码)初始化所有每用户设置和文件，而不是通过设置编写它们。
在这种情况下，Windows 安装程序不会跟踪复制到每个用户的文件或设置。它被视为根本不应受到干扰的用户数据。这避免了所有干扰，例如在升级和自我修复(以及手动卸载和重新安装)期间重置或覆盖用户数据。
如果存在必须对应用程序设置进行"修复"的情况，则可以通过让应用程序可执行文件在启动时更新每个用户的设置，然后标记更新已完成的注册表来实现。
总体"结论"是，您的设置应该为首次启动准备应用程序，它不应该设置用户数据和设置环境。所有用户配置文件和 HKCU 设置都应由应用程序默认，以防它们在启动时丢失 - 这会产生一个更强大的应用程序，也更容易对 QA 人员进行测试。这对于根本不允许运行自我修复的终端服务器尤其重要。在这种情况下，如果依靠自我修复来放置用户数据，则应用程序数据将丢失。
9.3用户设置的"云"或数据库存储
在当今的"云环境"中更进一步 -在我看来，这是首选。为什么应用程序应限制为文件、注册表项和值？为什么不在解决方案的数据库中存储所有用户特定的设置？
对所有设置的完全访问、控制和持久性，完全没有任何部署问题。
但是，您确实会遇到新的管理问题，这些问题必须在开发人员，系统管理员和数据库管理员之间共享。但是，云现在不是行业标准吗？
我们已经在漫游配置文件，损坏的用户注册表，处理不当的用户配置文件数据文件等方面苦苦挣扎了足够长的时间......。开发人员，为自己省去很多麻烦，并为自己创建一些新的数据库管理问题而不是部署问题 - 并开始对一群全新的人大喊大叫！:-).
数据库中的设置包括：
没有遭受"双源问题"的困扰。有一个实例，它是实时更新的。不像用户配置文件和"漫游"看到的同步问题。
可检查、可管理和可修补
可修订(版本控制 - 可以还原旧设置)
您甚至可以通过在部署过程中运行数据库脚本来"调整"设置中的所有用户设置，但是如果您在企业环境中 - 只是提出票证然后让您的数据库管理员运行维护脚本的想法不是更有吸引力吗事务支持和回滚？
即使您正在交付一个大型的胖客户端供应商应用程序供一般分发和第三方使用(换句话说，不是定制的企业客户端/服务器解决方案，可以保证您拥有后端数据库)，也应该考虑用户设置的云存储，让用户使用他们的电子邮件或类似工具登录到云，然后实时同步设置。
这样的大型应用程序通常总是需要在计算机和HKCU中"缓存"一些设置文件，但似乎越来越有可能将所有设置保存在用户配置文件区域中的单个临时文件中，这完全是"牺牲"的，甚至可以删除如果它被损坏，然后下载最后保存的设置。
显然，可以使用公司 DBO 来配置自己的公司范围的云，而不是自己托管云，他们可以完全控制所有设置，还可以对软件的操作实施强制性策略和限制。更不用说所有用户设置都可以进行的正确备份。