围绕 Windows UAC 限制进行设计的正确方法？答案

【问题标题】：Correct way to design around Windows UAC limitations?围绕 Windows UAC 限制进行设计的正确方法？
【发布时间】：2010-11-24 09:52:40
【问题描述】：

我发现如果在任何级别启用 UAC，我编写的应用程序在 Windows Vista/7 下都无法正常工作，因为它将文件写入程序的安装目录，默认为“C:\Program Files\MyProgram. "如果 UAC 被禁用（或在任何其他版本的 Windows 上）它可以正常工作 - 我读到 UAC 默认拒绝应用程序对 Program Files 目录的写访问。

我的问题是，我应该如何编写我的应用程序，以便可以在根本不需要任何“权利”的情况下使用它。我不希望用户必须以提升的权限或以管理员身份运行它。我只是想让它工作。是否有任何应用程序在 UAC 下具有写入权限的某些目录，在这些目录中写入我的文件可能会更好？它们大多是动态创建/销毁/更新的配置文件。

感谢您的帮助！

【问题讨论】：

我不会将 UAC 限制称为对您的应用程序的“限制”。从技术上讲，它们是，但或多或少只是引导你不要做你一开始就不应该做的事情
“不应该做”——为什么不呢？
您到底为什么要将配置数据写入程序文件？那是安装目录。这就是可执行文件和库所在的位置。数据不去那里...
@Jim - 您的应用在许多其他情况下被破坏，例如非管理员用户。 Vista 将非管理员案例推向更多的默认设置。如果非管理员可以写入程序文件，则非特权用户可以将任意数量的木马程序放在那里并让管理员运行它们，拥有该盒子。
AppData 听起来像是正确的解决方案。也许对某些人来说这听起来很明显，但对我来说似乎并不那么明显。这些文件不是为用户准备的，它们是专门为程序存储设置的。我想出了比应用程序存在的地方更好的地方。看来我错了。我会改变我的方法。

标签： windows-7 windows-vista installation uac

【解决方案1】：

应将每个用户应用程序的特定数据写入 AppData 文件夹。

您应该将SHGetKnownFolderPath 与 FOLDERID_LocalAppData 一起使用。

在托管代码中，您应该将System.Environment.GetFolderPath 与 System.Environment.SpecialFolder.LocalApplicationData 一起使用。

【讨论】：

如果您使用 .NET 配置功能（System.Configuration 命名空间，这些是 C# 项目中的 .settings 文件），您的数据将被放置在正确的位置，您将拥有非常优雅的访问和更新它的方法。

【解决方案2】：

是的，有特定的位置。将this msdn article 作为第一个参考。它提到了地点：

CSIDL_APPDATA
CSIDL_LOCAL_APPDATA
CSIDL_COMMON_APPDATA

在本机代码中，SHGetKnownFolderPath 方法应该很有用。

在托管代码中，您可以使用Environment.GetFolderPath()。如果您在特定的应用程序框架中，例如 windows 窗体，您可以通过直接属性更轻松地访问，例如 Application.LocalUserAppDataPath（这是我个人最喜欢的技术）。框架路径将在其返回的路径上包含特定于应用程序的限定符，以区分（例如）您的应用程序的不同版本。

【讨论】：