为什么.net中不包含Windows常量？

Question

每当我看到代码调用kernel32.dll或User32.dll时，即使在MSDN上，代码片段也要求开发人员将任何所需的常量（例如WM_SETREDRAW = 11）硬编码到例程中。由于这些常量永远不会按定义更改并始终具有一个标准定义，为什么.net不能在某处提供它们？我觉得我们最终都会根据需要创建自己的常量库和标准的Windows dll调用。看起来这种重复工作是浪费的，容易出错。

也许我看起来不够努力而且他们都在某处，如果有的话，有人可以提供他们的位置吗？

Answer 1

只有.Net团队可以提供我认为的实际答案，我们只能做出假设。

可能有很多原因。以下是一些猜测：

• Win32 API太容易出错。许多Win32方法要求开发人员操纵不安全的句柄（通常表示为IntPtr个对象），这不是.Net的处理方式（例如，你应该使用FileStream而不是CreateFile / { {1}} / ReadFile / WriteFile）
• 在mscorlib中添加整个Win32 API毫无意义，只有0.1％的开发人员实际使用它
• Microsoft更喜欢开发人员编写托管代码
• .Net框架旨在与平台无关。这就是为什么你会找到例如Environment.NewLine（CloseHandle）的原因。因此添加整个Win32 API毫无意义。

Microsoft在Microsoft.Win32命名空间中添加了一些特定于Windows的类，但它非常有限，而且这些功能是必不可少的（注册表操作，文件管理...）。

关于pinvoke.net，我不会过分依赖它。我经常看到写得不好的方法声明会在x64系统上崩溃（A string containing "\r\n" for non-Unix platforms, or a string containing "\n" for Unix platforms.而不是int，结构布局问题......）。另一个例子：WriteFile方法声明不一致。 IntPtr vs SafeHandle ...等等。

Answer 2

不仅有一个原因，还有很多原因。我可以想到以下任何一个在不包括它们的决定中发挥作用：

• 甚至参与框架程序集的团队都没有共享一组普通的pinvoke声明，每个团队都写了自己的
• Microsoft只维护winapi的单一来源，Windows SDK
• SDK的维护者是一个不同的组，与任何在.NET上工作的组没有密切关系
• 不仅有一个winapi，它严重依赖于目标Windows版本，这是您在构建C / C ++程序时指定的内容。这严重违背了.NET，它与版本无关
• winapi是巨大的，没有人会对只有部分版本感到高兴
• winapi函数的pinvoke声明通常会从其原始形式重写，以使用法更加简单。特别是采用不透明指针的函数的情况，SendMessage（）是典型的例子
• .NET旨在确保您不必依赖winapi。无论如何，您可以使用自己的pinvoke声明来回填缺少的部分，但保证这将适用于任何可以运行.NET程序的Windows版本。 Windows 98和2000仍然正式支持2.0

您可以使用Pinvoke Interop Assistant工具。它提供的声明是从Windows SDK标头自动生成的。

Answer 3

.NET旨在成为一个完整的生态系统。放入Windows API是一种破解，不包括常量是微软劝阻它的方式。