交叉引用:一个相关的问题是当您有一个普通用户无法写入的设置文件时.这是一个方法列表消除这种情况:System.UnauthorizedAccessException在程序文件下运行 .exe 时.

• 将两个互斥的同名文件安装到同一个目录

我将仅总结其他人基本上提到的内容，并稍微充实一些内容，以提供一点参考".

I will just summarize what others have basically mentioned, fleshing things out a bit trying to make a "little reference".

也许可以看看下面提到的 Win10 勒索软件保护功能，了解有关此 Windows 更改如何影响用户配置文件部署的重要花絮.

Maybe have a look at the mentioning of the Win10 ransomware protection feature below for an important tidbit on how this Windows change can affect deployment of user-profile files.

• 有很多方法可以将文件部署到计算机上的每个用户，但大多数方法都存在许多缺点和问题.老实说，所有方法都存在问题，以一种或另一种形式存在.

• There are many ways to get files deployed to each user on a computer, but there are many drawbacks and problems with most of the approaches. In all honesty there are problems with all approaches, in one form or another.

下面首先列出了一些常见的部署方法，然后提到了一些基于云的方法".在未来，这个讨论可能会变得无关紧要，因为设置完全基于云并且是动态同步的，并且部署可能会完全从基于机器的部署切换到基于用户的部署.我们将不得不等待，看看结果如何.

Below is a list of some common deployment approaches first, and then a mention of some "cloud-based approaches". In the future this discussion may become irrelevant as settings are entirely cloud based and synced on the fly and deployment may switch entirely from per-machine to per-user based deployment. We will have to wait and see how it turns out.

