Why aren't windows constants included in .net?

Question

Every time I see code calling into say kernel32.dll or User32.dll the snippet always, even on MSDN, requires the developer to hard code any required constants (WM_SETREDRAW = 11 for example) into the routine. Since these constants never change by definition and have one standard definition always, why doesn't .net provide them somewhere? I feel like we all end up creating our own libraries of constants and standard Windows dll calls as we need them. It seems like this duplication of effort is wasteful and prone to error.

Perhaps I haven't looked hard enough and they are all in there somewhere, if so could someone please provide their location?

Answer 1

Only the .Net team can provide the actual answer I think, we can only make assumptions.

There probably are many reasons. Here are some guesses:

• Win32 API is too much error-prone. Lots of Win32 methods require the developer to manipulate unsafe handles (often represented as IntPtr objects), which is not the .Net-way of doing things (for instance you should use FileStream instead of CreateFile/ReadFile/WriteFile/CloseHandle)
• there is no point in adding the whole Win32 API in mscorlib in only 0.1% of developers actually use it
• Microsoft prefer developers write managed code
• The .Net framework is designed to be platform agnostic. That's why you'll find Environment.NewLine for example (A string containing "\r\n" for non-Unix platforms, or a string containing "\n" for Unix platforms.). So adding the whole Win32 API makes no sense.

Microsoft added some Windows-specific classes in the Microsoft.Win32 namespace , but it's very limited and those functions are essential (registry operations, filedialogs...).

Concerning pinvoke.net, I wouldn't rely too much on it. I often see poorly written method declarations that would crash on x64 systems (int instead of IntPtr, struct layout issues...). Another example: the WriteFile method declarations are inconsistent. SafeHandle vs IntPtr...etc.

Answer 2

There's not just a single reason, there are many. I can think of any of the following playing a role in the decision to not include them:

• not even the teams that worked on the framework assemblies shared a common set of pinvoke declarations, every team wrote their own
• Microsoft maintains only a single source for the winapi, the Windows SDK
• the maintainers of the SDK are a different group, not closely related to any of the groups that worked on .NET
• there's not just one winapi, it is heavily dependent on the target Windows version, something you specify when you build a C/C++ program. This goes heavily against the grain of .NET, it is version agnostic
• the winapi is enormous, nobody will be pleased with just a partial version
• the pinvoke declaration for a winapi function is often rewritten from its original form to make the usage much simpler. Particularly the case with the kind of functions that take opaque pointers, SendMessage() is the classic example
• .NET was designed to ensure you don't have to take a dependency on the winapi. You can anyway with your own pinvoke declarations to back-fill missing parts, but the guarantee that this will work on any Windows version that can run a .NET program is lost. Windows 98 and 2000 are still officially supported for 2.0

You can use the Pinvoke Interop Assistant tool. The declarations it provides are auto-generated from the Windows SDK headers.