C#中调用Dll动态连接库

C#中调用Dll动态连接库

起始

受限于语言的不一样，咱们有的时候可能会用别人提供的函数及方法

或者其余的什么缘由、反正就是要调！！！

恰巧别人所使用的的语言跟本身又不是同样的

这个时候想要调用别人的函数库就须要借用一些别的东西了

今天咱们要说的是“UnmanagedExports”

当前我所要实现的目的只是为某一QQ机器人编写插件

但我又不喜欢某中文编程语言，编程习惯致使 233333

在这里咱们还可使用进程间UDP通讯来解决这个问题(编写插件的问题)

可是这种方法局限性比较大，操做起来又略显繁琐

因此今天介绍一下“UnmanagedExports”这个nuget包

通过

打开nuget包管理器，为你所在的项目的安装上这个包，这里就不在复述了

以后即可以以相似下面的写法来调用Dll

首先须要声明须要调用的函数及其对用的Dll

[DllImport("user32.dll")]//DllImportAttribute
public static extern int MsgBox(int hWnd, String text, String caption, uint type);

这里告诉编译器咱们须要调用的Dll名称及其对应的方法定义

使用“extern”关键字来标识这个方法是从外部引用

关于“DllImportAttribute”的属性会在下面讲到

DllImportAttribute详解

DllImportAttribute是一个重要的角色，其主要做用是给CLR指示哪一个Dll是须要调用的外部库。

字段	说明
BestFitMapping	启用或禁用最佳匹配映射。
CallingConvention	指定用于传递方法参数的调用约定。 默认值为 WinAPI，该值对应于基于 32 位 Intel 的平台的 __stdcall。
CharSet	控制名称重整以及将字符串参数封送到函数中的方式。 默认值为 CharSet.Ansi。
EntryPoint	指定要调用的 DLL 入口点。
ExactSpelling	控制是否应修改入口点以对应于字符集。 对于不一样的编程语言，默认值将有所不一样。
PreserveSig	控制托管方法签名是否应转换成返回 HRESULT 而且返回值有一个附加的 [out, retval] 参数的非托管签名。默认值为 true（不该转换签名）。
SetLastError	容许调用方使用 Marshal.GetLastWin32Error API 函数来肯定执行该方法时是否发生了错误。 在 Visual Basic 中，默认值为 true；在 C# 和 C++ 中，默认值为 false。
ThrowOnUnmappableChar	控件引起的异常，将没法映射的 Unicode 字符转换成一个 ANSI"?"字符。

除了指出所调用的Dll外，DllImportAttribute还包含了一些可选属性

其中有如下几个比较经常使用：

entrypoint

入口点，用于标识函数在Dll中的位置。

你能够将入口点映射到一个不用的名称，这实际上就是将被调用的函数重命名。

这里也说明如下重命名Dll函数的可能缘由

• 避免使用区分大小写的API函数名
• 符合现行的命名标准
• 提供采用不一样数据类型的函数（经过声明同一Dll函数的多个版本）
• 简化对包含ANSI和Unicode版本的API的使用

[DllImport("dllname", EntryPoint="MyFunctionname")]
[DllImport("dllname", EntryPoint="#123")]

指定入口点名称时，您能够提供一个字符串来指示包含入口点的 DLL 的名称，或者也能够按序号来标识入口点。序号以 # 符号为前缀，如 #1。（序号看不太明白，不用先）

下面来演示一下如何使用Entrypoint字段将咱们本身的函数MessageBoxA映射(替换)为Dll库中的MsgBox

[DllImport("user32.dll", EntryPoint="MessageBoxA")]
public static extern int MsgBox(int hWnd, String text, String caption, uint type);

CharSet（部分摘自MSDN）

charset字段控制字符串封送处理并肯定平台调用在dll查找函数名的方式。

对于采用字符串参数的函数，有些 API 将导出它们的两个版本：窄版本 (ANSI) 和宽版本 (Unicode)。例如，Win32 API 包含 MessageBox 函数的如下入口点名称：

• MessageBoxA

提供单字节字符 ANSI 格式，其特征是在入口点名称后附加一个“A”。对 MessageBoxA 的调用始终会以 ANSI 格式封送字符串，它常见于 Windows 95 和 Windows 98 平台。

• MessageBoxW

提供双字节字符 Unicode 格式，其特征是在入口点名称后附加一个“W”。对 MessageBoxW 的调用始终会以 Unicode 格式封送字符串，它常见于 Windows NT、Windows 2000 和 Windows XP 平台。

CharSet 字段接受如下值：

CharSet.Ansi（默认值）

• 字符串封送处理

平台调用将字符串从托管格式 (Unicode) 封送为 ANSI 格式。

• 名称匹配

在 ExactSpelling 字段为 true（它是 Visual Basic 2005 中的默认值）时，平台调用将只搜索您指定的名称。例如，若是指定MessageBox，则平台调用将搜索 MessageBox，若是它找不到彻底相同的拼写则失败。

