UAC实施的最佳实践是什么？（.NET）

我正在考虑开发一个应用程序，该应用程序大部分时间都应该作为标准用户运行，但对于某些操作，将需要提升的管理访问权限。将内容复制到受保护的文件夹时，用户体验应该与Windows资源管理器中类似

现在的问题是，这应该如何在.NET中实现？我知道只能提升整个流程或某些COM实例，而不能提升单个函数。但那正是我需要的。我应该走哪条路？编写两个可执行文件，一个有清单，另一个没有清单；以编程方式再次运行同一进程；使用一些COM的东西？那么我就有了额外的特权，但是如何告诉另一个进程该做什么呢？使用.NET远程处理（哪种已弃用/复杂？）；使用套接字/管道/任何东西实现我自己的IPC？提升的任务可能需要在过程中间向用户询问。而且它必须是可取消的

---

有很多东西告诉我UAC在内部是如何工作的，或者系统管理员如何配置它，但我没有找到任何东西来回答这些基本问题。

我们这里似乎有两个不同的问题：

我应该如何处理需要提升权限的操作

如果我使用一个单独的流程，我应该如何告诉另一个流程该做什么

以下是我试图回答的问题：

从这个SO问题来看：按照您在问题中建议的解决方案（运行另一个进程并在启动时请求提升）似乎是“正确答案”

至于告诉另一个流程应该做什么，下面是我如何尝试的：

我将首先将需要提升权限的每个操作拆分为它们自己的“助手”程序。这些助手程序只执行一个操作，通过命令行获取参数

例如，假设您的程序需要停止/启动一项服务，我会编写一个名为servicecontroller的小型帮助程序（实际上您可能希望使用该命令），该程序使用与以下类似的命令行参数：

servicecontroller stop MyCoolService
servicecontroller start MyCoolService

这些参数将由“Main”程序建立，并在点击“OK”后传递

但是，上述解决方案有几个问题，您可能会关心，也可能不关心：

您正在命令行上传递参数，这很容易被嗅探到

您受到+程序路径长度的限制（从MSDN开始：添加到进程完整路径长度的参数长度必须小于2080）

将信息传递给您可能有点棘手（如果您需要）

谷歌搜索揭示了这篇博文，它基本上推荐了我上面描述的内容。祝你好运

---

根据评论中提出的其他问题进行编辑：

当需要执行提升的操作时，建议启动单独的可执行文件还是相同的可执行文件

（我正在读这篇文章的字里行间）我应该多久提示用户一次这些操作

我不知道你到底在做什么，我的看法是：

我个人会为每一个动作设置单独的可执行文件，但我不知道你到底想做什么，所以很难打这个电话。一般来说，似乎每个提升的操作都需要一个单独的流程

我对你的第二个例子感到有点困惑，再一次，我不知道你到底想做什么，我将根据你在评论中给出的例子来做 在文件管理器示例中，我将执行explorer所做的操作，首先旋转每个目标目录，以确定是否有任何目标位置需要提升的复制权限。如果他们这样做，我会标记一个标志，指示操作需要以管理员身份执行，提示用户，然后以管理员身份执行整个操作

对于文本编辑器示例，我将执行与上面类似的操作，当用户向您提供目标目录检查以查看您是否具有对该位置的写入权限时，如果不通知用户他们正在保存到需要提升的位置，请将其工作保存到可写位置（您的程序的APPDATA可能是一个好地方，甚至是临时文件），然后启动请求提升的复制过程，如果用户取消UAC对话框，请确保捕获此取消并删除临时文件

如果您发现您的程序需要多次请求提升（Readas:1或2种极端情况），我会劝阻您不要保留提升的工作进程在程序的生命周期内，我会问为什么它没有被标记为总是提升的。我喜欢遵循“最不意外”的规则，当我给你提升的权限时，我希望你只执行请求它的操作，而不是继续通过第一个请求泵送需要提升的操作

所有这些都是说，没有什么可以阻止你做上述事情，一旦你让某个进程获得提升的权限，他就可以邀请他的所有伙伴。基于你希望保持提升的进程，为什么不保存程序的当前状态，并以提升的权限重新启动程序并恢复状态呢，在我看来，这与工人进程始终处于提升状态是一样的

---

如果您能告诉我们更多关于您正试图做的事情，我们可能会找到更好的方法来实现这一点，而不必遇到UAC问题。虽然有一些很好的理由可以写入受UAC保护的区域，但在大多数情况下，程序不需要写入/访问这些位置。

为了让您来回获取参数也可以使用环境变量和控制台输出。如果创建进程开始信息，则可以设置environment v