VC++编写DLL供C#使用

半年没有写东西了。也就出差了半年。半年没有用C#，写了半年VC,呵呵。有时候其实有挺多东西写的，不过一忙起来人就懒了。简单的东西不想写，复杂的又写不了，哈哈。最近不是太忙，大概看了下COM组件模型，然后对DLL工作，库文件有了一些兴趣。因为工作和自己写的程序可以延伸到这些知识上，所以对DLL进行了一定的了解，而且对于直接开始编写C#应用程序的人来说，也很少会去了解这些，所以决定写下来。

 

 

 一 库文件

库文件是我们在接触编程时经常听到的词。那么什么是库文件。其实库文件是一种重用的思想。比如我们自己编写C#的程序，可能会把公用的一些方法放在一个名为Common的项目中，然后编译成DLL，其他项目引用这个程序集，就可以调用这个里面的方法，而不用自己去实现。在说的大一点，.NET中提供给我们使用的类，也是存放在.NET库中的。而整个WINDOWS系统，都是建立在库文件基础上的。

 

其实在最初的时候是没有库文件的概念，所有功能都是自己实现的。为了提高效率，减少重复工作，就必须对代码重用。重用方法有很对，比如对于一些通用的方法的实现代码让编译器自己生成，但这个问题是，一旦方法变更会添加，编译器也必须修改了。另一个方法是把常用的方法编译成.obj模块文件。这样在编译的时候，去链接这些模块文件，就能实现代码重用。但是所有方法放到一个obj文件中，文件会很庞大，占用内存；如果为每个方法提供一个obj文件，那又会相当的麻烦。

 

于是就出现了静态库（static library），静态库是一个或多个.obj文件的集合。使用到这些.obj文件对应的函数时，只需要在连接时提供该静态库，而不需要列举用到的.obj文件。而连接器进行连接的时候，只会将程序中用到的函数对应的.obj文件连接到程序中。静态库的形式就是我们WINDOWS上常见的.lib文件。

 

但静态库的确定是，每个程序使用时都会吧需要的obj文件拷贝到内存中，100个程序就有100个拷贝，这样对内存的浪费很大，而且如果静态库文件更新的话，程序也需要重新编译，进行连接。于是共享库（shared library，也叫做动态连接库）就出现了。首先他是被加载到公用的内存空间中，是所有程序共享的，所以对节省了内存；另外他在编译时没有象静态库那样，把代码直接连接到了程序中，只是插入了动态库的一些信息，供调用时使用。这样，我们就有可能直接修改动态库，而不需要重新编译程序。

 

动态库当然也有他的问题，比如DLL HELL。DLL Hell 是指当多个应用程序共享一个DLL或COM组件时所引发的一系列问题。比如一个应用程序安装一个新版本DLL，而该DLL与机器上的现有版本不向后兼容。这样就可能导致以前的引用程序引发异常。而.NET的强命名程序集就解决了这个问题，它通过程序集（DLL）名称、语言、版本、KEY来区分DLL，而不仅仅是只通过名字。也就能保证对个版本的DLL同时工作。

 

 

二 使用库文件

其面说到了库文件有静态库和动态库以及.NET的程序集文件。

 

我们在.NET中编写的DLL，在其他.NET程序中调用时很方便，引用DLL程序集，然后添加namespace，这样就能直接使用程序集中的方法了。这些都是因为.NET的程序集中的元数据，使得DLL文件有了自述性。所以也就取消了C++中的.h文件。

 

以下是在托管的VC++环境下使用：

 

演练：创建和使用静态库

 

演练：创建和使用动态链接库

 

对于非托管的VC++环境使用如下：

 

使用静态库时，我们需要提供一个编译好的Lib文件。但是光有这个文件不行，因为我们不知道这个文件中包含了那些方法。所以我们还需要提供我们编写库文件时使用的.h头文件。在我们自己的VC项目中引入这个.lib库，然后吧.h头文件添加到项目中，就可以调用了。

 

 

具体使用方法参见：静态连接库的生成和使用

 

使用动态库时，我们的库编译后生成DLL时，链接程序会自动生成一个与之对应的 LIB 导入文件。所以存在2种不同的调用方法，叫隐式加载和动态加载。

所谓动态库静态加载，使用上和静态库类似，但是他必须提供DLL，而LIB文件也和静态库不同了，这里的LIB文件直接和DLL关联，实际的实现代码是在DLL中。

而动态连接，就是使用LoadLibrary函数，加载DLL库；通过GetProcAddress 获得方法的指针，然后可以直接使用此方法，而不需要引入LIB文件和头文件。

 

