Glytzhkof :这个问题与新MSI用户的常见问题有关,他们认为MSI需要一个自定义操作来支持MSI本身不支持的功能。
在这种情况下,MSI中的 IniFile表允许共享Ini文件的合并,回滚和更新在系统上。 Ini文件的所有更新都应该通过此表执行,因为您可以免费获得许多功能,并且您将符合所有MSI指南。
如果有办法通过原生功能获得相同的效果,请始终避免自定义操作。
我的WIX msi上有一个c#customaction。
当msi开始需要管理员帐户并且所有工作正常以外我的习惯,它无法写入programdata文件夹。
我根据wix参考设置了impersonate="no"
:
此属性指定在执行此自定义操作时,作为LocalSystem执行的Windows Installer是否应模拟安装用户的用户上下文。通常,该值应为“是”,除非自定义操作需要提升权限才能将更改应用于计算机。
但不起作用。
这是我的自定义操作配置:
<CustomAction
Id="MyCustomActionCA"
BinaryKey="mycustomactionDLL"
DllEntry="MyCustomAction"
Execute="immediate" Return="check" Impersonate="no" />
<InstallUISequence>
<Custom Action="MyCustomActionCA" After="CustomDialog1">NOT Installed</Custom>
</InstallUISequence>
在MyCustomAction
关闭后启动 CustomDialog1
,这没关系,我的代码运行正常,但在MyCustomAction
我有一行代码如下:
File.WriteAllText(mypath, mycontent);
mypath
引用ProgramData
文件夹并抛出异常,因为用户无法在其中写入。
答案 0 :(得分:2)
据我所知,这里似乎有两个问题:
第一个是CA需要延迟,如果它是impersonate =“no”,并且你不清楚你是否已经这样做了。
第二个问题是ProgramData是用户配置文件概念。例如,它在我的系统上的C:\ Users \中。如果你使用impersonate =“no”运行,你将使用系统帐户运行,因此它将尝试写入一些奇怪的(不存在的)C:\ Users \ System文件夹。
您可能在此处遇到设计问题,因为您说您需要提升的用户权限才能写入该文件夹,但除非您延迟使用系统帐户权限,否则无法提升。您可能需要描述您尝试解决的确切问题,看看是否有其他方法。
答案 1 :(得分:0)
最佳选择:重新设计您的应用程序,将此ini文件作为每用户文件(任何用户都可以写入自己的用户配置文件)从内部启动应用程序exe本身的默认值。解决了部署问题。
关于部署上下文中发生的情况:Windows安装程序仅运行部分安装 LocalSystem - 所谓的安装事务。其余的设置以启动MSI的用户身份运行 - 这包括整个用户界面序列,您已添加自定义操作。
尝试设置延迟的操作,在InstallFinalize之前安排它,并将模拟设置为no。
关于每用户数据管理,请参阅本文稍微不同的主题,以了解处理需要在应用程序的已部署版本之间进行管理的每用户数据的方法:{{3} }
答案 2 :(得分:0)
检查此线程以获取有关如何使用MSI内置支持写入INI文件的信息: Wix modify an existing ini file
进一步参考: http://wixtoolset.org/documentation/manual/v3/xsd/wix/inifile.html