我们的客户端只允许在以管理员身份登录时安装应用程序。必须为计算机的当前用户安装需要安装的应用程序。应用程序安装正常，当我需要在用户的appdata/用户配置文件文件夹中删除配置文件时，我的问题就出现了。由于这是他们想要的地方，因此当前配置在安装时被丢弃在管理员配置文件上。我如何解决这个问题，有没有办法让我检查安装是否有其他配置文件并可能写信给他们，但这感觉很脏。
交叉引用 ：一个相关的问题是，当您有一个普通用户无法写入的设置文件时。这是方法列表 用于消除该条件：System.UnauthorizedAccessException 在程序文件下运行.exe时。
- 将两个同名的互斥文件安装到同一目录
我只是总结一下其他人基本上提到的内容，稍微充实一下，试图做一个"小参考"。
也许看看下面提到的Win10 勒索软件保护功能，了解此 Windows 更改如何影响用户配置文件部署的重要花絮。
常见方法
有许多方法可以将文件部署到计算机上的每个用户，但大多数方法都存在许多缺点和问题。老实说，所有方法都存在问题，以一种或另一种形式。
下面首先列出了一些常见的部署方法，然后提到了一些"基于云的方法"。将来，此讨论可能会变得无关紧要，因为设置完全基于云并动态同步，并且部署可能完全从每台计算机切换到基于每个用户的部署。我们将不得不拭目以待，看看结果如何。
1：每台计算机模板
- 将配置文件安装到所有用户均可读取的每台计算机位置，然后从那里复制该文件，并在应用程序启动时使用应用程序本身将其放入用户配置文件中，以每个用户执行一次复制工作。
- 这是推荐的方法。如果需要使用以下方法，甚至可以使用逻辑更新应用程序，以强制按用户更新：http://forum.installsite.net/index.php?showtopic=21552。
- 复制发生时，你将始终在正确的用户上下文中运行，并且不必担心复杂的 MSI 模拟、条件反射和排序复杂性。
- 此方法的一个很好的优点是，即使在应用程序启动时缺少安装源 (MSI)，它也可以工作。
2：启动时创建文件 - "内部默认值">
- 正如 gilliduck 所建议的那样，只需在启动时使用应用程序的内部默认值创建配置文件，根本不安装该文件。每个用户发生一次，从那时起，您可以使用那里的文件。将此类文件保留在安装程序之外意味着您可以消除安装程序意外覆盖或卸载它的风险。
- 显而易见的问题是，如果您可以从内部默认值创建它，为什么您还需要这样的文件 - 如果您可以从内部默认值创建它？答案显然是，您可能希望在创建文件后强制实施一些对用户环境唯一的特定值。但是，像这样的设置也可以保存在注册表中吗？
- 您可以在安装期间通过 PUBLIC PROPERTIES 在注册表的 HKLM 部分中设置有问题的自定义设置(可由用户在命令行上或通过转换进行配置，请参阅：如何更好地利用 MSI 文件以获取相关信息)，并在应用程序启动时为所有用户强制执行这些设置——换句话说，将它们写入 HKCU。或者，您可以在 HKLM 中将设置保留为"只读"，并在您的应用程序中以这种方式为所有用户强制执行它们？(非用户可配置设置 - 例如网络服务器名称或类似名称)。
- 您仍然可以使用上述链接中的方法在应用程序启动时强制更新现有配置文件，方法是让您的设置向 HKLM 写入一个标志，以通知自上次启动以来部署已"发生"。
- 或者，如前所述，也可以改用注册表来保存设置。
- 如何读取嵌入的资源文本文件
3：微星自我修复
- 使用MSI 自我修复为每个用户放置配置文件。这发生在调用播发的入口点(如用于启动应用程序的播发快捷方式)时。
- 需要在修复时访问安装源。确保在包装盒上缓存您的 MSI 文件。
- 自我修复可能无法在终端服务器上工作(禁用功能)。自从我上次测试这个以来已经有好几年了。我不确定这些天服务器是如何开箱即用的配置的。
- 除非配置为不这样做，否则卸载可能会为运行实际卸载的用户卸载配置文件，或者至关重要的是，这可能会在主要升级期间发生(实际上是卸载并重新安装产品)。换句话说：将组件设置为永久(并且永不覆盖) - 否则您的文件可能会在升级过程中被覆盖(但它实际上是卸载并重新安装的)。
- 对于 HKCU 注册表设置，您不一定需要提供可用的安装源。查看斯特凡克鲁格的解释：http://www.msifaq.com/a/1011.htm。该过程与触发用户配置文件的安装相同(但随后需要安装源)。相关的讨论 - 以防有帮助。
- 虽然未经我测试，但我已考虑将注册表项路径值设置为：
HKCUSoftwareMyCompanyMyApplicationVersionHKCU_KeyPath = [ComputerName]以使键路径值成为"移动目标"，以便在用户登录到新计算机时可靠地触发自我修复(尽管漫游配置文件引入了现有的 HKCU 设置)。 - 正如我所说，未经测试，因为我几乎放弃了这种方法 - 因为它对 Windows 的每个新更新都不那么可靠。每次都会改变一些奇怪的东西，结果是不可预测的。
- 虽然不是 100% 相关，但我可以以Windows 10 中的新勒索软件保护功能为例 - 它似乎会导致任何尝试写入用户数据文件夹的 MSI 出现间歇性运行时错误。有多少部署问题会导致还有待观察 - 虽然到目前为止我们看到间歇性的结果 - 当他们默认打开该功能时会发生什么？
- 而且，与上述相同，第三方安全软件还通过阻止某些文件系统活动并隔离由于某种原因(包括误报)而被标记的文件来为部署提供障碍- 导致永远无法完成的自我修复，但继续徒劳无功。
- 请参阅此处有关自我修复和安全软件及恶意软件的问题 #7：如何避免使用我的 WiX/MSI 软件包触发 MSI 自我修复？
- 一般部署复杂性的摘要：程序安装的好处和真正目的是什么？以及底部：Windows安装程序和WiX的创建。
- 因此，作为简短的总结，以下是避免通过自我修复部署用户配置文件变得越来越有用的一些原因：
- 漫游配置文件并发症。
- 勒索软件防护功能干扰。
- 安全软件干扰(尤其是恶意软件误报)。
- 终端服务器对自我修复的限制。
- 主要升级期间的数据重置或设置卸载问题。
- 也许你会得到和我一样的感觉：还有更多，而且会继续变得更糟。
- 我的两分钱：立即与您的经理讨论如何为您的应用程序提供更好的数据文件管理，并放弃在部署期间"智能"的所有尝试。仅使用 MSI 部署每个计算机文件 - 如果可能。
- 将来，随着部署技术的变化，此首选项可能会发生变化，并且安装仅按用户完成(可能)。
- 前面写的对问题的较长描述：为什么在使用 MSI 时将文件部署限制为用户配置文件或 HKCU 是个好主意？
- 关于部署问题的整个混乱聊天：如何避免WiX/MSI部署解决方案中的常见设计缺陷？
4：活动设置(不再推荐，请阅读)- 使用活动安装程序将配置文件放置到位。这发生在用户登录时(然后需要注销和登录，除非您确保在安装时文件也安装到当前用户配置文件)。
- 这实际上是方法1的变体。应将配置文件安装到所有用户均可读取的每台计算机位置。
- 然后，在注册表中注册一个任务，以为每个用户运行一次"可运行的内容"。您可以运行任何内容，例如批处理文件、可执行文件、脚本或我的首选方法 MSI 修复，这些方法将设法将用户配置文件放置到位(在这种情况下，您不需要每台计算机位置中的文件，而是在活动安装程序运行时访问安装源)。
- 请注意不要覆盖在为当前用户安装期间放置的配置文件。或者，通过编写在为相关用户运行活动安装程序后写入的 HKCU 密钥，禁止为此用户运行活动安装程序(请参阅下面的链接)。
- 在我的回答中尝试了该过程：在Windows Server 2003上更新每个配置文件的注册表。这一切都基于每个用户运行一次的 HKLM 密钥。检查链接的答案以了解详细信息，其中有一些外部链接提供了更多详细信息。
- 更新：在终端服务器上安装时，将服务器置于"安装模式"，然后将每用户注册表项写入
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstall，然后在每个用户登录时写入每个用户的 HKCU 配置单元。这可能与ActiveSetup冲突 - 据我所知。我从来没有机会测试它。终端服务器的打包通常由专门的专业服务器团队完成。
5： MsiProvideComponent
- Phil的MsiProvideComponent很有趣，我从来没有用过它。我应该。
云样式的方法
随着数据存储似乎转移到云中，数据文件部署的常见方法可能很快就会过时。
6：下载设置文件
- 下载设置文件- 在应用程序启动时为每个用户下载一次 - 从本地网络数据库/共享或从Internet下载 - 如果这是一个选项。
- 管理员可以维护远程文件，以便在有新的默认值或需要删除某些内容时更新值。
- 应用程序理解的设置文件中的配置机制可以强制将新的"强制"值应用于所有用户。
- 是否允许在 HKLM 中配置服务器列表？可通过公共属性在 MSI 中配置？
- 或者在安装过程中在设置中设置单个 URL，并通过该 URL 维护服务器列表(您将这通过 DNS 重定向到哪个服务器，因此配置是一项系统管理任务，无需重新部署？目前选择集在香港CU。
7：远程数据库的读/写设置
- 直接从本地AD数据库或互联网连续读取/写入设置。
- 根本没有本地设置文件，或者无法访问服务器时的缓存只读副本？或者，如果无法访问服务器，则只是使用内部应用程序默认值运行？在后一种方法中根本没有要管理的文件。
- 您可以编写用于 HKLM 的服务器 (URL) 列表(甚至通过组策略？)，甚至可以在 HKCU 中为每个用户维护当前选定的服务器。然后其余的在线进行。
- 到目前为止，通常用于企业客户端/服务器应用程序 - 但基于云的平台将永远改变部署 - 特别是对于家庭用户。我们已经看到浏览器通过互联网保留设置很长时间了(Chrome，Opera，Firefox等)。
- 远程数据库存储意味着您可以将用户设置作为数据库管理任务进行维护，甚至可以对数据库中的用户数据进行版本控制，并轻松地强制实施新的默认值或强制更新所有用户用户的现有值作为集中式 DBO 任务。
- 不再有讨厌的漫游配置文件问题。
- 用户配置文件的部署不再失败。
- 总之：根本没有要部署的用户设置，并且数据永远不会在不同的计算机上不同步。
- 防火墙/代理和网络连接问题？
总结
我不再喜欢选项3(自我修复)和选项 4(主动设置)，尽管我已经多次使用它们 - 如果做得好，它们确实可以工作。但是，它们不能幸免于漫游配置文件问题(用户登录的所有系统上未就地复制文件)和在修复运行时无法访问 MSI 安装源 - 这可能会导致部署问题。在使用重置设置进行重大升级期间，也经常出现并发症，并且终端服务器上的自我修复失败。由于勒索软件保护或安全软件干扰，安装到用户配置文件的自我修复可能会失败。选项 4(活动设置)中指定的命令行可能有问题并清除数据(例如，您为 msiexec.exe 修复启用了错误的标志并意外强制覆盖设置文件 - 这通常不会被发现，直到为时已晚并且损坏已经完成)。现在还有其他问题逃脱了我。这两种方法都有相似但略有不同的局限性。
我越来越喜欢基于云的方法，使本地(和隔离)用户设置文件成为过去 - 但我很少能够以这种方式部署东西。这些云方法可能会面临防火墙/代理问题和网络连接问题- 可能还有其他一些我还不知道的事情(现在开发人员将与DBO而不是部署专家争吵，等等......;-))。分布式计算有其谬误：https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing。另外：在基于云的方法中，应用程序允许将设置备份到磁盘仍然是一个好主意，因此显然仍然需要一些文件管理 - 或者您只是导出几个数据库表？另外：如果您安装了应用程序的试用版，您可能希望它能够在没有网络连接的情况下运行 - 以防用户位于非常严格的防火墙后面。由于技术原因，不允许用户测试应用程序的功能是一个非常昂贵的错误。
选项 1 和 2的最大好处是，即使在触发修复时缺少原始安装介质，它们也可以工作。这对于家庭和小型办公室部署尤其重要，在这些部署中，如果没有集中的包共享，部署可能会相当随意地进行。您可以通过在安装过程中使用缓存方法在系统上缓存整个 MSI 来解决此问题(缺少源 MSI)(在 Installshield 中可用，我尚未检查 WiX 或高级安装程序)。
不要在安装时创建配置文件，检查并查看它是否存在于程序运行时，如果没有，则在运行的用户配置文件文件夹中创建它。如果它确实存在，则使用其中的数据并继续。
您可以使用修复功能进行此操作。大局是该文件是在用户配置文件位置安装时为一个用户安装的，而在按系统安装中，这意味着当其他用户登录以使用该应用程序时，该文件将丢失。这取决于 MSI 组件、功能和快捷方式的结构，但使用宣传的快捷方式启动应用程序可能会导致通过自我修复安装丢失的文件。显然，这需要源 MSI 保持可用。
但是，为任何新用户安装文件的最安全方法是显式调用 MsiProvideComponent，传递 MSI 的产品代码、功能名称、组件 ID 等，如文档中所述。正如文档所说，如果缺少组件，这将安装组件，再次要求源 MSI 可用。
此功能处理尚未创建的用户帐户的情况，因此显然您还不能将文件放入其配置文件文件夹中。
与其他方法相比，它是否是最佳方法将取决于应用程序的具体细节。