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

每当我看到调用kernel32.dll或User32.dll的代码时，即使在MSDN上，代码片段也总是要求开发人员将任何所需的常量（例如WM_SETREDRAW = 11）硬编码到例程中。 由于这些常量永远不会改变，总是有一个标准的定义，为什么.net提供他们的地方？ 我觉得我们都最终创build我们自己的常量库和标准的Windows DLL调用，因为我们需要他们。 似乎这种重复的努力是浪费，容易出错。

也许我还没有看够，他们都在那里，如果有人可以提供他们的位置？

Windows安全性自定义loginvalidation

无法通过C＃连接到ManagementScope。 拒绝访问

在.NET中使用RegEx标准化Windowspath或URI

Windows客户端应用程序的login对话框

在同一个进程中，在AppDomain之间发送大的字节数组

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

可能有很多原因。 这里有一些猜测：

Win32 API太多容易出错。 许多Win32方法需要开发人员操作不安全的句柄（通常表示为IntPtr对象），这不是.NET的方式（例如，您应该使用FileStream而不是CreateFile / ReadFile / WriteFile / CloseHandle ）

在mscorlib中添加整个Win32 API没有意义，只有0.1％的开发人员实际使用它

微软喜欢开发人员编写托管代码

.Net框架被设计为平台不可知的。 这就是为什么你会找到Environment.NewLine的例子（ A string containing "rn" for non-Unix platforms,or a string containing "n" for Unix platforms. ）。 所以添加整个Win32 API是没有意义的。

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

关于pinvoke.net，我不会太依赖它。 我经常看到写得不好的方法声明会崩溃在x64系统（ int而不是IntPtr ，结构布局问题…）。 另一个例子： WriteFile方法声明是不一致的。 SafeHandle vs IntPtr …等。

这不仅仅是一个原因，还有很多。 我可以想到下面的任何一个在决定不包括他们的时候起作用：

即使是在框架集合上工作的团队也没有共享一组共同的声明，每个团队都写自己的

微软维护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头自动生成的。

.NET被设计成一个完整的生态系统。 放入Windows API是一种破解，而不包括常量是微软不鼓励它的方式。