SOE 中调用第三方dll

一、简介

在利用soe实现server的扩展的时候，有些时候，需要调用第三方的dll库。官网中给出了明确的说明，soe中是可以添加第三方的dll文件，但是一直没有测试。按照官方的步骤应该是一个非常的简单的步骤。官方的步骤，参考连接如下：点击我

但是在实际测试的过程中发现并不如官方的步骤如此简单。其中涉及一个非常重要的东西，就是强签名。

二、强签名密钥

在新建soe模板工程后，可以在工程目录下看到一个名为myKey.snk 文件。snk一言以蔽之，为了防止自己的应用程序被篡改，就是给自己的应用程序加了一个token密钥。只有token密钥匹配才能在程序中引用。

强签名的程序集有个特性，就是不会调用没有签名的程序集，也就是说在soe中调用的dll第三方库，必须也是强签名过的，且签名证书与soe模板生成的证书是匹配的。如果不匹配在编译soe的时候会出现如下的错误：

三、dll添加强签名

在实际的过程中，有的dll是有源码的，有的是没有源码。根据这两种情况，生成强签名的方式有如下两种方式

1. 有源码的dll

有源码的这种情况，相对来说比较简单，在vs中打开项目，在项目上右击-properities-singing中，勾选复选框。选择soe模板文件生成的签名文件。重新build项目即可。如下图所示

2. 没有源码的dll

还有的dll文件没有源码，且没有强签名。这个时候如果要给待引用的dll文件添加soe的强签名，需要先将dll文件通过反汇编工具，汇编成il代码文件，然后给il文件添加强签名，然后重新编译生成强签名的dll。这也是snk这种方式不安全地方所在，就是通过反汇编，可以更改源码。

具体的操作如下，

首先，使用vs sdk tool中 反汇编工具，生成il文件

在弹出的工具中打开dll文件，然后file-dump保存后缀为.il 的文件，使用utf-8保存

习惯使用命令行的可以，可以使用如下命令

ildasm ClassLibrary.dll /utf-8 ClassLibrary.il

请注意这些命令行并不是在cmd中执行，而是vs的命令行工具。如下图所示。

接下来就是给反编译的il添加soe的证书，命令如下

ilasm /dll /key=myKey.snk ClassLibrary.il /out=ClassLibrary.dll

最后将新生产的dll，添加到soe项目中编译即可。本满怀欣喜的以为可以了但是执行soe的时候，出现了如下错误

这个错误耽误了我很久的时间。因为从soe文件中，可以看到新的dll已经打包进去，但是soe工程确找不到文件。

通过将这种方式重新生产的dll与有源码直接vs编译的dll通过反编译工具reflactor进行反编译对比。发现两者的runtime的版本是不一样。通过vs编译的其runtime的版本是2.0，而ilasm生产的runtime是4.0，而soe的开发版本才有的runtime的版本是3.5，故导致该问题。

究其原因，发现每个runtime sdk的下面都有ilasm.exe 文件，而我不知不觉的使用的runtime framework 4.0的。

ilasm.exe 的目录格式如下：

C:\Windows\Microsoft.NET\Framework\v2.0.50727，将上面的命令替换如下：

C:\Windows\Microsoft.NET\Framework\v2.0.50727\ilasm.exe /dll /key=myKey.snk ClassLibrary.il /out=ClassLibrary.dll

即可。

四、参考：

1.http://www.cnblogs.com/zjoch/archive/2012/08/28/2660358.html

2.http://msdn.microsoft.com/zh-cn/library/6f05ezxy(v=vs.110).aspx

3. http://blog.csdn.net/a497785609/article/details/8662295

五、总结

在测试这个过程中，我顺便测试了下dll的平台版本。按道理来说，server是64位，其能调用的dll的版本应该也是64的，但是实际我测试了32位也是可以的。涉及到底层通信，就不知道怎么解释了。