• 1:每台机器模板

  • 将配置文件安装到所有用户都可读的每台机器位置，然后从那里复制文件并将其放入上的用户配置文件应用程序启动使用应用程序本身为每个用户执行一次复制工作.
  • 这是推荐的方法.如果您需要使用这样的方法，您甚至可以使用逻辑更新您的应用程序以强制每个用户更新:http://forum.installsite.net/index.php?showtopic=21552.
  • 当复制发生时，您将始终在正确的用户上下文中运行，您不必担心复杂的 MSI 模拟、调节和排序的复杂性.
  • 这种方法的一个很好的优点是，即使在应用程序启动时缺少安装源 (MSI)，它也能正常工作.

  • 1: Per-Machine Template

    • Install the config file to a per-machine location that is readable for all users, then copy the file from there and put it into the userprofile on application launch using the application itself to do the copy-work once per user.
    • This is the recommended approach. You can even update your application with logic to enforce updates per-user if you need to using an approach like this: http://forum.installsite.net/index.php?showtopic=21552.
    • You will always be running in the right user context when the copy is happening, and you don't have to worry about complex MSI impersonation, conditioning and sequencing complexities.
    • A nice advantage of this approach is that it will work even if the installation source (MSI) is missing at the time of the application launch.
    • 正如 gilliduck 所建议的那样，只需使用应用程序的内部默认值在启动时创建配置文件，根本不安装该文件.每个用户发生一次，从那时起您将使用那里的文件.将此类文件排除在安装程序之外意味着您可以消除安装程序意外覆盖或卸载它的风险.
    • 显而易见的问题是为什么您需要这样一个文件 - 如果您可以从内部默认值创建它?答案很明显，您可能希望在创建文件后强制执行一些对于用户环境唯一的特定值.但是，这些设置也可以保存在注册表中吗?
    • 您可以在安装期间通过 PUBLIC PROPERTIES 在注册表的 HKLM 部分中设置有问题的自定义设置(可由用户在命令行上或通过转换进行配置，请参阅:如何更好地使用 MSI 文件 以获取有关这方面的信息)，并对所有人强制执行应用程序启动时的用户 - 换句话说，将它们写入 HKCU.或者您可以将 HKLM 中的设置保持为只读"，并在您的应用程序中以这种方式为所有用户强制执行这些设置?(非用户可配置的设置 - 例如网络服务器名称或类似名称).
    • 您仍然可以使用上面链接中的方法在应用程序启动时强制更新现有配置文件，方法是让您的设置向 HKLM 写入一个标志，以通知自上次启动以来部署已发生".
    • 或者，如上所述，使用注册表来保存设置.
    • 如何读取嵌入的资源文本文件
    • As gilliduck suggests, simply create the config file on launch using the application's internal defaults and don't install the file at all. Happens once per user, from then on you use the file that is there. Keeping such a file out of your installer means you eliminate the risk that the installer accidentally overwrites it or uninstalls it.
    • The obvious question is why you would need such a file at all - if you can create it from internal defaults? The answer is obviously that you may want to enforce some specific values that are unique for the user's environment once the file is created. However, settings like these could just as well be saved in the registry?
    • You could set the custom settings in question in the HKLM section of the registry via PUBLIC PROPERTIES during installation (configurable by the user on the command line or via a transform, see: How to make better use of MSI files for information on this), and enforce them for all users on application launch - in other words write them to HKCU. Or you could just keep the settings "read-only" in HKLM and enforce them for all users that way in your application? (non-user configurable settings - such as a network server name or similar).
    • You can still use the method from the link above to enforce updates to existing config files on application launch by having your setup write a flag to HKLM to notify that a deployment has "happened" since last launch.
    • Or, as stated, alternatively use the registry to hold settings instead.
    • How to read embedded resource text file
    • 使用 MSI 自我修复，按用户放置配置文件.这发生在调用 广告入口点 例如用于启动应用程序的广告快捷方式.
    • 需要在修复发生时访问安装源.确保将您的 MSI 文件缓存在盒子上.
    • 自我修复可能不适用于终端服务器(禁用功能).我上次测试这个已经有好几年了.我不确定这些天服务器是如何配置的.
    • 除非配置为不这样做，否则卸载可能会为运行实际卸载的用户卸载配置文件，或者更严重的是，这可能发生在重大升级(实际上是卸载并重新安装您的产品)期间.换句话说:将组件设置为永久(并且永远不会覆盖) - 否则您的文件可能会在升级过程中被覆盖(但实际上已卸载并重新安装).
    • 对于 HKCU 注册表设置，您不一定需要安装源可用.检查 Stefan Kruger 的 解释:http://www.msifaq.com/a/1011.htm.触发用户配置文件安装的过程相同(但需要安装源).相关讨论 - 如果有帮助.莉>
    • 虽然未经我测试，但我已考虑将注册表项路径值设置为:HKCUSoftwareMyCompanyMyApplicationVersionHKCU_KeyPath = [ComputerName] 以使键路径值成为移动目标"，以便在用户登录新计算机时可靠地触发自我修复(尽管漫游配置文件引入了现有的 HKCU 设置).
    • 正如我所说，未经测试，因为我几乎已经放弃了这种方法 - 因为 Windows 的每次新更新都不太可靠.每次都会发生一些奇怪的变化，结果出乎意料.
    • 虽然不是 100% 相关，但我可以举个例子，提到新的 Windows 10 中的勒索软件保护功能 - 它似乎会导致任何 MSI 尝试间歇性运行时错误写入用户数据文件夹.将导致多少部署问题仍有待观察 - 虽然到目前为止我们看到的是间歇性的结果 - 如果默认情况下启用该功能会发生什么情况?
    • 并且，与上述相同，第三方安全软件还通过阻止某些文件系统活动和隔离出于某种原因标记的文件来提供部署障碍(包括误报) - 导致无法完成的自我修复，但继续白费力气.
      • 在此处查看问题 #7，了解自我修复和安全软件和恶意软件:如何避免使用 WiX 触发 MSI 自我修复/MSI 包?
      • 部署复杂性的总体总结:安装程序的好处和真正目的是什么? 和底部:Windows Installer 和 WiX 的创建.
      • Put the config file in place per user using MSI self-repair. This happens on invoking an advertised entry point such as an advertised shortcut used to launch the application.
      • Requires access to the installation source at the time the repair happens. Make sure to cache your MSI file on the box.
      • Self-repair may not work on Terminal Servers (disabled feature). It has been years since I last tested this. I am not sure how servers are configured out of the box these days.
      • Unless configured not to, the uninstall may uninstall the config file for the user who runs the actual uninstall or, critically, this may happen during a major upgrade (which is really an uninstall and reinstall of your product). In other words: set the component permanent (and never overwrite) - or your file may appear overwritten during the upgrade (but it is really uninstalled and reinstalled).
      • For HKCU registry settings you don't necessarily need to have the installation source available. Check Stefan Kruger's explanation: http://www.msifaq.com/a/1011.htm. The procedure is the same to trigger installation of userprofile files (but then the installation source is needed). An associated discussion - in case it is helpful.
      • Though untested by me, I have considered setting a registry key path value to: HKCUSoftwareMyCompanyMyApplicationVersionHKCU_KeyPath = [ComputerName] in order to make the key path value a "moving target" so that self-repair is triggered reliably when the user logs into a new computer (despite roaming profiles bringing in existing HKCU settings).
      • As I said, untested since I have pretty much abandoned this approach - since it is less reliable to depend upon for every new update to Windows. Something strange is changed every time, with unpredictable results.
      • Though not 100% related, I can mention the new ransomware protection feature in Windows 10 as an example - it seems to cause intermittent runtime errors for any MSI trying to write to user data folders. It remains to be seen how many deployment problems will result - while we see intermittent results so far - what will happen when and if they turn on the feature by default?.
      • And, along the same lines as above, third party security software also provide obstacles to deployment by blocking certain file system activity and quarantining files that are flagged for some reason (including false positives) - causing self-repair that can never complete, but keep running in vain.
        • See issue #7 here on self-repair and security software and malware: How do I avoid triggering MSI self-repair with my WiX / MSI package?
        • A summary of deployment complexity in general: What is the benefit and real purpose of program installation? and towards the bottom here: Windows Installer and the creation of WiX.
        • 漫游配置文件并发症.
        • 勒索软件保护功能干扰.
        • 安全软件干扰(尤其是恶意软件误报).
        • 终端服务器对自我修复的限制.
        • 重大升级期间的数据重置或设置卸载问题.
        • 也许你和我有同样的感觉:还有更多，而且情况会越来越糟.
        • 我的两分钱:立即与您的经理讨论如何更好地管理您的应用程序的数据文件，并在部署期间放弃所有智能"尝试.仅使用 MSI 部署每个机器文件 - 如果可能.
        • 将来，随着部署技术的变化和安装(可能)仅针对每个用户完成，此偏好可能会发生变化.
        • 之前写的问题的详细描述:为什么在使用 MSI 时将文件部署限制到用户配置文件或 HKCU 是个好主意?
        • 还有一个关于一般部署问题的混乱讨论:如何避免 WiX/MSI 部署解决方案中的常见设计缺陷?
        • Roaming profile complications.
        • Ransomware protection feature interference.
        • Security software interference (particularly false malware positives).
        • Terminal server restrictions on self-repair.
        • Data reset or settings uninstall issues during major upgrade.
        • Maybe you get the same feeling I get: there is more, and it will continue to get worse.
        • My two cents: talk to your manager immediately about better data file management for your application and abandon all attempts to be "smart" during deployment. Deploy per machine file only with MSI - if possible.
        • In the future this preference may likely change as deployment technology changes and installs are done per user only (maybe).
        • A longer description of the problem written earlier: Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?
        • And a whole messy chat about deployment problems in general: How do I avoid common design flaws in my WiX / MSI deployment solution?
        • 使用 Active Setup 将配置文件放置到位.这会在用户登录时发生(然后需要注销并登录，除非您确保该文件在安装时也安装到当前用户配置文件中).
        • 这实际上是方法 1 的变体.您应该将配置文件安装到每台机器的位置，供所有用户读取.
        • 然后您在注册表中注册一个任务，为每个用户运行一次可运行的东西".您可以运行任何东西，例如批处理文件、可执行文件、脚本或我首选的 MSI 修复方法，这些方法将设法将用户配置文件放置到位(在这种情况下，您不需要在每台机器位置的文件，但需要访问在 Active Setup 运行时添加到安装源).
        • 注意不要覆盖当前用户在安装过程中放置​​的配置文件.或者，通过写入在为相关用户运行 Active Setup 后写入的 HKCU 密钥，禁用 Active Setup 为该用户运行(请参阅下面的链接).
        • 尝试在我的回答中解释该过程:在 Windows Server 2003 上更新每个配置文件的注册表.它全部基于每个用户运行一次的 HKLM 密钥.查看链接的答案以了解详细信息，其中有一些外部链接提供了更多详细信息.
        • 更新:在终端服务器上安装时，您将服务器置于安装模式"，然后将每个用户的注册表项写入 HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstall 然后在他们登录时写入每个用户的 HKCU 配置单元.这可能与 ActiveSetup 冲突 - 据我所知.我从来没有机会测试它.终端服务器的打包工作通常由专门的专业服务器团队完成.
        • Put the config file in place using Active Setup. This happens on user login (which then requires a logout and login to happen unless you ensure the file is also installed to the current user profile on install).
        • This is in effect a variation of approach 1. You should install the config file to a per-machine location, readable by all user.
        • Then you register a task in the registry to run "something runnable" once per user. You can run anything such as a batch file, executable, script, or my preferred approach MSI repair that will manage to put the userprofile file in place (in this case you don't need a file in a per-machine location, but access to the installation source as Active Setup runs).
        • Beware not to overwrite a config file put in place during the install for the current user. Or disable Active Setup from running for this user by writing the HKCU key that is written after Active Setup has run for the user in question (see link below).
        • The procedure is attempted explained in my answer here: Updating every profile's registry on Windows Server 2003. It is all based on a HKLM key that is run once per user. Check the linked answer for detail, and there are a few external links in there that provide a lot more details.
        • UPDATE: When installing on Terminal Server you put the server in "install mode" and then per-user registry entries are written to HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstall and then written to each user's HKCU hive when they log in. This may conflict with ActiveSetup - for all I know. I have never had the chance to test it. Packaging for Terminal Server is typically done by a dedicated, specialist server team.
        • Phil 的 MsiProvideComponent 很有趣，我没用过.我应该.
        • Phil's MsiProvideComponent is interesting, I have never used it. I should.

        • 随着数据存储似乎转移到云端，数据文件部署的常见方法可能很快就会过时.

        • With data storage seemingly moving to the cloud the common approaches to data file deployment may quickly become obsolete.

        • 6:下载设置文件

          • 下载设置文件 - 在应用程序启动时为每个用户下载一次 - 从本地网络数据库/共享或互联网代替 -如果这是一个选项.
          • 如果有新的默认值或需要删除某些内容，管理员可以维护远程文件以更新值.
          • 您的应用程序理解的设置文件中的配置机制可以强制执行新的强制"值以应用于所有用户.
          • 允许在 HKLM 中配置服务器列表吗?可通过 PUBLIC PROPERTIES 在 MSI 中进行配置?
          • 或者在安装过程中在设置中设置单个 URL 并通过该 URL 维护服务器列表(您通过 DNS 重定向它指向的服务器，因此配置是一项无需重新部署的系统管理任务?).HKCU 中的当前选择集.

          • 6: Download the Settings File

            • Download the settings file - once for each users on application launch - from a local network database / share or from the Internet instead - if this is an option.
            • The remote file can be maintained by an admin to update values if there are new default values or something needs to be removed.
            • Configuration mechanisms in the settings file understood by your application could enforce new "forced" values to apply for all users.
            • Allow configuration of a list of servers in HKLM? Configurable in the MSI via PUBLIC PROPERTIES?
            • Or set a single URL in your setup during installation and maintain a list of servers via that URL (you redirect what server this points to via DNS so configuration is a sysadmin task without re-deployment required?). Present selection set in HKCU.
            • 直接向/从本地 AD 数据库或互联网连续读取/写入设置.
            • 根本没有本地设置文件，或者无法访问服务器时缓存的只读副本?或者如果无法访问服务器，只需使用内部应用程序默认值运行?在后一种方法中根本不需要管理任何文件.
            • 您可以编写要用于 HKLM(甚至通过组策略?)的服务器 (URL) 列表，甚至可以在 HKCU 中为每个用户维护当前选择的服务器.然后剩下的就在线上完成.
            • 目前普遍用于企业客户端/服务器应用程序 - 但基于云的平台将永远改变部署 - 特别是对于家庭用户.长期以来，我们已经看到浏览器(Chrome、Opera、Firefox 等)通过 Internet 保留设置.
            • 远程数据库存储意味着您可以将用户设置作为数据库管理任务进行维护，您甚至可以对数据库中的用户数据进行版本，并轻松强制执行新的默认或强制更新所有用户的现有值作为集中的 DBO 任务.
              • 不再有烦人的漫游配置文件问题.
              • 不再有失败的用户配置文件部署.
              • 总而言之:根本没有要部署的用户设置，并且数据在不同机器上永远不会不同步.
              • 防火墙/代理和网络连接问题?
              • Read / write settings directly to / from a local AD database or the Internet continuously instead.
              • No local settings file at all, or a cached read-only copy for when the server can't be reached? Or simply run with internal application defaults if server can't be reached? No file at all to manage in the latter approach.
              • You can write a list of servers (URLs) to use to HKLM (even by group policy?), and even maintain the currently selected server in HKCU for each user. Then the rest happens online.
              • Generally used in corporate client / server applications so far - but the cloud based platforms will change deployment forever - particularly for home users. We have seen browsers preserve settings via the Internet for a long time (Chrome, Opera, Firefox, etc...).
              • Remote, database storage means you can maintain user settings as a database management task and you can even version the user data in the database and easily enforce new defaults or force update existing values for all users users as a centralized DBO task.
                • No more pesky roaming profile issue.
                • No more failed deployment of userprofile files.
                • In summary: no user settings to deploy at all, and the data will never run out of sync on different machines.
                • Firewall / proxy and network connectivity issues?

                我不再喜欢选项 3(自我修复)和 选项 4(主动设置)，尽管我已经多次使用它们 - 它们确实有效做对了.但是，它们无法避免漫游配置文件问题(文件未在用户登录的所有系统上复制到位)以及在修复运行时无法访问 MSI 安装源 - 这可能会导致部署问题.在重置设置的重大升级过程中也经常出现并发症，并且在终端服务器上自我修复失败.由于勒索软件保护或安全软件干扰，自我修复可能无法安装到用户配置文件中.选项 4(活动设置)中指定的命令行可能有问题并清除数据(例如，您为 msiexec.exe 修复启用了错误的标志并意外强制覆盖设置文件 - 这通常不会被发现，直到它太晚了，损坏已经完成).现在还有更多的问题让我望而却步.两种方法都有相似但略有不同的局限性.

                I don't like option 3 (Self-repair) and option 4 (Active Setup) anymore, although I have used them many times - and they do work when done right. They are, however, not immune to roaming profile issues (files not being copied in place on all systems the user logs onto) and lacking access to the MSI installation source when repair is running - which can cause deployment problems. There are also frequent complications during major upgrades with reset settings, and self-repair fails on terminal servers. Self-repair could fail for installation to the user-profile because of ransomware protection or security software interference. The command line specified in option 4 (Active Setup) could be buggy and wipe out data (for example you enable the wrong flag for the msiexec.exe repair and force overwrite the settings file by accident - this is often not discovered until it is too late and the damage is done). And there are further issues that escape me right now. Both approaches have similar, but slightly different limitations.

                我越来越喜欢基于云的方法，让本地(和独立的)用户设置文件成为过去 - 但我很少能够以这种方式部署.不过，这些云方法可能会面临防火墙/代理问题和网络连接问题的问题 - 可能还有其他一些我还不知道的事情(现在开发人员会与 DBO 争吵，而不是比部署专家等...;-)).分布式计算有其谬误:https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing.另外:在基于云的方法中，允许将设置备份到磁盘的应用程序仍然可能是一个好主意，因此显然仍然需要一些文件管理 - 或者您只是导出几个数据库表?另外:如果您安装应用程序的试用版，您可能希望它能够在完全没有网络连接的情况下运行 - 以防用户位于非常严密的防火墙后面.由于技术问题，不允许您的用户测试您的应用程序的功能，这是一个代价高昂的错误.

                I more and more prefer cloud-based approaches to make local (and isolated) user settings files a thing of the past - but I rarely have been able to deploy things this way. These cloud approaches may face problems with firewall / proxy issues and network connectivity problems though - and probably several other things I am not aware of yet (now developers will quarrel with DBOs rather than deployment specialists, etc... ;-)). Distributed computing has its fallacies: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing. Also: in cloud-based approaches it still may be a good idea for applications to allow settings to be backed up to disk, so some file management is obviously still needed - or do you just export a couple of database tables? Also: if you install a trial version of your application, you may want it to be able to function without network connectivity at all - in case the user is behind a very tight firewall. It is a very expensive mistake to make to not allow your user to test your application's features because of a technicality.

                选项 1 和 2 的最大好处是，即使在触发修复时原始安装介质丢失，它们也能正常工作.这对于家庭和小型办公室部署尤为重要，在这种情况下，如果没有集中的软件包共享，部署可能会相当随意.您可以在安装过程中使用缓存方法在系统上缓存整个 MSI(在 Installshield 中可用，我没有检查 WiX 或 Advanced Installer)来解决这个问题(缺少源 MSI).

                The great benefit of options 1 and 2 is that they will work even if the original installation media is missing when the repair is triggered. This is particularly important for home and small-office deployment where deployment may happen rather haphazardly without a centralized package share. You can work around this problem (missing source MSI) by using caching methods to cache the whole MSI on the system during the installation (available in Installshield, I haven't checked WiX or Advanced Installer).