可能使用提升的权限创建的日志文件

Question

我有一个非常旧的应用程序，现在需要对Windows Server 2008友好。它是一个用作单例的用户应用程序。它使用注册表的HKLM部分来读取和写入配置，并创建日志文件。

主要问题：如何使UAC的应用程序适合当前最佳实践？

我最初的方法是运行应用程序不升级，如果配置需要更改用户手动重新启动它升高，重新配置，并重新启动到非升高。问题是日志文件可以创建为高级，然后非高级应用程序无法写入。可能的解决方法：

1. 不要在提升模式下做任何暗示写入日志文件的事情。但是如何检测应用程序是否处于提升模式？
2. 即使在提升模式下也可以使用非提升权限创建日志文件。怎么样？
3. 如果在打开现有日志文件时访问被拒绝，则尝试创建另一个日志文件。
4. 一直运行提升。

第一种选择是迄今为止最好看，但如何检测海拔？也许还有其他的选择？也许有一些完全不同的方法？如果可能的话，我不想过多地更改代码。

Answer 1

最好的做法是重写应用程序以使用每个用户的存储空间，除非您确实需要某个用户保存的某些内容来影响框中的其他用户。也就是说，答案“只有一个用户，因此每个用户和每台机器都是相同的”被拒绝。在这种情况下，整个应用程序始终运行不升级，并具有防止虚拟化的清单。

下一个最佳实践是对应用程序进行分区。写入HKLM的代码在单独的exe文件中，并且具有请求提升的清单。 UI有一些警告（一个按钮或菜单项上的屏蔽），用户在该位置运行此代码。单独的进程与ShellExecute一起启动，它尊重清单。用户的体验是大多数时候应用程序运行时没有提升，有时它的一部分似乎提升然后降低。这就是它看起来像但这实际上是不可能的 - 一个EXE要么升高，要么不升高。你用两个exes达到效果。

第三件好事是将日志移动到某个地方，无论您是否升高，并在需要时训练用户手动升起。我认为这不是一个好的解决方案，但是比培训他们每次在不同地方手动提升和写入日志文件要好。我猜你写在“当前目录”下，它本身在Program Files下，并且你没有清单。然后，当不提升你的应用程序将写在虚拟商店。如果用户需要查找日志文件，这真的不好。写入不同的文件夹 - AppData下的东西会很好。该位置不会被虚拟化。

检测您是否被提升的最简单方法是使用IsInRole查看用户是否为管理员。作为一个小测试将证明，即使管理员用户得到false当应用程序没有提升，甚至非管理员谁提高OTS提示将返回true返回。

Answer 2

UAC是一个相当戏剧性的变化;在事实充满危险之后，试图迫使你的申请适合它。将注册表和日志文件位置从机器区域更改为用户区域不是更容易吗？例如HKCU和CSIDL_APPDATA。如果这不适合你，那么用户只需要提升你的应用程序;你可以指定一个requireAdministrator清单。