为什么是一个好主意，限制文件的部署，从我的MSI或安装文件中的用户配置文件或HKCU？

部署是最有发展的重要组成部分。请给这个内容的机会。这是我坚定地认为，软件质量可以通过在应用程序设计的微小变化得到显着改善，使部署更为合理，更可靠的-这就是这个“答案”的所有- 软件开发 。

这是一个答案，成为太长的Q / A-风格问题分裂：如何避免在我的WiX / MSI部署解决方案，共同设计缺陷？。

：如上所述， 这部分指出，从更广泛的范围已有答案分裂 如何避免在我的WiX / MSI部署解决方案，共同设计缺陷？ （旨在帮助开发一个答案做出更好的决策部署）。

9. 过度使用每用户文件和注册表的部署。

有些应用程序不会对计算机上的所有用户的正常运行，因为安装过程中添加特定于用户的数据不正确添加到其他用户的配置文件和注册表。换句话说，应用程序只适用于谁安装软件的用户。 这显然是一个严重的设计错误 。

有几种方法来“解决”这一点，但每个用户的文件和设置部署的整个问题是一些基本的原因有些凌乱 ：

你如何引用计数组件多次安装？（用于机器上的每个用户）
你怎么与卸载已安装的数据和设置吗？
你如何应对新的文件和设置安装从在磁盘上，并在注册表中的那些不同，具有用户所做的更改？当然，你不会自动覆盖？

有没有真正明确的答案，但有几个可选的方式来处理“问题”。我的首选方案是2和3，因为我不认为Windows安装应该部署，跟踪或试图在所有修改或更糟糕的是，卸载用户数据和设置 - 这是不应受到插手用户数据：

9.1使用Windows安装程序自维修或类似

第一个选项是让通过设置本身或建立样特征正确部署设置，文件和HKCU注册表项。主要有两种方法可以做到这一点：依靠Windows安装程序“ 自我修复 ”一般由一个广告使用快捷键触发，或者微软智能安装 。

自我修复是当你推出一个快捷方式来启动应用程序会发生什么，和Windows安装程序踢，你会看到一个进度条，而“东西”正在安装。什么是典型的加入是HKCU注册表项和用户配置文件的文件。
还有另一种选择，以实现这一目标，它被称为主动设置，也是微软的特征。它本质上注册“的东西可运行”，以每用户登录时运行一次。这可以被用于设置每个用户的数据。活动设置允许“任何可运行的”执行对象-比如文件的副本给用户配置文件。。
这两个选项意味着用户数据和设置的地方被复制一次 - 从此之后，他们通常不是感动，而是在“自我修复”的情况下可能会卸载了谁实际运行的卸载任何用户应用程序（除非设置被设计为不这样做）。
虽然设置了自我修复和活动设置用户数据“建立”的方法来获取正常运行的应用程序，它似乎是错误的跟踪与Windows Installer组件的用户数据。为什么？因为它实在是不应该与初始化一次来插手用户数据。
因此我真诚的采取对整个问题是要尽量避免完全部署用户特定的数据或注册表键和值 ，这就是接下来描述为两个其它用户数据部署方法。

用户数据的 9.2 应用程序初始化

我觉得更清洁的第二个选择，和一，是改变你的应用程序可执行文件，以便能够基于从每台机器位置复制或基于应用程序内部默认默认设置和模板初始化所有每用户设置和文件（从源代码），而不是通过您设置写他们。

在这种情况下Windows安装程序将无法跟踪复制到每个用户的文件或设置。它被视为不应该用在所有干扰用户数据。 这避免了升级和自我修复（和手动卸载并重新安装）在所有的干扰，如复位或覆盖用户数据 。
如果有其中“修复”必须对应用程序设置进行的情况下，这可以通过应用程序的可执行更新在启动每个用户的设置，然后标记该更新已经完成注册表来实现。
总的“结论”是你的设置应该准备您的第一个启动应用程序 ，它不应该建立用户数据和设置环境。所有用户的个人资料文件和HKCU设置应该由他们缺少在启动情况下，应用程序默认 - 这将产生更强大的应用程序更易于测试的QA人员也是如此。这对于自我修复不允许运行在所有终端服务器尤为重要。在这种情况下，如果你靠自我修复把用户数据，应用程序数据将会丢失。

9.3“云”或用户设置的数据库存储

拿东西进了一步在今天的“云环境” - 这是在我看来，更好的选择 。为什么你的应用仅限于文件和注册表项和值？为什么不存储在解决方案数据库中的所有用户特定的设置？

完全访问，控制和持久性，而完全不任何部署问题的所有设置。
你得到新的管理问题，虽然，他们必须开发人员，系统管理员和数据库管理员之间共享。但实际情况并非云相当多的行业标准现在？
我们一直在努力足够长，漫游配置文件，已损坏的用户注册表，处理不当的用户配置文件数据文件，等等 。开发商，为自己省下不少麻烦，而自己创建了一些新的数据库管理问题，而不是部署问题 - 并开始在一个全新的一堆人喊了！ :-)。
在数据库中设置有：
- 不是从“双源问题”的痛苦。有一个实例，它是实时更新。不喜欢与用户配置文件和“漫游”看到的同步问题。
- 可检查，可管理，可跳接
- 可修改（版本控制 - 可以恢复旧的设置）
还是通过运行数据库脚本作为部署的一部分，你甚至可以“调整”从你的设置中的所有用户设置，但如果你是在企业环境中 - 不只是提高了票的想法，然后让数据库管理员运行维护脚本适当事务支持和回滚更吸引人？
即使你提供了总经销和第三方使用大，胖客户端厂商的应用程序（换句话说，不是你都保证有一个后端数据库量身定制，企业客户端/服务器解决方案），应该考虑云存储通过具有用户登录到使用电子邮件或类似的云，然后用户设置同步实时设置。
- 这样的大型应用程序通常总是需要在计算机上，并在HKCU为“高速缓存”的一些设置文件，但似乎越来越有可能保存在用户配置文件区域内的单个临时文件，该文件是完全“牺牲”，甚至可能所有设置删除，如果它被破坏，然后下载上次保存的设置。
- 相反，自己托管的云，它显然是可以使用公司DBOS配置自己的公司范围内的云计算，他们拥有的所有设置完全控制，并且还可以强制执行软件操作的强制性政策和限制。且不说正确的备份也可以让用户设置。