.NET 的哪些部分需要管理权限才能执行？
框架的哪些部分要求用户不仅仅是标准用户？我之所以问这个问题，是因为我正在尝试编制一份迁移到 Windows 7 时现有应用程序可能出现的问题的列表。
现在，我自己可以想到一些事情：
- 写入事件日志
- 写入 Current_User 之外的注册表项范围
- 获取环境变量
- 等...
我真的想要一个更完整的列表，到目前为止我还没有找到一个像样的资源来列出所有这些东西。
请注意，我并不是在寻找提升现有应用程序权限的方法（这可以通过使用清单来完成），我只是在识别代码中可能导致问题的操作。
Which parts of the framework require a user to be more than a Standard User? The reason I'm asking is because I'm trying to compile a list of possible issues with our existing applications when migrating to Windows 7.
Now, I can think of a few things myself:
- Writing to Eventlog
- Writing to Registry Keys outside of Current_User scope
- Getting an Environment variable
- etc...
I really would like a more complete list and so far I've not come across a decent resource in which all this stuff is listed.
Note that I'm not looking for ways of elevating the privileges for the existing apps (which can be done by using a manifest), I'm simply identifying actions in code that might cause issues.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
嗯，您的示例实际上与 Windows 7 或 .NET 没有任何关系。实际上它们已经是“Designed for Windows NT 4.0”徽标要求的一部分。如果您以非管理员用户能够在 NT、Win2k 或 XP 上运行的方式编写应用程序，那么它在 Vista/Win7 上也能正常工作。
当您在 x64 系统上运行软件时，还有另一个常见的陷阱（但这也不是 Win7 特有的，但对于 Win2003 Server x64 或 Win XP x64 也是如此）：如果您使用本机 32 位代码， （如调用本机 DLL 或与进程内组件的 COM 互操作），请确保在 Visual Studio 项目设置中选择“x86”作为平台目标，而不是“任何 CPU”。否则，您的应用程序将作为 64 位进程运行，并且您不能在同一进程中混合使用 32 和 64 位代码，因此您会遇到错误。
当然，正如最佳实践一样，使用 Environment.GetSpecialFolders 而不是硬编码路径。
Well, your examples don't really have anything to do with Windows 7 or .NET. Actually they were already part of the "Designed for Windows NT 4.0" logo requirements. If you have written your application in a way that non-admin users were able to run it on NT, Win2k or XP, it will just work fine on Vista/Win7.
There is another common pitfall when you run your software on x64 systems (however this too isn't specific to Win7 but is true e. g. for Win2003 Server x64 or Win XP x64 as well): If you are working with native 32-bit code, like calls to a native DLL or COM interop with a in-process component), make sure to select "x86" as the platform target in Visual Studio project settings instead of "Any CPU". Otherwise your application will run as a 64 bit process, and you can't mix 32 and 64 bit code in the same process, so you would run into errors.
And of course, as it always has been best practice, use
Environment.GetSpecialFoldersinstead of hard-coded paths.将其视为“图书馆调用的内容”将会导致您走上错误的道路。考虑写入文件的任何内容。如果该文件位于 Program Files（以及其他位置）下，则您需要管理员权限。如果它位于 AppData 下，则不需要。同样的图书馆调用，不同的结果。写入注册表也是如此 - HKLM 你需要管理员，HKCU 你不需要。写入事件日志通常是可以的，但创建事件源则不行。等等。这与您调用什么方法无关，更多的是与您传递给它的参数（例如路径）有关。
Thinking of it as "What library calls" is going to lead you down the wrong path. Think about anything that writes to a file. If that file is under Program Files (among other places), you need admin privs. If it's under AppData, you don't. Same library call, different outcomes. Ditto for writing to the registry - HKLM you need admin, HKCU you don't. Writing to Event Log is generally ok but creating your event source is not. And so on. It's not about what method you call, it's more about the params (eg path) you pass to it.
我不认为获取环境变量需要提升权限。至少我从来没有遇到过，真的有这样的情况吗？
I don't believe getting environment variables need elevating privledges. At least I've never run into it, are there really cases where that's true?
获取部分列表的一个地方是查看“本地组策略编辑器”，您可以在其中检查默认情况下仅分配给管理员的登录权限和特权。
One place to get a partial list is to look in the "Local Group Policy Editor" where you can check what Logon rights and Privileges are only assigned to administrators by default.
命名管道可能会导致问题。通常这不是问题，但随着 WCF 原生支持命名管道以进行 IPC 传输，命名管道的使用现在正在增加。
Named Pipes can cause issues. Normally this isn't an issue, but use of Named Pipes is now increasing with WCF supporting them natively for IPC transport.
.Net 框架中的任何内容都不需要管理权限。与用户级安全性有关的一切都由操作系统控制，是否需要管理员权限取决于操作系统配置。因此，框架无法确定是否需要提升。
您应该考虑的不是“.Net 框架中的哪些内容需要提升？”，而是“我的应用程序使用的哪些操作系统功能需要默认配置中的管理员提升”。正如 @Marcus 所说，“专为 Windows NT 4.0 设计”徽标要求是一个非常好的起点，可以确定您的应用程序如果设计为以普通用户身份运行，则应避免使用哪些操作系统功能。
Nothing in .Net framework requires administrative privileges. Everything that has to do with user-level security is controlled by the OS, and whether admin privileges are required is a matter of OS configuration. Thus, the framework can't make the determination whether it needs to require elevation.
You should be thinking not in terms of "What in the .Net framework requires elevation?", but in terms of "What OS features is my app using that require admin elevation in the default configuration". And as @Marcus said, "Designed for Windows NT 4.0" logo requirements is a very good starting point to determine which OS features your app should be avoiding if it's designed to run as regular user.
您可以使用应用程序验证程序 帮助您发现问题。 标准用户分析器也将为您提供帮助。
You can use the Luapriv checks from the Application Verifier to help you find issues. Also the Standard User Analyzer will help you.
如果我正确理解你的问题，Visual Studio 可以为你计算这个...
只需转到项目的属性，单击“安全”选项卡并选中“启用 ClickOnce 安全设置”复选框。选择“这是部分信任应用程序”单选按钮，然后单击“计算权限”按钮。
VS 将在您的应用程序所需的每个权限（例如 IO、注册表等）旁边放置一个复选标记...
If I'm understanding your question correctly, Visual Studio can calculate this for you...
Just go to your project's properties, click on Security tab and check "Enable ClickOnce Security Settings" checkbox. Select "This is a partial trust application" radio button and then click on "Calculate Permissions" button.
VS will place a checkmark next to each permission like IO, Registry, etc your application requires...
我严重怀疑是否有办法获取需要提升权限的 .NET 调用的完整列表。
顺便说一句，写入事件日志不需要提升，但是创建事件日志源确实需要提升。
找出代码的哪些部分有问题的最佳方法是在 Win7 上进行测试，看看哪些部分出了问题，虽然不优雅，但可以完成工作。如果您希望为此任务创建时间估计，那么您可能需要花一两天的时间来修改您的应用程序：在 Win7 上运行，查看哪些问题，记下它，评论/避免/禁用该部分，然后重复直到你认为你有足够的事情清单来解决。
I seriously doubt there is a way to get a complete list of .NET calls that require elevation of privileges.
BTW writing to the Event Log doesn't require elevation, however creating an Event Log source does require elevation.
The best way to find out which parts of your code have issues is by testing on Win7 and see what breaks, not elegant but does the job. If you are looking to create time estimates for this task, then you might have to spend a day or two hacking through your app: run on Win7, see what breaks, make note of it, comment/avoid/disable that section, and repeat until you think you have enough a of list of things to address.