我有一个非常古老的应用程序，现在需要对 Windows Server 2008 友好。它是一个作为单例运行的用户应用程序。它使用注册表的 HKLM 部分来读取和写入配置，并创建日志文件。
主要问题:如何根据当前最佳实践使应用程序与 UAC 一起工作？
我最初的方法是在非提升的情况下运行应用程序，如果需要更改配置，用户手动重新启动提升的应用程序，重新配置，然后重新启动为非提升的。问题是日志文件也可以创建提升，然后非提升的应用程序无法写入它。可能的解决方法:
- 不要在提升模式下做任何暗示写入日志文件的事情。但是如何检测应用程序是否处于提升模式？
- 创建具有非提升权限的日志文件，即使在提升模式下也是如此。怎么样？
- 如果打开现有日志文件时访问被拒绝，则尝试创建另一个日志文件。
- 一直保持高强度运行。
到目前为止，第一个选项看起来最好，但如何检测高度？也许还有其他选择？也许有一些完全不同的方法？如果可能，我希望不必过多更改代码。
最佳答案
最佳做法是重写应用以使用按用户存储，除非您确实需要一个用户保存的内容来影响盒子上的其他用户。也就是说，回答“只有一个用户，所以每个用户和每个机器是一样的”被拒绝了。在这种情况下，整个应用始终以非提升的方式运行，并带有防止虚拟化的 list 。
下一个最佳实践是对应用程序进行分区。写入 HKLM 的代码在一个单独的 exe 中，并且有一个请求提升的 list 。用户界面在用户运行此代码的地方有一些警告(按钮或菜单项上的盾牌)。单独的进程使用 ShellExecute 启动，它尊重 list 。用户的体验是，大部分时间应用程序运行时未提升，有时它的某些部分似乎提升然后下降。这就是它看起来的样子，但实际上是不可能的 - 一个 exe 要么被提升，要么没有。你用两个 exe 实现了这个效果。
第三个最好的办法是将日志移动到相同的位置，无论您是否提升，并培训您的用户在需要时手动提升。我认为这根本不是一个好的解决方案，但总比训练他们每次手动提升并在不同的地方写入日志文件要好。我猜你是在“当前目录”下写的，它本身就在 Program Files 下，而且你没有 list 。然后，当没有提升时，您的应用程序将在虚拟商店下写入。如果用户需要查找日志文件，这确实不太好。写入不同的文件夹 - AppData 下的东西会很好。该位置不会被虚拟化。
检测您是否被提升的最简单方法是使用 IsInRole 来查看用户是否是管理员。正如一些测试将证明的那样，即使是管理员用户也会得到 false当应用程序未提升时返回，甚至使用 OTS 提示提升的非管理员也会得到 true返回。
关于windows - 可能使用提升的权限创建的日志文件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4135568/