在用户文件夹中创建一个 .config 文件夹 [英] Create a .config folder in the user folder

问题描述

在安装我的程序时，我想在用户文件夹中创建一个 .config 文件夹.例如:

C:\Users\MyUser\.config

这是我尝试过的，但不起作用:

<Directory Id="ConfigUserFolder" Name=".config"><Directory Id="UserConfig" Name="Config" ><Component Id="ConfigFolder" Guid="GUID"><RemoveFolder Id='RemoveConfig' Directory='UserConfig' On='uninstall'/><RemoveFolder Id='RemoveConfigUserFolder' Directory='ConfigUserFolder' On='uninstall'/><RegistryValue Root='HKCU' Key='Software\MySoftware' Type='string' Value='' KeyPath='yes'/></组件></目录></目录></目录><Property Id="USERPROFILEFOLDER"/>

知道我遗漏了什么/做错了什么吗?

解决方案

此应用程序是否为常规可执行文件?或者某种网络应用程序或插件?换句话说:它有自己的启动顺序吗?

这个建议听起来像是破记录，但是:用户配置文件文件夹(和 HKCU 设置)中的文件夹和文件在应用程序启动时创建比在安装过程中更好.

只需在您的设置中保留此结构，使您的应用程序更智能，并能够在启动时为每个用户创建此文件夹 - 并且能够将任何数据文件从其主只读模板位置复制到该文件夹​​中%ProgramFiles% 安装文件夹.

我之前写了一篇关于用户特定文件和设置部署问题的完整咆哮:从管理员配置文件在当前用户配置文件上创建文件夹和文件.我描述了诸如 MSI 自我修复和主动设置之类的选项 - 并列出了一些关于它们不可靠原因的详细信息(并提出了一些可能更好的方法).

我想说:消除复杂性和错误源，并尽可能地留在熟悉的领域.避免使用高级设置功能，因为它们难以调试，并且具有异常和陌生的复杂性.什么与您的问题相关:避免通过安装程序完成每个用户的部署.

<小时>

以上基本上就是全部内容，但在此充实它是使用应用程序启动顺序而不是为每个用户设置的主要原因:

1. 可预测性和可靠性:这种方法可以为启动您的应用程序的任何用户可靠地创建文件夹 - 无需依赖 Windows Installer 将每个用户的文件和文件夹放置到位.

   • Windows Installer 自我修复可以通过某些机器(例如终端服务器)上的策略阻止运行，并且您的文件夹将永远不会为未运行原始安装的用户创建.

   • 如果您还想安装用户特定的文件(不仅仅是文件夹)，那么用户特定文件和设置的 MSI 部署充其量是不可靠的，并且容易发生意外的文件和设置覆盖(REINSTALLMODE = amus - 强制覆盖)和用户设置以及因意外卸载旨在永久但未标记为永久的设置文件而导致的数据丢失(意外).这会导致很多问题.

   • 技术性很强，但是当用于引用可能安装多次的计数文件时，MSI 的组件 GUID 概念在概念上有点崩溃.

2. 实施&调试:应用程序启动顺序是只是常规代码"，而 Windows Installer 和部署对于许多开发人员来说可能是陌生的领域.因此，您可以避免因部署的复杂性而导致的意外问题(在 WiX 历史背景下写的关于部署复杂性的简介).

   • 如果您使用具有非常阴谋复杂性"的复杂顺序、模拟和条件化方面的自定义操作(这些问题不会立即显而易见，但会在最不方便的时候浮出水面)，则尤其如此.

   • 您的应用程序启动序列具有可预测的用户上下文、对用户环境的完全访问权限和交互性以及错误和警告消息.只需重新启动应用程序即可轻松调试问题，而不是编译和运行设置(并在自定义操作的情况下附加调试器 - 远远超出您的问题范围).

   • 您可以避免安装程序的一次性"性质和调试困难，因为部署错误总体上难以重现(无法访问问题系统，通常缺少日志记录，难以清除先前的错误).对于启动序列，您只需让用户重新启动应用程序并报告看到的错误 - 或检查事件日志或任何其他可用的日志记录.

   • 根据我的经验，QA 人员测试应用程序启动序列的经验通常比部署功能的经验要多.

   • 对于现实世界中的情况，我可能会让应用程序调试听起来过于乐观"，但相信我，它确实比部署调试更容易.

3. 设置管理:您的应用程序的启动序列可以(更多)可靠地对您的数据和设置文件执行任何形式的维护"，这是不可能的从设置中可靠地完成.

   • 这些通常是资源文件"而不是数据文件——换句话说，程序运行期间使用的模板和设置——不仅仅是用户创建的内容(有时也需要清理"——但你可以这样做在文件打开而不是应用程序启动时).

   • 您想修复为每个用户复制的文件中的某些内容

     • 泄露元文件图片
     • 数据文件错误和故障
     • 只是由每个用户设置引起的错误真的......
   • 强制执行新的强制性设置
     • 将文件移动到新位置或备份它们
     • 删除不再有效(或错误地未加密)的设置
     • 从 HKCU 中删除导致应用程序崩溃的二进制流
   • 关于设置如何标记"系统以激活应用程序的启动序列维护功能"的描述:http://forum.installsite.net/index.php?showtopic=21552(2019 年 2 月转换为 WayBack Machine 链接).

