当前位置：文江博客话题详情

是否有适用于 .NET 的完整 user32.dll 包装库？

发布于 2024-10-09 21:18:03 字数 333 浏览 5 评论 0原文

我目前正在通过 VB.NET 与 user32.dll 进行大量互操作。由于 user32.dll 不是在 .NET 级别而是在本机级别，因此我需要使用 Declare 语句来声明函数。虽然这很有效，但我还是一遍又一遍地声明它们。

我在谷歌上搜索，但我遇到的唯一有用的网站是 pinvoke.net。虽然它确实包含一定程度的信息，但有相当多的功能没有描述，或者在其文档中包含大量“TODO”部分。

因此，我想知道 .NET 是否有一个完整的 user32.dll 包装器。恐怕我没能找到任何东西，但也许我看得不正确。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

蓝海似她心 2024-10-16 21:18:03

.NET Framework 的 user32.dll 的完整包装是毫无意义的。 user32.dll 导出的绝大多数函数都具有由 .NET Framework 本机实现的相应函数。事实上，整个.NET Framework只是Windows API的包装器，包括user32.dll。

当有办法使用 .NET Framework 已提供的功能通过托管代码来执行此操作时，我建议您不要尝试从 user32.dll 中 P/Invoke 函数。在尝试自己重新发明轮子之前，请先检查 MSDN 或您选择的方便的 .NET 参考指南。

如果并且当您确定所需的特定函数没有具有本机等效函数时，那么也只有在那时您才应该考虑 P/Invoking Windows API。在这种情况下，由于您已经大大缩小了必须导入的函数数量，因此结合使用 MSDN 文档 pinvoke.net 和 Stack Overflow。我想说，自己编写这段代码的好处（现在您已经将所需的代码缩减到更易于管理的大小）是您实际上需要阅读文档并准确理解它是如何工作的。如果您依赖其他人编写的代码，则无法保证其编写正确、遵循最佳实践、实现任何错误处理，甚至无法保证您了解其工作原理以及如何使用它。

最后，我建议即使在 VB.NET 中，您也应该对 P/Invoking 函数使用标准 C# 语法，而不是 Declare。例如：

<DllImport("user32.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _
Private Shared Function AppendMenu(ByVal hMenu As IntPtr, ByVal uFlags As MenuFlags, ByVal uIDNewItem As Int32, ByVal lpNewItem As String) As Boolean
End Function

我认为这样做更可取的原因有几个：

Declare 语法试图保持与 VB 6 处理方式的向后兼容性。官方 .NET 方式（常用于 C#）是使用属性，并且由于您正在编写针对 .NET Framework 的全新代码，因此您应该强烈考虑使用官方语法。这里的另一个好处是，使用 C# 的人会更熟悉您的代码，并且他们将更能够帮助您进行声明。您在网上找到的示例很可能是以这种方式编写的，而不是使用旧版 VB 6 样式语法。
有时，Declare 语法会出现一些意外行为。例如，某些类型的编组方式与标准语法不同。对于更熟悉标准 .NET 行为的人来说，这可能会非常令人困惑。

另请参阅解决类似问题的此问题。

A complete wrapper for user32.dll for the .NET Framework would be pretty pointless. The vast majority of the functions exported by user32.dll have corresponding functions that are natively implemented by the .NET Framework. In fact, the entire .NET Framework is simply a wrapper around the Windows API, including user32.dll.

I recommend that you not try and P/Invoke functions from user32.dll when there is a way to do it through managed code using the functionality already provided by the .NET Framework. Check MSDN or a handy .NET reference guide of your choosing for that first, before trying to reinvent the wheel yourself.

If and when you determine that the specific function(s) you need does not have a native equivalent, then and only then should you consider P/Invoking the Windows API. In that case, since you've substantially narrowed down the amount of functions you have to import, it should be only a minimal amount of work to determine the function signature using a combination of the MSDN documentation, pinvoke.net, and Stack Overflow. I'd say the benefit of writing this code yourself (now that you've trimmed what you need down to a more manageable size) is that you're virtually required to read the documentation and understand exactly how it works. If you rely on code written by someone else, there's no guarantee that it's written correctly, that it follows best practices, that it implements any error handling, or even that you understand how it works and how to use it.

Finally, I recommend that even in VB.NET, you use the standard C# syntax for P/Invoking functions, rather than Declare. For example:

<DllImport("user32.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _
Private Shared Function AppendMenu(ByVal hMenu As IntPtr, ByVal uFlags As MenuFlags, ByVal uIDNewItem As Int32, ByVal lpNewItem As String) As Boolean
End Function

There are a couple of reasons why I think this is preferable:

The Declare syntax is an attempt to maintain backwards compatibility with the VB 6 way of doing things. The official .NET way (commonly used in C#) is using the <DllImport> attribute, and since you're writing brand new code targeting the .NET Framework, you should strongly consider using the official syntax. The other benefit here is that your code will be more familiar to people who use C#, and they'll be more able to help you with your declarations. The samples you find online are most likely to be written in this way, rather than using the legacy VB 6-style syntax.
Sometimes, the Declare syntax has some unexpected behavior. For example, certain types are marshalled differently than they are with the standard <DllImport> syntax. This can be quite confusing to people who are more familiar with the standard .NET behavior.

Also see this question addressing a similar issue.

回复收藏 0 原文