C:/ProgramFiles/MicrosoftVisual Studio .NET/ FrameworkSDK/Samples/ Technologies/ Interop/PlatformInvoke/ WinAPIs/CS目录下有大量的调用API的例子。
一、调用格式
using System.Runtime.InteropServices; //引用此名称空间，简化后面的代码
//使用DllImportAttribute特性来引入api函数，注意声明的是空方法，即方法体为空。
[DllImport("user32.dll")]
public static extern ReturnType FunctionName(type arg1,type arg2,...);
//调用时与调用其他方法并无区别
可以使用字段进一步说明特性，用逗号隔开，如：
[ DllImport( "kernel32", EntryPoint="GetVersionEx" )]
DllImportAttribute特性的公共字段如下：
1、CallingConvention
指示向非托管实现传递方法参数时所用的 CallingConvention
值。
指示向非托管实现传递方法参数时所用的 CallingConvention
值。
CallingConvention.Cdecl : 调用方清理堆栈。它使您能够调用具有 varargs
的函数。
的函数。
CallingConvention.StdCall : 被调用方清理堆栈。它是从托管代码调用非托管函数的默认约定。
2、CharSet
控制调用函数的名称版本及指示如何向方法封送 String
参数。
控制调用函数的名称版本及指示如何向方法封送 String
参数。
此字段被设置为 CharSet
值之一。如果 CharSet
字段设置为 Unicode，则所有字符串参数在传递到非托管实现之前都转换成 Unicode
字符。这还导致向 DLL EntryPoint
的名称中追加字母“W”。如果此字段设置为 Ansi，则字符串将转换成 ANSI
字符串，同时向 DLL EntryPoint
的名称中追加字母“A”。大多数 Win32 API
使用这种追加“W”或“A”的约定。如果 CharSet
设置为 Auto，则这种转换就是与平台有关的（在 Windows NT
上为 Unicode，在 Windows 98
上为 Ansi）。CharSet
的默认值为 Ansi。CharSet
字段也用于确定将从指定的 DLL
导入哪个版本的函数。CharSet.Ansi
和 CharSet.Unicode
的名称匹配规则大不相同。对于 Ansi
来说，如果将 EntryPoint
设置为“MyMethod”且它存在的话，则返回“MyMethod”。如果
DLL 中没有“MyMethod”，但存在“MyMethodA”，则返回“MyMethodA”。对于
Unicode 来说则正好相反。如果将 EntryPoint
设置为“MyMethod”且它存在的话，则返回“MyMethodW”。如果 DLL
中不存在“MyMethodW”，但存在“MyMethod”，则返回“MyMethod”。如果使用的是
Auto，则匹配规则与平台有关（在 Windows NT
上为 Unicode，在 Windows 98
上为 Ansi）。如果 ExactSpelling
设置为 true，则只有当 DLL
中存在“MyMethod”时才返回“MyMethod”。
值之一。如果 CharSet
字段设置为 Unicode，则所有字符串参数在传递到非托管实现之前都转换成 Unicode
字符。这还导致向 DLL EntryPoint
的名称中追加字母“W”。如果此字段设置为 Ansi，则字符串将转换成 ANSI
字符串，同时向 DLL EntryPoint
的名称中追加字母“A”。大多数 Win32 API
使用这种追加“W”或“A”的约定。如果 CharSet
设置为 Auto，则这种转换就是与平台有关的（在 Windows NT
上为 Unicode，在 Windows 98
上为 Ansi）。CharSet
的默认值为 Ansi。CharSet
字段也用于确定将从指定的 DLL
导入哪个版本的函数。CharSet.Ansi
和 CharSet.Unicode
的名称匹配规则大不相同。对于 Ansi
来说，如果将 EntryPoint
设置为“MyMethod”且它存在的话，则返回“MyMethod”。如果
DLL 中没有“MyMethod”，但存在“MyMethodA”，则返回“MyMethodA”。对于
Unicode 来说则正好相反。如果将 EntryPoint
设置为“MyMethod”且它存在的话，则返回“MyMethodW”。如果 DLL
中不存在“MyMethodW”，但存在“MyMethod”，则返回“MyMethod”。如果使用的是
Auto，则匹配规则与平台有关（在 Windows NT
上为 Unicode，在 Windows 98
上为 Ansi）。如果 ExactSpelling
设置为 true，则只有当 DLL
中存在“MyMethod”时才返回“MyMethod”。
3、EntryPoint
指示要调用的 DLL
入口点的名称或序号。
指示要调用的 DLL
入口点的名称或序号。
如果你的方法名不想与api函数同名的话，一定要指定此参数,例如：
[DllImport("user32.dll",CharSet="CharSet.Auto",EntryPoint="MessageBox")]
public static extern int MsgBox(IntPtr hWnd,string txt,string caption, int type);
4、ExactSpelling
指示是否应修改非托管 DLL
中的入口点的名称，以与 CharSet
字段中指定的 CharSet
值相对应。如果为 true，则当 DllImportAttribute.CharSet
字段设置为 CharSet
的 Ansi
值时，向方法名称中追加字母 A，当 DllImportAttribute.CharSet
字段设置为 CharSet
的 Unicode
值时，向方法的名称中追加字母 W。此字段的默认值是 false。
指示是否应修改非托管 DLL
中的入口点的名称，以与 CharSet
字段中指定的 CharSet
值相对应。如果为 true，则当 DllImportAttribute.CharSet
字段设置为 CharSet
的 Ansi
值时，向方法名称中追加字母 A，当 DllImportAttribute.CharSet
字段设置为 CharSet
的 Unicode
值时，向方法的名称中追加字母 W。此字段的默认值是 false。
5、PreserveSig
指示托管方法签名不应转换成返回 HRESULT、并且可能有一个对应于返回值的附加 [out, retval]
参数的非托管签名。
指示托管方法签名不应转换成返回 HRESULT、并且可能有一个对应于返回值的附加 [out, retval]
参数的非托管签名。
6、SetLastError
指示被调用方在从属性化方法返回之前将调用 Win32 API SetLastError。 true
指示调用方将调用 SetLastError，默认为 false。运行时封送拆收器将调用 GetLastError
并缓存返回的值，以防其被其他 API
调用重写。用户可通过调用 GetLastWin32Error
来检索错误代码。
指示被调用方在从属性化方法返回之前将调用 Win32 API SetLastError。 true
指示调用方将调用 SetLastError，默认为 false。运行时封送拆收器将调用 GetLastError
并缓存返回的值，以防其被其他 API
调用重写。用户可通过调用 GetLastWin32Error
来检索错误代码。
二、参数类型：
1、数值型直接用对应的就可。（DWORD -> int , WORD -> Int16）
2、API中字符串指针类型 -> .net中string
3、API中句柄 (dWord) -> .net中IntPtr
4、API中结构 -> .net中结构或者类。注意这种情况下，要先用StructLayout特性限定声明结构或类
公共语言运行库利用StructLayoutAttribute控制类或结构的数据字段在托管内存中的物理布局,即类或结构需要按某种方式排列。如果要将类传递给需要指定布局的非托管代码，则显式控制类布局是重要的。它的构造函数中用LayoutKind值初始化
StructLayoutAttribute 类的新实例。 LayoutKind.Sequential
用于强制将成员按其出现的顺序进行顺序布局。
StructLayoutAttribute 类的新实例。 LayoutKind.Sequential
用于强制将成员按其出现的顺序进行顺序布局。
LayoutKind.Explicit 用于控制每个数据成员的精确位置。利用 Explicit，每个成员必须使用
FieldOffsetAttribute 指示此字段在类型中的位置。如：
FieldOffsetAttribute 指示此字段在类型中的位置。如：
[StructLayout(LayoutKind.Explicit, Size=16, CharSet=CharSet.Ansi)]
public class MySystemTime
{
[FieldOffset(0)]public ushort wYear;
[FieldOffset(2)]public ushort wMonth;
[FieldOffset(4)]public ushort wDayOfWeek;
[FieldOffset(6)]public ushort wDay;
[FieldOffset(8)]public ushort wHour;
[FieldOffset(10)]public ushort wMinute;
[FieldOffset(12)]public ushort wSecond;
[FieldOffset(14)]public ushort wMilliseconds;
}
下面是针对API中OSVERSIONINFO结构，在.net中定义对应类或结构的例子：
/**********************************************
* API中定义原结构声明
* OSVERSIONINFOA STRUCT
* dwOSVersionInfoSize DWORD ?
* dwMajorVersion DWORD ?
* dwMinorVersion DWORD ?
* dwBuildNumber DWORD ?
* dwPlatformId DWORD ?
* szCSDVersion BYTE 128 dup (?)
* OSVERSIONINFOA ENDS
*
* OSVERSIONINFO equ <OSVERSIONINFOA>
*********************************************/
//.net中声明为类
[ StructLayout( LayoutKind.Sequential )]
public class OSVersionInfo
{
public int OSVersionInfoSize;
public int majorVersion;
public int minorVersion;
public int buildNumber;
public int platformId;
[ MarshalAs( UnmanagedType.ByValTStr, SizeConst=128 )]
public String versionString;
}
//或者
//.net中声明为结构
[ StructLayout( LayoutKind.Sequential )]
public struct OSVersionInfo2
{
public int OSVersionInfoSize;
public int majorVersion;
public int minorVersion;
public int buildNumber;
public int platformId;
[ MarshalAs( UnmanagedType.ByValTStr, SizeConst=128 )]
public String versionString;
}
此例中用到MashalAs特性，它用于描述字段、方法或参数的封送处理格式。用它作为参数前缀并指定目标需要的数据类型。例如，以下代码将两个参数作为数据类型长指针封送给 Windows API
函数的字符串 (LPStr)：
函数的字符串 (LPStr)：
[MarshalAs(UnmanagedType.LPStr)]
String existingfile;
[MarshalAs(UnmanagedType.LPStr)]
String newfile;
注意结构作为参数时候，一般前面要加上ref修饰符，否则会出现错误：对象的引用没有指定对象的实例。
[ DllImport( "kernel32", EntryPoint="GetVersionEx" )]
public static extern bool GetVersionEx2( ref OSVersionInfo2 osvi );
三、如何保证使用托管对象的平台调用成功？
如果在调用平台 invoke
后的任何位置都未引用托管对象，则垃圾回收器可能将完成该托管对象。这将释放资源并使句柄无效，从而导致平台invoke
调用失败。用 HandleRef
包装句柄可保证在平台 invoke
调用完成前，不对托管对象进行垃圾回收。
后的任何位置都未引用托管对象，则垃圾回收器可能将完成该托管对象。这将释放资源并使句柄无效，从而导致平台invoke
调用失败。用 HandleRef
包装句柄可保证在平台 invoke
调用完成前，不对托管对象进行垃圾回收。
例如下面：
FileStream fs = new FileStream( "a.txt", FileMode.Open );
StringBuilder buffer = new StringBuilder( 5 );
int read = 0;
ReadFile(fs.Handle, buffer, 5, out read, 0 ); //调用Win API中的ReadFile函数
由于fs是托管对象，所以有可能在平台调用还未完成时候被垃圾回收站回收。将文件流的句柄用HandleRef包装后，就能避免被垃圾站回收:
[ DllImport( "Kernel32.dll" )]
public static extern bool ReadFile(
HandleRef hndRef,
StringBuilder buffer,
int numberOfBytesToRead,
out int numberOfBytesRead,
ref Overlapped flag );
......
......
FileStream fs = new FileStream( "HandleRef.txt", FileMode.Open );
HandleRef hr = new HandleRef( fs, fs.Handle );
StringBuilder buffer = new StringBuilder( 5 );
int read = 0;
// platform invoke will hold reference to HandleRef until call ends
ReadFile( hr, buffer, 5, out read, 0 );
我在自己最近的编程中注意到一个趋势，正是这个趋势才引出本月的专栏主题。最近，我在基于 Microsoft? .NET Framework
的应用程序中完成了大量的 Win32? Interop。我并不是要说我的应用程序充满了自定义的 interop
代码，但有时我会在 .NET Framework
类库中碰到一些次要但又繁絮、不充分的内容，通过调用该 Windows? API，可以快速减少这样的麻烦。
的应用程序中完成了大量的 Win32? Interop。我并不是要说我的应用程序充满了自定义的 interop
代码，但有时我会在 .NET Framework
类库中碰到一些次要但又繁絮、不充分的内容，通过调用该 Windows? API，可以快速减少这样的麻烦。
因此我认为，.NET Framework 1.0
或 1.1
版类库中存在任何 Windows
所没有的功能限制都不足为怪。毕竟，32
位的 Windows（不管何种版本）是一个成熟的操作系统，为广大客户服务了十多年。相比之下，.NET Framework
却是一个新事物。
或 1.1
版类库中存在任何 Windows
所没有的功能限制都不足为怪。毕竟，32
位的 Windows（不管何种版本）是一个成熟的操作系统，为广大客户服务了十多年。相比之下，.NET Framework
却是一个新事物。
随着越来越多的开发人员将生产应用程序转到托管代码，开发人员更频繁地研究底层操作系统以图找出一些关键功能显得很自然—至少目前是如此。
值得庆幸的是，公共语言运行库 (CLR)
的 interop
功能（称为平台调用 (P/Invoke)）非常完善。在本专栏中，我将重点介绍如何实际使用 P/Invoke
来调用 Windows API
函数。当指 CLR
的 COM Interop
功能时，P/Invoke
当作名词使用；当指该功能的使用时，则将其当作动词使用。我并不打算直接介绍 COM Interop，因为它比 P/Invoke
具有更好的可访问性，却更加复杂，这有点自相矛盾，这使得将 COM Interop
作为专栏主题来讨论不太简明扼要。
的 interop
功能（称为平台调用 (P/Invoke)）非常完善。在本专栏中，我将重点介绍如何实际使用 P/Invoke
来调用 Windows API
函数。当指 CLR
的 COM Interop
功能时，P/Invoke
当作名词使用；当指该功能的使用时，则将其当作动词使用。我并不打算直接介绍 COM Interop，因为它比 P/Invoke
具有更好的可访问性，却更加复杂，这有点自相矛盾，这使得将 COM Interop
作为专栏主题来讨论不太简明扼要。
走进 P/Invoke
首先从考察一个简单的 P/Invoke
示例开始。让我们看一看如何调用 Win32 MessageBeep
函数，它的非托管声明如以下代码所示：
示例开始。让我们看一看如何调用 Win32 MessageBeep
函数，它的非托管声明如以下代码所示：
BOOL MessageBeep(
UINT uType // beep type
);
为了调用 MessageBeep，您需要在 C#
中将以下代码添加到一个类或结构定义中：
中将以下代码添加到一个类或结构定义中：
[DllImport("User32.dll")]
static extern Boolean MessageBeep(UInt32 beepType);
令人惊讶的是，只需要这段代码就可以使托管代码调用非托管的 MessageBeep API。它不是一个方法调用，而是一个外部方法定义。（另外，它接近于一个来自 C
而 C#
允许的直接端口，因此以它为起点来介绍一些概念是有帮助的。）来自托管代码的可能调用如下所示：
而 C#
允许的直接端口，因此以它为起点来介绍一些概念是有帮助的。）来自托管代码的可能调用如下所示：
MessageBeep(0);
请注意，现在 MessageBeep
方法被声明为 static。这是 P/Invoke
方法所要求的，因为在该 Windows API
中没有一致的实例概念。接下来，还要注意该方法被标记为 extern。这是提示编译器该方法是通过一个从 DLL
导出的函数实现的，因此不需要提供方法体。
方法被声明为 static。这是 P/Invoke
方法所要求的，因为在该 Windows API
中没有一致的实例概念。接下来，还要注意该方法被标记为 extern。这是提示编译器该方法是通过一个从 DLL
导出的函数实现的，因此不需要提供方法体。
说到缺少方法体，您是否注意到 MessageBeep
声明并没有包含一个方法体？与大多数算法由中间语言 (IL)
指令组成的托管方法不同，P/Invoke
方法只是元数据，实时 (JIT)
编译器在运行时通过它将托管代码与非托管的 DLL
函数连接起来。执行这种到非托管世界的连接所需的一个重要信息就是导出非托管方法的 DLL
的名称。这一信息是由 MessageBeep
方法声明之前的 DllImport
自定义属性提供的。在本例中，可以看到，MessageBeep
非托管 API
是由 Windows
中的 User32.dll
导出的。
声明并没有包含一个方法体？与大多数算法由中间语言 (IL)
指令组成的托管方法不同，P/Invoke
方法只是元数据，实时 (JIT)
编译器在运行时通过它将托管代码与非托管的 DLL
函数连接起来。执行这种到非托管世界的连接所需的一个重要信息就是导出非托管方法的 DLL
的名称。这一信息是由 MessageBeep
方法声明之前的 DllImport
自定义属性提供的。在本例中，可以看到，MessageBeep
非托管 API
是由 Windows
中的 User32.dll
导出的。
到现在为止，关于调用 MessageBeep
就剩两个话题没有介绍，请回顾一下，调用的代码与以下所示代码片段非常相似：
就剩两个话题没有介绍，请回顾一下，调用的代码与以下所示代码片段非常相似：
[DllImport("User32.dll")]
static extern Boolean MessageBeep(UInt32 beepType);
最后这两个话题是与数据封送处理 (data marshaling)
和从托管代码到非托管函数的实际方法调用有关的话题。调用非托管 MessageBeep
函数可以由找到作用域内的extern MessageBeep
声明的任何托管代码执行。该调用类似于任何其他对静态方法的调用。它与其他任何托管方法调用的共同之处在于带来了数据封送处理的需要。
和从托管代码到非托管函数的实际方法调用有关的话题。调用非托管 MessageBeep
函数可以由找到作用域内的extern MessageBeep
声明的任何托管代码执行。该调用类似于任何其他对静态方法的调用。它与其他任何托管方法调用的共同之处在于带来了数据封送处理的需要。
C# 的规则之一是它的调用语法只能访问 CLR
数据类型，例如 System.UInt32
和 System.Boolean。C#
显然不识别 Windows API
中使用的基于 C
的数据类型（例如 UINT
和 BOOL），这些类型只是 C
语言类型的类型定义而已。所以当 Windows API
函数 MessageBeep
按以下方式编写时
数据类型，例如 System.UInt32
和 System.Boolean。C#
显然不识别 Windows API
中使用的基于 C
的数据类型（例如 UINT
和 BOOL），这些类型只是 C
语言类型的类型定义而已。所以当 Windows API
函数 MessageBeep
按以下方式编写时
BOOL MessageBeep( UINT uType )
外部方法就必须使用 CLR
类型来定义，如您在前面的代码片段中所看到的。需要使用与基础 API
函数类型不同但与之兼容的 CLR
类型是 P/Invoke
较难使用的一个方面。因此，在本专栏的后面我将用完整的章节来介绍数据封送处理。
类型来定义，如您在前面的代码片段中所看到的。需要使用与基础 API
函数类型不同但与之兼容的 CLR
类型是 P/Invoke
较难使用的一个方面。因此，在本专栏的后面我将用完整的章节来介绍数据封送处理。
样式
在 C# 中对 Windows API
进行 P/Invoke
调用是很简单的。但如果类库拒绝使您的应用程序发出嘟声，应该想方设法调用 Windows
使它进行这项工作，是吗？
进行 P/Invoke
调用是很简单的。但如果类库拒绝使您的应用程序发出嘟声，应该想方设法调用 Windows
使它进行这项工作，是吗？
是的。但是与选择的方法有关，而且关系甚大！通常，如果类库提供某种途径来实现您的意图，则最好使用 API
而不要直接调用非托管代码，因为 CLR
类型和 Win32
之间在样式上有很大的不同。我可以将关于这个问题的建议归结为一句话。当您进行 P/Invoke
时，不要使应用程序逻辑直接属于任何外部方法或其中的构件。如果您遵循这个小规则，从长远看经常会省去许多的麻烦。
而不要直接调用非托管代码，因为 CLR
类型和 Win32
之间在样式上有很大的不同。我可以将关于这个问题的建议归结为一句话。当您进行 P/Invoke
时，不要使应用程序逻辑直接属于任何外部方法或其中的构件。如果您遵循这个小规则，从长远看经常会省去许多的麻烦。
图 1 中的代码显示了我所讨论的 MessageBeep
外部方法的最少附加代码。图 1
中并没有任何显著的变化，而只是对无包装的外部方法进行一些普通的改进，这可以使工作更加轻松一些。从顶部开始，您会注意到一个名为 Sound
的完整类型，它专用于 MessageBeep。如果我需要使用 Windows API
函数 PlaySound
来添加对播放波形的支持，则可以重用 Sound
类型。然而，我不会因公开单个公共静态方法的类型而生气。毕竟这只是应用程序代码而已。还应该注意到，Sound
是密封的，并定义了一个空的私有构造函数。这些只是一些细节，目的是使用户不会错误地从 Sound
派生类或者创建它的实例。
外部方法的最少附加代码。图 1
中并没有任何显著的变化，而只是对无包装的外部方法进行一些普通的改进，这可以使工作更加轻松一些。从顶部开始，您会注意到一个名为 Sound
的完整类型，它专用于 MessageBeep。如果我需要使用 Windows API
函数 PlaySound
来添加对播放波形的支持，则可以重用 Sound
类型。然而，我不会因公开单个公共静态方法的类型而生气。毕竟这只是应用程序代码而已。还应该注意到，Sound
是密封的，并定义了一个空的私有构造函数。这些只是一些细节，目的是使用户不会错误地从 Sound
派生类或者创建它的实例。
图 1 中的代码的下一个特征是，P/Invoke
出现位置的实际外部方法是 Sound
的私有方法。这个方法只是由公共 MessageBeep
方法间接公开，后者接受 BeepTypes
类型的参数。这个间接的额外层是一个很关键的细节，它提供了以下好处。首先，应该在类库中引入一个未来的 beep
托管方法，可以重复地通过公共 MessageBeep
方法来使用托管 API，而不必更改应用程序中的其余代码。
出现位置的实际外部方法是 Sound
的私有方法。这个方法只是由公共 MessageBeep
方法间接公开，后者接受 BeepTypes
类型的参数。这个间接的额外层是一个很关键的细节，它提供了以下好处。首先，应该在类库中引入一个未来的 beep
托管方法，可以重复地通过公共 MessageBeep
方法来使用托管 API，而不必更改应用程序中的其余代码。
该包装方法的第二个好处是：当您进行 P/Invoke
调用时，您放弃了免受访问冲突和其他低级破坏的权利，这通常是由 CLR
提供的。缓冲方法可以保护您的应用程序的其余部分免受访问冲突及类似问题的影响（即使它不做任何事而只是传递参数）。该缓冲方法将由 P/Invoke
调用引入的任何潜在的错误本地化。
调用时，您放弃了免受访问冲突和其他低级破坏的权利，这通常是由 CLR
提供的。缓冲方法可以保护您的应用程序的其余部分免受访问冲突及类似问题的影响（即使它不做任何事而只是传递参数）。该缓冲方法将由 P/Invoke
调用引入的任何潜在的错误本地化。
将私有外部方法隐藏在公共包装后面的第三同时也是最后的一个好处是，提供了向该方法添加一些最小的 CLR
样式的机会。例如，在图 1
中，我将 Windows API
函数返回的 Boolean
失败转换成更像 CLR
的异常。我还定义了一个名为 BeepTypes
的枚举类型，它的成员对应于同该 Windows API
一起使用的定义值。由于 C#
不支持定义，因此可以使用托管枚举类型来避免幻数向整个应用程序代码扩散。
样式的机会。例如，在图 1
中，我将 Windows API
函数返回的 Boolean
失败转换成更像 CLR
的异常。我还定义了一个名为 BeepTypes
的枚举类型，它的成员对应于同该 Windows API
一起使用的定义值。由于 C#
不支持定义，因此可以使用托管枚举类型来避免幻数向整个应用程序代码扩散。
包装方法的最后一个好处对于简单的 Windows API
函数（如 MessageBeep）诚然是微不足道的。但是当您开始调用更复杂的非托管函数时，您会发现，手动将 Windows API
样式转换成对 CLR
更加友好的方法所带来的好处会越来越多。越是打算在整个应用程序中重用 interop
功能，越是应该认真地考虑包装的设计。同时我认为，在非面向对象的静态包装方法中使用对 CLR
友好的参数也并非不可以。
函数（如 MessageBeep）诚然是微不足道的。但是当您开始调用更复杂的非托管函数时，您会发现，手动将 Windows API
样式转换成对 CLR
更加友好的方法所带来的好处会越来越多。越是打算在整个应用程序中重用 interop
功能，越是应该认真地考虑包装的设计。同时我认为，在非面向对象的静态包装方法中使用对 CLR
友好的参数也并非不可以。
DLL Import 属性
现在是更深入地进行探讨的时候了。在对托管代码进行 P/Invoke
调用时，DllImportAttribute
类型扮演着重要的角色。DllImportAttribute
的主要作用是给 CLR
指示哪个 DLL
导出您想要调用的函数。相关 DLL
的名称被作为一个构造函数参数传递给 DllImportAttribute。
调用时，DllImportAttribute
类型扮演着重要的角色。DllImportAttribute
的主要作用是给 CLR
指示哪个 DLL
导出您想要调用的函数。相关 DLL
的名称被作为一个构造函数参数传递给 DllImportAttribute。
如果您无法肯定哪个 DLL
定义了您要使用的 Windows API
函数，Platform SDK
文档将为您提供最好的帮助资源。在 Windows API
函数主题文字临近结尾的位置，SDK
文档指定了 C
应用程序要使用该函数必须链接的 .lib
文件。在几乎所有的情况下，该 .lib
文件具有与定义该函数的系统 DLL
文件相同的名称。例如，如果该函数需要 C
应用程序链接到 Kernel32.lib，则该函数就定义在 Kernel32.dll
中。您可以在 MessageBeep
中找到有关 MessageBeep
的 Platform SDK
文档主题。在该主题结尾处，您会注意到它指出库文件是 User32.lib；这表明 MessageBeep
是从 User32.dll
中导出的。
定义了您要使用的 Windows API
函数，Platform SDK
文档将为您提供最好的帮助资源。在 Windows API
函数主题文字临近结尾的位置，SDK
文档指定了 C
应用程序要使用该函数必须链接的 .lib
文件。在几乎所有的情况下，该 .lib
文件具有与定义该函数的系统 DLL
文件相同的名称。例如，如果该函数需要 C
应用程序链接到 Kernel32.lib，则该函数就定义在 Kernel32.dll
中。您可以在 MessageBeep
中找到有关 MessageBeep
的 Platform SDK
文档主题。在该主题结尾处，您会注意到它指出库文件是 User32.lib；这表明 MessageBeep
是从 User32.dll
中导出的。
可选的 DllImportAttribute
属性
属性
除了指出宿主 DLL
外，DllImportAttribute
还包含了一些可选属性，其中四个特别有趣：EntryPoint、CharSet、SetLastError
和 CallingConvention。
外，DllImportAttribute
还包含了一些可选属性，其中四个特别有趣：EntryPoint、CharSet、SetLastError
和 CallingConvention。
EntryPoint 在不希望外部托管方法具有与 DLL
导出相同的名称的情况下，可以设置该属性来指示导出的 DLL
函数的入口点名称。当您定义两个调用相同非托管函数的外部方法时，这特别有用。另外，在 Windows
中还可以通过它们的序号值绑定到导出的 DLL
函数。如果您需要这样做，则诸如“#1”或“#129”的 EntryPoint
值指示 DLL
中非托管函数的序号值而不是函数名。
导出相同的名称的情况下，可以设置该属性来指示导出的 DLL
函数的入口点名称。当您定义两个调用相同非托管函数的外部方法时，这特别有用。另外，在 Windows
中还可以通过它们的序号值绑定到导出的 DLL
函数。如果您需要这样做，则诸如“#1”或“#129”的 EntryPoint
值指示 DLL
中非托管函数的序号值而不是函数名。
CharSet 对于字符集，并非所有版本的 Windows
都是同样创建的。Windows 9x
系列产品缺少重要的 Unicode
支持，而 Windows NT
和 Windows CE
系列则一开始就使用 Unicode。在这些操作系统上运行的 CLR
将Unicode
用于 String 和 Char
数据的内部表示。但也不必担心—当调用 Windows 9x API
函数时，CLR
会自动进行必要的转换，将其从 Unicode转换为 ANSI。
都是同样创建的。Windows 9x
系列产品缺少重要的 Unicode
支持，而 Windows NT
和 Windows CE
系列则一开始就使用 Unicode。在这些操作系统上运行的 CLR
将Unicode
用于 String 和 Char
数据的内部表示。但也不必担心—当调用 Windows 9x API
函数时，CLR
会自动进行必要的转换，将其从 Unicode转换为 ANSI。
如果 DLL
函数不以任何方式处理文本，则可以忽略 DllImportAttribute
的 CharSet
属性。然而，当 Char
或 String 数据是等式的一部分时，应该将 CharSet
属性设置为 CharSet.Auto。这样可以使 CLR
根据宿主 OS
使用适当的字符集。如果没有显式地设置 CharSet
属性，则其默认值为 CharSet.Ansi。这个默认值是有缺点的，因为对于在 Windows 2000、Windows
XP 和 Windows NT?
上进行的 interop
调用，它会消极地影响文本参数封送处理的性能。
函数不以任何方式处理文本，则可以忽略 DllImportAttribute
的 CharSet
属性。然而，当 Char
或 String 数据是等式的一部分时，应该将 CharSet
属性设置为 CharSet.Auto。这样可以使 CLR
根据宿主 OS
使用适当的字符集。如果没有显式地设置 CharSet
属性，则其默认值为 CharSet.Ansi。这个默认值是有缺点的，因为对于在 Windows 2000、Windows
XP 和 Windows NT?
上进行的 interop
调用，它会消极地影响文本参数封送处理的性能。
应该显式地选择 CharSet.Ansi
或 CharSet.Unicode
的 CharSet
值而不是使用 CharSet.Auto
的唯一情况是：您显式地指定了一个导出函数，而该函数特定于这两种 Win32 OS
中的某一种。ReadDirectoryChangesW API
函数就是这样的一个例子，它只存在于基于 Windows NT
的操作系统中，并且只支持 Unicode；在这种情况下，您应该显式地使用 CharSet.Unicode。
或 CharSet.Unicode
的 CharSet
值而不是使用 CharSet.Auto
的唯一情况是：您显式地指定了一个导出函数，而该函数特定于这两种 Win32 OS
中的某一种。ReadDirectoryChangesW API
函数就是这样的一个例子，它只存在于基于 Windows NT
的操作系统中，并且只支持 Unicode；在这种情况下，您应该显式地使用 CharSet.Unicode。
有时，Windows API
是否有字符集关系并不明显。一种决不会有错的确认方法是在 Platform SDK
中检查该函数的 C
语言头文件。（如果您无法肯定要看哪个头文件，则可以查看 Platform SDK
文档中列出的每个 API
函数的头文件。）如果您发现该 API
函数确实定义为一个映射到以 A
或 W
结尾的函数名的宏，则字符集与您尝试调用的函数有关系。Windows API
函数的一个例子是在 WinUser.h
中声明的 GetMessage API，您也许会惊讶地发现它有 A
和 W
两种版本。
是否有字符集关系并不明显。一种决不会有错的确认方法是在 Platform SDK
中检查该函数的 C
语言头文件。（如果您无法肯定要看哪个头文件，则可以查看 Platform SDK
文档中列出的每个 API
函数的头文件。）如果您发现该 API
函数确实定义为一个映射到以 A
或 W
结尾的函数名的宏，则字符集与您尝试调用的函数有关系。Windows API
函数的一个例子是在 WinUser.h
中声明的 GetMessage API，您也许会惊讶地发现它有 A
和 W
两种版本。
SetLastError 错误处理非常重要，但在编程时经常被遗忘。当您进行 P/Invoke
调用时，也会面临其他的挑战—处理托管代码中 Windows API
错误处理和异常之间的区别。我可以给您一点建议。
调用时，也会面临其他的挑战—处理托管代码中 Windows API
错误处理和异常之间的区别。我可以给您一点建议。
如果您正在使用 P/Invoke
调用 Windows API
函数，而对于该函数，您使用 GetLastError
来查找扩展的错误信息，则应该在外部方法的 DllImportAttribute
中将 SetLastError
属性设置为 true。这适用于大多数外部方法。
调用 Windows API
函数，而对于该函数，您使用 GetLastError
来查找扩展的错误信息，则应该在外部方法的 DllImportAttribute
中将 SetLastError
属性设置为 true。这适用于大多数外部方法。
这会导致 CLR
在每次调用外部方法之后缓存由 API
函数设置的错误。然后，在包装方法中，可以通过调用类库的 System.Runtime.InteropServices.Marshal
类型中定义的 Marshal.GetLastWin32Error
方法来获取缓存的错误值。我的建议是检查这些期望来自 API
函数的错误值，并为这些值引发一个可感知的异常。对于其他所有失败情况（包括根本就没意料到的失败情况），则引发在 System.ComponentModel
命名空间中定义的 Win32Exception，并将 Marshal.GetLastWin32Error
返回的值传递给它。如果您回头看一下图 1
中的代码，您会看到我在 extern MessageBeep
方法的公共包装中就采用了这种方法。
在每次调用外部方法之后缓存由 API
函数设置的错误。然后，在包装方法中，可以通过调用类库的 System.Runtime.InteropServices.Marshal
类型中定义的 Marshal.GetLastWin32Error
方法来获取缓存的错误值。我的建议是检查这些期望来自 API
函数的错误值，并为这些值引发一个可感知的异常。对于其他所有失败情况（包括根本就没意料到的失败情况），则引发在 System.ComponentModel
命名空间中定义的 Win32Exception，并将 Marshal.GetLastWin32Error
返回的值传递给它。如果您回头看一下图 1
中的代码，您会看到我在 extern MessageBeep
方法的公共包装中就采用了这种方法。
CallingConvention 我将在此介绍的最后也可能是最不重要的一个 DllImportAttribute
属性是 CallingConvention。通过此属性，可以给 CLR
指示应该将哪种函数调用约定用于堆栈中的参数。CallingConvention.Winapi
的默认值是最好的选择，它在大多数情况下都可行。然而，如果该调用不起作用，则可以检查 Platform SDK
中的声明头文件，看看您调用的 API
函数是否是一个不符合调用约定标准的异常 API。
属性是 CallingConvention。通过此属性，可以给 CLR
指示应该将哪种函数调用约定用于堆栈中的参数。CallingConvention.Winapi
的默认值是最好的选择，它在大多数情况下都可行。然而，如果该调用不起作用，则可以检查 Platform SDK
中的声明头文件，看看您调用的 API
函数是否是一个不符合调用约定标准的异常 API。
通常，本机函数（例如 Windows API
函数或 C-
运行时 DLL 函数）的调用约定描述了如何将参数推入线程堆栈或从线程堆栈中清除。大多数 Windows API
函数都是首先将函数的最后一个参数推入堆栈，然后由被调用的函数负责清理该堆栈。相反，许多 C-运行时 DLL
函数都被定义为按照方法参数在方法签名中出现的顺序将其推入堆栈，将堆栈清理工作交给调用者。
函数或 C-
运行时 DLL 函数）的调用约定描述了如何将参数推入线程堆栈或从线程堆栈中清除。大多数 Windows API
函数都是首先将函数的最后一个参数推入堆栈，然后由被调用的函数负责清理该堆栈。相反，许多 C-运行时 DLL
函数都被定义为按照方法参数在方法签名中出现的顺序将其推入堆栈，将堆栈清理工作交给调用者。
幸运的是，要让 P/Invoke
调用工作只需要让外围设备理解调用约定即可。通常，从默认值 CallingConvention.Winapi
开始是最好的选择。然后，在 C
运行时 DLL
函数和少数函数中，可能需要将约定更改为 CallingConvention.Cdecl。
调用工作只需要让外围设备理解调用约定即可。通常，从默认值 CallingConvention.Winapi
开始是最好的选择。然后，在 C
运行时 DLL
函数和少数函数中，可能需要将约定更改为 CallingConvention.Cdecl。
数据封送处理
数据封送处理是 P/Invoke
具有挑战性的方面。当在托管和非托管代码之间传递数据时，CLR
遵循许多规则，很少有开发人员会经常遇到它们直至可将这些规则记住。除非您是一名类库开发人员，否则在通常情况下没有必要掌握其细节。为了最有效地在 CLR
上使用 P/Invoke，即使只偶尔需要 interop
的应用程序开发人员仍然应该理解数据封送处理的一些基础知识。
具有挑战性的方面。当在托管和非托管代码之间传递数据时，CLR
遵循许多规则，很少有开发人员会经常遇到它们直至可将这些规则记住。除非您是一名类库开发人员，否则在通常情况下没有必要掌握其细节。为了最有效地在 CLR
上使用 P/Invoke，即使只偶尔需要 interop
的应用程序开发人员仍然应该理解数据封送处理的一些基础知识。
在本月专栏的剩余部分中，我将讨论简单数字和字符串数据的数据封送处理。我将从最基本的数字数据封送处理开始，然后介绍简单的指针封送处理和字符串封送处理。
封送数字和逻辑标量
Windows OS 大部分是用 C
编写的。因此，Windows API
所用到的数据类型要么是 C
类型，要么是通过类型定义或宏定义重新标记的 C
类型。让我们看看没有指针的数据封送处理。简单起见，首先重点讨论的是数字和布尔值。
编写的。因此，Windows API
所用到的数据类型要么是 C
类型，要么是通过类型定义或宏定义重新标记的 C
类型。让我们看看没有指针的数据封送处理。简单起见，首先重点讨论的是数字和布尔值。
当通过值向 Windows API
函数传递参数时，需要知道以下问题的答案：
函数传递参数时，需要知道以下问题的答案：
? 数据从根本上讲是整型的还是浮点型的？
? 如果数据是整型的，则它是有符号的还是无符号的？
? 如果数据是整型的，则它的位数是多少？
? 如果数据是浮点型的，则它是单精度的还是双精度的？
有时答案很明显，但有时却不明显。Windows API
以各种方式重新定义了基本的 C
数据类型。图 2
列出了 C 和 Win32
的一些公共数据类型及其规范，以及一个具有匹配规范的公共语言运行库类型。
以各种方式重新定义了基本的 C
数据类型。图 2
列出了 C 和 Win32
的一些公共数据类型及其规范，以及一个具有匹配规范的公共语言运行库类型。
通常，只要您选择一个其规范与该参数的 Win32
类型相匹配的 CLR
类型，您的代码就能够正常工作。不过也有一些特例。例如，在 Windows API
中定义的 BOOL
类型是一个有符号的 32
位整型。然而，BOOL
用于指示 Boolean
值 true 或 false。虽然您不用将 BOOL
参数作为 System.Int32
值封送，但是如果使用 System.Boolean
类型，就会获得更合适的映射。字符类型的映射
类型相匹配的 CLR
类型，您的代码就能够正常工作。不过也有一些特例。例如，在 Windows API
中定义的 BOOL
类型是一个有符号的 32
位整型。然而，BOOL
用于指示 Boolean
值 true 或 false。虽然您不用将 BOOL
参数作为 System.Int32
值封送，但是如果使用 System.Boolean
类型，就会获得更合适的映射。字符类型的映射