设置基本上应该做任何需要提升权限的事情，大多数其他事情 - 在你的应用程序中做 - 随着时间的推移，某些提升的事情实际上可以作为服务运行 - 它没有困扰的排序、条件或模拟变量部署.

When installing my program, I'd like to create a .config folder into the user's folder. For example :

C:\Users\MyUser\.config

This is what I tried but it doesn't work :

<Directory Id="USERPROFILEFOLDER" Name="[%USERPROFILE]">
 <Directory Id="ConfigUserFolder" Name=".config">
   <Directory Id="UserConfig" Name="Config" >
     <Component Id="ConfigFolder" Guid="GUID">
       <RemoveFolder Id='RemoveConfig' Directory='UserConfig' On='uninstall' />
       <RemoveFolder Id='RemoveConfigUserFolder' Directory='ConfigUserFolder' On='uninstall' />
       <RegistryValue Root='HKCU' Key='Software\MySoftware' Type='string' Value='' KeyPath='yes' />
     </Component>
  </Directory>
 </Directory>
</Directory>

<Property Id="USERPROFILEFOLDER" />

Any idea what I'm missing/doing wrong ?

解决方案

Is this application a regular executable? Or some sort of Web-App or Plug-In? In other words: does it have its own launch sequence?

I sound like a broken record with this advice, but: folders and files in the user profile folder (and HKCU settings) are better created on application launch than during installation.

Just leave this construct out of your setup and make your application smarter and capable of creating this folder on launch for every user - and to be able to copy any data files into the folder from their template locations in your main read-only %ProgramFiles% installation folder.

I previously wrote a whole rant about the problem of user-specific files and settings deployment: Create folder and file on Current user profile, from Admin Profile. I describe options such as MSI self-repair and Active Setup - and list some details on why they are unreliable (and suggest some potentially better approaches).

I'd say: kill complexity and error sources and stay in familiar territory whenever you can. Avoid advanced setup features due to their hard-to-debug nature and unusual and unfamiliar complexity. And what is relevant for your question: avoid per-user deployment done via the installer.

---

The above is basically all there is to say, but fleshing it out here are the main reasons to use your application launch sequence instead of your setup for per-user stuff:

1. Predictability & Reliability: this approach reliably creates the folder for any user who launches your application - without relying on Windows Installer to put per-user files and folders in place.

   • Windows Installer self-repair can be prevented from running by policy on certain machines (for example terminal servers) and your folder will then never be created at all for users who did not run the original install.

   • If you also want to install user-specific files (not just a folder), then MSI deployment of user-specified files and settings is unreliable at best, and prone to accidental file and settings overwrite (REINSTALLMODE = amus - force overwrite) and user settings and data loss from unexpected uninstall of settings files intended to be permanent, but not marked as such (by accident). A lot of problems can result from this.

   • Very technical, but MSI's component GUID concept sort of breaks down conceptually when used to reference count files potentially installed multiple times.

2. Implementation & Debugging: the application launch sequence is "just regular code" whilst Windows Installer and deployment may be unfamiliar territory for many developers. You hence avoid the unexpected problems that results from the complexity of deployment (a blurb on deployment complexity written in the context of the history of WiX).

   • This is especially true if you move into custom actions with their complex sequencing, impersonation and conditioning aspects featuring very "conspiratory complexity" (problems that are not immediately obvious, but that will surface when least convenient).

   • Your application launch sequence has predictable user context, full access to the user's environment and interactivity is available with error- and warning messages. Problems can be debugged easily by simply re-launching the application as opposed to compiling and running a setup (and attaching the debugger in the case of custom actions - well beyond the scope of your question).

   • You avoid an installer's "one shot" nature and difficulty of debugging due to the hard-to-reproduce nature of deployment errors overall (no access to the problem system, generally missing logging, difficulty of cleaning up prior mistakes). For the launch sequence you just have users re-launch the application and report the error seen - or check the event log or whatever other logging is available.

   • In my experience QA personnel will generally have more experience testing application launch sequences than deployment features.

   • And I might be making application debugging sound "too rosy" for what it is in the real world, but trust me it is indeed easier than deployment debugging.

3. Settings Management: your application's launch sequence can (much more) reliably perform any form of "maintenance" on your data and settings files that is impossible to accomplish reliably from a setup.

   • These are often "resource files" and not data files - in other words templates and settings used during program operation - not just content created by the user (which sometimes also requires "cleaning" - but you can do that on file open instead of application launch).

   • You want to fix something in files duplicated for each user

     • Leaking meta-files pictures
     • Data file errors and glitches
     • Just bugs caused by per-user settings really...
   • Enforce new mandatory settings
     • Move files to a new location or back them up
     • Remove settings that are no longer valid (or erroneously unencrypted)
     • Delete binary streams from HKCU that make your application crash
   • A description of how a setup can "flag" the system to activate an application's "launch sequence maintenance functions": http://forum.installsite.net/index.php?showtopic=21552 (Feb 2019 converted to WayBack Machine link).

A setup should essentially do anything that requires elevated rights, most other things - do it in your application - and certain elevated things can actually be done over time running as a service - which features no sequencing, conditioning or impersonation variables that plague deployment.

这篇关于在用户文件夹中创建一个 .config 文件夹的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！