Microsoft has a very nice Windows API wrapper included in .NET framework. It is stored in Microsoft.Win32.UnsafeNativeMethods , Microsoft.Win32.SafeNativeMethods and Microsoft.Win32.NativeMethods.Unfortunately they aren't accessible because they are declared as private. Is there a way of accessing them easily?
+1
A:
Most method definitions in those classes (if not all) are extern declarations with DllImport attributes that refer to functions in the Windows API through P/Invoke. In doesn't matter where these declarations reside. You can create your own class named UnsafeNativeMethods or SafeNativeMethods and put declarations referring to the same Windows API functions in there. You'll find the signatures of many Windows API functions for C# on pinvoke.net.
dtb
2010-01-31 02:28:59
That takes ages. I want to have access to all the functions in one class.
Nick Brooks
2010-01-31 02:31:05
As @SLaks wrote, many API functions are already exposed as managed classes in the .NET Framework, e.g., registry access, windows, GDI. It usually doesn't take so long to copy a couple of method signatures from a website into a C# file. If you're heavily depending on the Windows API and make no use of the .NET Framework, why not use a more appropriate programming language?
dtb
2010-01-31 02:34:57
Creating a nice UI in C++ is a headache. (IMHO)
Nick Brooks
2010-01-31 02:38:15
+1
A:
Most of the functionality contained in these classes is exposed by the .Net framework itself; you should search (or ask here) before making API calls.
To answer your question, no.
The best you can do is to copy them from Reflector or the reference source.
SLaks
2010-01-31 02:29:04
.NET Framework is available in open source if it is used as a read only reference
Nick Brooks
2010-01-31 02:34:29
It's not copyright violation when there's only one correct way to do it.
Josh Einstein
2010-01-31 02:34:47
@Nick Brooks: "Open Source" is a well defined term. And it does not apply to the license to look at source code for personal or academic purposes (under which the reference source is licensed).
dtb
2010-01-31 02:36:20
@Josh Einstein: It's not the only one correct way to do it. The correct way to do it is to look up the function definitions in the Windows SDK documentation and translate them to P/Invoke declarations, as done on pinvoke.net
dtb
2010-01-31 02:37:14
I guarantee MS doesn't give a rats ass about people using reflector to copy DllImport attributes and signatures.
Josh Einstein
2010-01-31 02:39:54
+1
A:
For what it's worth I always thought there should have been a kernel32.interop.dll etc with the static methods already DllImport'ed. But I've resorted to creating my own on an as-needed basis. Over the years I've found I rarely use more than a handful of them but it's such a pain in the ass when I need an API that I haven't imported yet.
Josh Einstein
2010-01-31 02:33:27
A:
The reason could be the security impact of SuppressUnmanagedCodeSecurityAttribute. Check Move P/Invokes to NativeMethods class
Sheng Jiang 蒋晟
2010-01-31 04:48:11