具体使用方法参见：DLL(Dynamic Link Libraries)专题

 

 

 

三 VC编写DLL

 

 

 

我使用VC++编写一个文件加密的DLL，并且在C#中调用。

 

编写一个动态库很简单，以VS2010为列，我们在VC++下选择【WIN32】--【WIN32项目】。在应用程序向导中，选择应用程序类型为DLL,并且选择为空项目。然后添加一个.h文件和一个.cpp文件

 

// FileEncrypt.h /*加密文件*/ extern "C" __declspec(dllexport) void EncryptMyFile(char *in_fname,char *out_file);

 

 

 

 

 // Filencrypt.cpp #include "FileEncrypt.h" #include <stdexcept> #include <iostream> #include<stdio.h> #include<stdlib.h> #include<conio.h> #include<string.h> #include <windows.h> /*加密子函数开始*/ void EncryptMyFile(char *in_fname,char *out_file) { //实现省略 }

 

 

编译之后我们就能得到一个DLL和一个LIB文件。

 

实现很简单，和我们写普通程序一样。唯一不同的是.h文件中声明函数时增加了extern "C" __declspec(dllexport) 这样一串在东西。其中extern "C" 网上解释非常多，简单的说是因为C++编译后，方法名字会变化，不是我们在程序中使用的EncryptMyFile。我们可以利用Depends工具来查看：

 

 

以上2个图就是使用了extern "C" 和没使用时的函数的名称。从第2个图可以看到，名字已经修改了。具体修改的参数意义可以参见DLL(Dynamic Link Libraries)专题 ，里面有详细介绍。所以当我们编写的DLL是给其他非VC程序调用，如C,C#等，就需要增加extern "C" ，来确保编译时不会被修改名字，以便程序使用。

 

 

 

另一个__declspec(dllexport)  标记使用来表示此函数为导出函数。。 一下内容是《WINDOWS核心编程》对这个的解释，具体可以参见书中原文。出此之外书中也对extern "C" 进行了解释。

 

当Micresoft的C/C++编译器看到变量、函数原型或C++类之前的这个修改符的时候，它就将某些附加信息嵌入产生的.OBJ文件中。当链接DLL的所有.OBJ文件时，链接程序将对这些信息进行分析。 当DLL被链接时，链接程序要查找关于输出变量、函数或C++类的信息，并自动生成一个.LIB文件。该.LIB文件包含一个DLL输出的符号列表。当然，如果要链接引用该DLL的输出符号的任何可执行模块，该.LIB文件是必不可少的。除了创建.LIB文件外，链接程序还要将一个输出符号表嵌入产生的DLL文件。这个输出节包含一个输出变量、函数和类符号的列表（按字母 顺序排列）。该链接程序还将能够指明在何处找到每个符号的相对虚拟地址(RVA)放入DLL模块。

 

如果我们的程序缺少了__declspec(dllexport)，那么其他应用程序调用DLL时就无法找到入口点：

 

 

鉴于上面的问题，VC还提供了一个DEF模块定义文件，来设置导出函数。我们可以在项目中添加一个DEF文件，配置如下，具体的DEF文件格式可以参见核心编程。这样我们就不需要在.h文件中添加额外的修饰符了

 

 

LIBRARY FileEncrypt EXPORTS EncryptMyFile @1

 

 

 

四 C#中使用DLL

 

这里使用的DLL是VC下编译生成的DLL，而不是.NET下的DLL。两者是不同的。使用自己的DLL和我们使用系统API是一样的。

 

 [DllImport("FileEncrypt")] public static extern void EncryptMyFile(string inFileName, string outFilename);

 

引入我们的DLL，并且声明这个方法就可以使用了。麻烦的仅仅是C#和C++直接数据类型的转换。其面提到，如果使用别人提哦那个的DLL，并且没有使用extern "C" 时，我们c#程序使用时会因为函数名不同而提示找不到函数入口点，我们可以通过设置DllImport属性中指定EntryPoint字段，指示要调用的DLL入口点名称和序号。

 

 

另外需要注意的地方就是VC运行库，默认编译运行库的参数是MD，这个时候，我们的DLL文件很小，需要目标机器上有VC运行库的支持，如果我们修改为MT则不在需要,而是吧需要的打包和DLL在一起了，此时的DLL会较大。这个我在编写的时候就遇到了。具体解释MSDN上有。

 

 

 

五 总结

其实对于有VC编程经验的人来说，上面都是挺简单的，不过对于一开始就写C#来说，不能说复杂，只能说不了解。所以还是有必要写下来。