C# 从管理员配置文件在当前用户配置文件上创建文件夹和文件

我们的客户端只允许在以管理员身份登录时安装应用程序。必须为机器的当前用户安装需要安装的应用程序。应用程序安装得很好，当我需要在用户的appdata/user profile文件夹中放置配置文件时，问题就出现了。因为这是他们想要的，所以在安装时，配置文件将被删除到管理配置文件中。我如何克服这一点，是否有一种方法让我检查安装是否有其他配置文件，并可能写入它们，但这感觉很脏

不要在安装时创建配置文件，检查并查看它是否存在于程序运行时，如果不存在，则在running users profile文件夹中创建它。如果它确实存在，则使用其中的数据并继续。

您可以使用修复功能实现此功能。重要的是，该文件是在安装时为一个用户在用户配置文件位置安装的，并且在每系统安装中，这意味着当另一个用户登录使用该应用程序时，该文件将丢失。这取决于MSI组件、功能和快捷方式的结构，但使用公布的快捷方式启动应用程序可能会导致丢失的文件被自动修复安装。显然，这需要源MSI保持可用

但是，为任何新用户安装文件最安全的方法是显式调用并传递MSI的产品代码、功能名称、组件id等，如文档中所述。正如文档所说，如果组件丢失，这将安装该组件，再次要求源MSI可用

此功能用于处理用户帐户尚未创建的情况，因此显然您还不能将文件放入其配置文件文件夹中

与其他方法相比，这是否是最好的方法将取决于应用程序的具体细节

交叉引用：一个相关问题是，当您有一个常规用户无法写入的设置文件时。这是一个方法列表 为了消除这种情况：

---

我只想总结一下其他人基本上提到的内容，充实一些内容，试图做一个“小参考”

请看下面提到的Win10勒索软件保护功能，了解有关此Windows更改如何影响用户配置文件部署的重要信息

常用方法

• 有许多方法可以将文件部署到计算机上的每个用户，但大多数方法都有许多缺点和问题。老实说，所有的方法都有问题，不管是哪种形式

• 下面首先列出一些常见的部署方法，然后提到一些“基于云的方法”。在未来，这一讨论可能变得无关紧要，因为设置完全基于云，并且动态同步，部署可能完全从基于每台机器的部署切换到基于每用户的部署。我们将不得不等待，看看结果如何
  • 1：每台机器模板
    • 将配置文件安装到所有用户都可以读取的每台机器的位置，然后从那里复制文件，并在应用程序启动时将其放入用户配置文件中，使用应用程序本身为每个用户执行一次复制工作
    • 这是推荐的方法。如果需要使用以下方法，您甚至可以使用逻辑更新应用程序以强制每个用户更新：
    • 当复制发生时，您将始终在正确的用户上下文中运行，并且您不必担心复杂的MSI模拟、调节和排序复杂性
    • 这种方法的一个很好的优点是，即使在应用程序启动时缺少安装源（MSI），它也可以工作
  • 2：启动时创建文件-“内部默认值”
    • 正如gilliduck所建议的，只需在启动时使用应用程序的内部默认值创建配置文件，而根本不安装该文件。每个用户发生一次，从那时起，您将使用该文件。将此类文件保留在安装程序之外意味着您消除了安装程序意外覆盖或卸载该文件的风险
    • 一个明显的问题是，如果可以从内部默认值创建这样的文件，那么为什么需要这样的文件呢？答案显然是，您可能希望在创建文件后强制执行一些特定的值，这些值对于用户环境是唯一的。但是，像这样的设置也可以保存在注册表中
    • 您可以在安装过程中通过公共属性在注册表的HKLM部分中设置有问题的自定义设置（可由用户在命令行上或通过转换进行配置，请参阅：了解有关信息），并在应用程序启动时对所有用户强制执行这些设置-换句话说，将它们写入HKCU。或者您可以在HKLM中保持设置为“只读”，并在应用程序中对所有用户强制执行这些设置？（非用户可配置设置-例如网络服务器名称或类似设置）
    • 您仍然可以使用上面链接中的方法在应用程序启动时强制更新现有配置文件，方法是让安装程序向HKLM写入一个标志，以通知自上次启动以来已“发生”部署
    • 或者，如上所述，或者使用注册表来保存设置
  • 3:MSI自修复
    • 使用MSI self-repair将配置文件按用户放置到位。这发生在调用诸如用于启动应用程序的公告快捷方式之类的快捷方式时
    • 需要在修复时访问安装源。确保将MSI文件缓存在该框中
    • 自我修复可能无法在终端服务器（dis）上工作