安装我的程序时,我想在用户的文件夹中创建一个.config
文件夹。
例如:
C:\Users\MyUser\.config
这是我尝试的但是它不起作用:
<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" />
知道我错过了什么/做错了吗?
答案 0 :(得分:2)
此应用程序是常规可执行文件吗?或某种Web应用程序或插件?换句话说:它有自己的发射顺序吗?
我听起来像是一个破碎的记录,但是:在用户配置文件夹(和HKCU设置)中的文件夹和文件在应用程序启动时比在安装期间更好地创建。
只需将此构造保留在您的设置之外,并使您的应用程序更智能,并且能够在启动时为每个用户创建此文件夹 - 并且能够将任何数据文件从其主要只读模板位置复制到该文件夹中%ProgramFiles%
安装文件夹。
我之前写过关于用户特定文件和设置部署问题的全部咆哮:Create folder and file on Current user profile, from Admin Profile。我描述了MSI自修复和主动设置等选项 - 并列出了它们不可靠的原因(并提出了一些可能更好的方法)。
我会说:消除复杂性和错误来源,保持熟悉的领域,只要有可能。由于难以调试的特性以及不寻常和不熟悉的复杂性,因此避免使用高级设置功能。 与您的问题相关的内容:避免通过安装程序完成每用户部署。
以上基本上只是说,但是在这里充实它是使用应用程序启动序列而不是每个用户的设置的主要原因:
可预测性&amp;可靠性 :此方法可以为启动应用程序的任何用户可靠地创建文件夹 - 而无需依赖Windows Installer来放置每个用户的文件和文件夹。
可以阻止某些计算机(例如终端服务器)上的策略运行Windows Installer自我修复,并且对于未运行原始安装的用户,将永远不会创建您的文件夹。
如果您还想安装特定于用户的文件(而不仅仅是文件夹),那么MSI部署的用户指定文件和设置充其量是不可靠的,并且容易发生意外的文件和设置覆盖({{3意外卸载设置文件的用户设置和数据丢失是永久性的,但没有标记为(不小心)。这可能导致许多问题。
非常技术性,但MSI的组件GUID概念在用于引用可能多次安装的计数文件时从概念上分解。
实施&amp;调试 :应用程序启动顺序是&#34; 只是常规代码&#34;而Windows Installer和部署可能是许多开发人员不熟悉的领域。因此,您可以避免REINSTALLMODE = amus导致的意外问题(在WiX历史背景下编写的部署复杂性模糊)。
如果您采用复杂的排序,模拟和调节方面进行自定义操作,尤其如此,这些方面具有很强的“呼吸复杂性”和#34; (这些问题不是很明显,但最不方便的时候会出现问题)。
您的应用程序启动序列具有可预测的用户上下文,可以完全访问用户的环境,并且可以使用错误和警告消息进行交互。通过简单地重新启动应用程序而不是编译和运行设置(以及在自定义操作的情况下附加调试器 - 远远超出您的问题范围),可以轻松调试问题。
你避免使用安装人员一次性拍摄&#34;由于整体部署错误难以重现的性质(无法访问问题系统,通常缺少日志记录,清理先前错误的难度),因此调试的性质和难度。对于启动序列,您只需让用户重新启动应用程序并报告所看到的错误 - 或检查事件日志或其他可用的日志记录。
根据我的经验,QA人员通常比测试部署功能有更多测试应用程序启动顺序的经验。
我可能正在使应用程序调试声音太棒了#34;太过乐观&#34;对于它在现实世界中的用途,但相信我,它确实比部署调试更容易。
设置管理 :您的应用程序的启动顺序可以(更多)可靠地执行任何形式的&#34;维护&#34;在您的数据和设置文件中,无法通过设置可靠地完成。
这些通常是&#34;资源文件&#34;而不是数据文件 - 换句话说 - 在程序运行期间使用的模板和设置 - 不仅仅是用户创建的内容(有时也需要&#34;清理&#34; - 但你可以在文件打开而不是应用程序启动时执行此操作)
您希望在每个用户重复的文件中修复某些内容
设置应该基本上做任何需要提升权限的事情,大多数其他事情 - 在你的应用程序中做 - 并且某些提升的事情实际上可以随着时间的推移作为服务运行 - 其中没有任何排序,调节或冒充变量困扰部署。
答案 1 :(得分:0)
要使用WiX执行此操作,您需要使用父组件下的CreateFolder元素。问题与此基本相同:
在我看来,作为一种更好的做法,您应该使用标准的Windows Installer文件夹属性作为位置。完整列表如下:
例如ProgramFiles64Folder,AppDataFolder(可能是您目录的最佳位置),CommonAppDataFolder等。