在打开 UAC 的情况下编辑 ProgramFiles 中的配置
我的问题非常类似于 安装完成后启动应用程序，并打开 UAC
我们不想在安装程序中构建一组复杂的配置屏幕，而是希望在安装程序完成后启动配置过程。
在所有情况下，这都需要编辑 ProgramFiles 文件夹中的内容，当在未提升的情况下启用 UAC 时，标准用户无法编辑这些内容。
我们知道但不喜欢使用的选项：
- 通过引导程序提升整个安装程序 - 我们不希望这样做是为了支持在提升结束时执行配置的 1 个操作。
- 在配置过程中包括强制提升 - 虽然在某些情况下我们可以将其工作到应用程序中，但在某些情况下我们希望在 App.config 上启动一个简单的编辑器，而这种强制提升将不是一个选项。
是否有某种方法可以获得提升版本的
<Property Id="WixShellExecTarget" Value="[INSTALLDIR]\app.config" />
<CustomAction Id="LaunchApplication" BinaryKey="WixCA" DllEntry="WixShellExec" />
或者是否更适合制作自定义 UI 并在 UI 中较早添加复选框并将其作为延迟操作启动而无需等待，例如
<CustomAction Id="Config.SetProperty" Property="Config" Value='"Open" app.config' />
<CustomAction Impersonate="no" Execute="deferred" Return="ignore"
Id="Config" BinaryKey="WixCA" DllEntry="CAQuietExec" />
或者我们只是忘记这一切作为一个坏主意并且管理员可以找到该文件并右键单击“提升”进行编辑。
My question is quite similar to
Launch application after installation complete, with UAC turned on
Rather than build a complex set of configuration screens into the installer, we would like to launch a config process after the installer is complete.
In all cases this will require the editing of content in ProgramFiles folder which is not editable as a standard user when UAC is enabled without elevation.
Options we know of and prefer not to use:
- to elevate the whole installer with a bootstrap - we would like not to do this to support 1 action of execute the config at the end elevated.
- including forced elevation in the config process - while we could in some cases work this into the app, in some cases we want to launch a simple editor on App.config where this forced elevation would not be an option.
Is there some way of getting an elevated version of
<Property Id="WixShellExecTarget" Value="[INSTALLDIR]\app.config" />
<CustomAction Id="LaunchApplication" BinaryKey="WixCA" DllEntry="WixShellExec" />
Or is it more appropriate to make custom UI and add the checkbox earlier in the UI and launch it as a deferred action without waiting, like
<CustomAction Id="Config.SetProperty" Property="Config" Value='"Open" app.config' />
<CustomAction Impersonate="no" Execute="deferred" Return="ignore"
Id="Config" BinaryKey="WixCA" DllEntry="CAQuietExec" />
Or do we just forget it all as a bad idea and the admin can go find the file and right click elevate to edit.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
其中一种选择可能是像现在一样从安装程序中启动非提升应用程序。然后，当您的应用程序检测到它需要编辑配置文件时，它会请求提升。
另一种选择是将配置文件存储在 ProgramData 目录中而不是 Program Files 中。该位置无需提升即可写入。这里需要注意的是：在那里创建的文件和目录仅对创建它们的用户具有写入/修改权限；其他用户将具有只读访问权限。如果不需要，您可以更改应用程序配置文件的 ACL。
One of the options could be to launch your app non-elevated from the installer as you do now. Then when your app detects that it needs to edit config files, and it requests elevation.
Another option is to store config files in ProgramData directory rather than in Program Files. This location is writable without elevation. One caveat here: files and directories that created there will have write/modify permissions only for the user who created them; other users will have read-only access. If it's not desirable, you can change ACLs for your app config files.
我建议使用一个单独的配置工具，它需要提升所有用户配置，并在提升被拒绝时继续每用户配置。
安装程序完成后启动此程序（仅从 UI 序列，将其绑定到“完成”按钮），以便正常安装启动并在完成时提示提升，而静默安装则需要管理员手动启动配置工具或编辑配置文件他们自己。
请注意，如果您将配置文件作为 MSI 组件进行安装，并且该配置文件已被编辑，则广告快捷方式或运行 Windows Installer“修复”将使用 MSI 中包含的配置文件覆盖该配置文件。我们的一般解决方案是部署一个sample.config，并要求管理员在安装后将其编辑复制到application.config。如果 application.config 不存在，配置工具将启动或显示错误消息。这样做的另一个好处是在删除/升级时保留配置。
I suggest a separate config tool, that requires elevation for all-user config and continues with per-user config if elevation is denied.
Launch this on completion of installer (from the UI sequence only, tie it to the 'Finish' button) so that normal installs launch and prompt for elevation on completion while silent installs require the Admin to manually launch the configuration tool or edit the config file themselves.
Note that if you're installing the config file as an MSI component, if it has been edited then an Advertised shortcut or running a Windows Installer 'repair' will overwrite this with the one included in the MSI. Our general solution has been to deploy a sample.config and require the administrator to edit copy this to an application.config post-install. If the application.config is not present, the configuration tool launches or an error message displays. This has the added benefit that the configuration is preserved on remove/upgrade.