应用程序安装的 .NET 2.0 进程提升

发布于 2024-08-27 11:23:22 字数 1134 浏览 7 评论 0原文

我们有一个用 C++ 和 .NET 编写的应用程序,为所有用户安装在 Program Files 文件夹中。该应用程序下载自身的新版本(作为 MSI 安装程序)并生成新的安装程序进程来替换自身。

目前的安装过程:

  1. 将安装管理器应用程序(C#、.NET 2.0)复制到临时目录。 将此称为“管理器”,
  2. 根据本文,
  3. 管理器以提升的权限执行。原来的应用程序退出。
  4. 管理器生成 MSI 安装程序(具有提升的权限,因为副本已提升)
  5. 管理器生成应用程序的新版本。

错误:

新安装的应用程序正在提升的状态下运行。这会导致一些问题,我这里就不一一列举了。

理想情况下,新安装的应用程序的启动将在原始用户的权限下运行。

我不知道如何在提升后将应用程序降级回标准用户。

一个不优雅的黑客:(

是的,是的,无论如何,整个过程都是不优雅的)

  1. 将安装管理器复制到临时目录
  2. 使用标准用户权限运行安装管理器。我们将此实例称为“LowlyManager”。
  3. 原始应用程序退出。
  4. LowlyManager 再次生成应用程序,这次权限提升。让我们将此实例命名为“UpperManagement”
  5. UpperManagement 生成安装程序
  6. UpperManagement 正常退出,返回安装程序的退出代码。
  7. LowlyManager 解释来自 UpperManagement 的错误代码,并生成新安装的应用程序。这次是作为最初的调用者。

有更好的方法来做到这一点吗?

(我在这些步骤之前和之后省略了一些其他细节,以使用户的过程更加顺畅,但是这个应该足以理解我试图解决的问题的核心。)

其他要求:

  • 我们不能作为每用户应用程序安装
  • 如果UAC只是简单地询问,则不应向用户显示身份验证对话框“您确定要允许这样做吗?”。我认为这可能会终止使用 WindowsImpersonationContext 的解决方案,但我不确定。
  • 系统需要在 XP、Vista 和 Windows 7 上运行(即使 XP 有单独的进程)。

We have an application written in both C++ and .NET that installs for all users in the Program Files folder. This application downloads new versions of itself (as MSI installers) and spawns the new installer process to replace itself.

The install process as it exists today:

  1. Copy an install manager app (C#, .NET 2.0) to the temp directory. Call this 'Manager'
  2. Manager is executed with elevated privs per this article.
  3. The original application exits.
  4. Manager spawns the MSI installer (with elevated privs, since the copy is elevated)
  5. Manager spawns the new version of the app.

The bug:

The newly installed app is running in an elevated state. This causes problems I won't enumerate here.

Ideally, the launch of the newly installed app would be run with the permissions of the original user.

I can't figure out how to demote the app back to being the standard user after elevation.

An inelegant hack:

(yeah, yeah, this whole process is inelegant anyway)

  1. Copy the install manager to the temp directory
  2. Run the install manager with standard user privs. Lets call this instance 'LowlyManager'.
  3. Original application exits.
  4. LowlyManager spawns the app again, this time with elevated privs. Let's name this instance 'UpperManagement'
  5. UpperManagement spawns the installer
  6. UpperManagement exits gracefully, returning the exit code of the installer.
  7. LowlyManager interprets the error code from UpperManagement, and spawns the newly installed application. This time as the original invoker.

Is there a better way to do this?

(I've left out a bunch of other details before and after these steps that make the process smoother for the user, but this should be enough to understand the core of the problem I'm trying to solve.)

Other requirements:

  • We can't install as a per-user app
  • The user shouldn't be presented with an authentication dialog box if UAC would have simply asked "are you sure you want to allow this?". I think this might kill a solution using WindowsImpersonationContext, but I'm not sure.
  • The system needs to work on XP, Vista, and Windows 7 (even if there is a separate process for XP).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文