当 ExactSpelling 字段为 false（它是 C++ 和 C# 中的默认值）时，平台调用将首先搜索未处理的别名 (MessageBox)，若是找不到未处理的别名，则将搜索已处理的名称 (MessageBoxA)。请注意，ANSI 名称匹配行为与 Unicode 名称匹配行为不一样。

CharSet.Unicode

• 字符串封送处理

平台调用会将字符串从托管格式 (Unicode) 复制为 Unicode 格式。

• 名称匹配

当 ExactSpelling 字段为 true（它是 Visual Basic 2005 中的默认值）时，平台调用将只搜索您指定的名称。例如，若是指定MessageBox，则平台调用将搜索 MessageBox，若是它找不到彻底相同的拼写则失败。

当 ExactSpelling 字段为 false（它是 C++ 和 C# 中的默认值）时，平台调用将首先搜索已处理的名称 (MessageBoxW)，若是找不到已处理的名称，则将搜索未处理的别名 (MessageBox)。请注意，Unicode 名称匹配行为与 ANSI 名称匹配行为不一样。

CharSet.Auto

• 平台调用在运行时根据目标平台在 ANSI 和 Unicode 格式之间进行选择。( 针对目标操做系统适当地自动封送字符串。在 Windows NT、Windows 2000、Windows XP 和 Windows Server2003 系列上默认值为 System.Runtime.InteropServices.CharSet.Unicode；在 Windows 98
  和 Windows Me 上默认值为 System.Runtime.InteropServices.CharSet.Ansi。)

下面的示例演示用于指定字符集的 MessageBox 函数的三个托管定义。在第一个定义中，经过省略，使 CharSet 字段默认为 ANSI 字符集。

[DllImport("user32.dll")]

public static extern int MessageBoxA(int hWnd, String text, String caption, uint type);

[DllImport("user32.dll", CharSet=CharSet.Unicode)]

public static extern int MessageBoxW(int hWnd, String text, String caption, uint type);

[DllImport("user32.dll", CharSet=CharSet.Auto)]

public static extern int MessageBox(int hWnd, String text, String caption, uint type);

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”。

若是 DLL 函数不以任何方式处理文本，则能够忽略 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。

有时，Windows API 是否有字符集关系并不明显。一种决不会有错的确认方法是在 Platform SDK 中检查该函数的 C 语言头文件。（若是您没法确定要看哪一个头文件，则能够查看 Platform SDK 文档中列出的每一个 API 函数的头文件。）若是您发现该 API 函数确实定义为一个映射到以 A 或 W 结尾的函数名的宏，则字符集与您尝试调用的函数有关系。Windows API 函数的一个例子是在 WinUser.h 中声明的 GetMessage API，您也许会惊讶地发现它有 A 和 W 两种版本。

以上内容采起直译，大意就是那样

这里咱们通常不设置，即便用Auto便可。

各位Dalao有看法的话欢迎补充说明。

SetLastError(摘自MSDN)

SetLastError 错误处理很是重要，但咱们在编程时常常会遗忘，或者直接偷懒而致使程序容错性差。

对于该函数，咱们可使用 GetLastError 来查找扩展的错误信息，则应该在外部方法的 DllImportAttribute 中将 SetLastError 属性设置为 true。

这会致使 CLR 在每次调用外部方法以后缓存由 API 函数设置的错误。

而后，在包装方法中，能够经过调用类库的 System.Runtime.InteropServices.Marshal 类型中定义的 Marshal.GetLastWin32Error方法来获取缓存的错误值。

个人建议是检查这些指望来自 API 函数的错误值，并为这些值引起一个可感知的异常。

对于其余全部失败状况（包括根本就没意料到的失败状况），则引起在 System.ComponentModel 命名空间中定义的 Win32Exception，并将 Marshal.GetLastWin32Error返回的值传递给它。

CallingConvention

该字段的值有如下几个：

• CallingConvention.Cdecl : 调用方清理堆栈。它使您可以调用具备 varargs 的函数（如printf）。

• CallingConvention.StdCall : 被调用方清理堆栈。它是从托管代码调用非托管函数的默认约定。

• CallingConvention 字段的默认值为 Winapi，然后者又默认为 StdCall 约定。

这里不作详解，用到的地方很少，大可能是时候默认。

这里给一个例子

[DllExport("about", CallingConvention = CallingConvention.Cdecl)]
public static void about()
{
}

这里咱们须要本身实现该函数

ExactSpelling

ExactSpelling 指示是否应修改非托管 DLL 中的入口点的名称，以与 CharSet 字段中指定的 CharSet 值相对应。

若是为 true，则当 DllImportAttribute.CharSet 字段设置为 CharSet 的 Ansi 值时，向方法名称中追加字母 A，当 DllImportAttribute.CharSet 字段设置为 CharSet 的 Unicode 值时，向方法的名称中追加字母 W。

此字段的默认值是 false。

定义明确的状况下，不刻意使用该字段。

我的认为会把本身绕进去

结果

MarkDown真是太好使了！