OpcRcw.da.dll在x64模式下编译运行失败的一次调试经历

项目需要，用到了OPC，系统是64位系统，因为调用了x64的库，所以整个工程是以x64模式编译的，但是我手中的OpcRcw.da.dll却是x86的

经过单步调试发现会在向Group中添加Item时直接跳出，异常信息是 超出读写范围     也就是说代码的指针跑到了它不应该到的地方。

代码锁定在

((IOPCItemMgt)GetObjectByGroupName(groupName)).AddItems(itemCount, ItemDefArray, out pResults, out pErrors);

这句出现了问题。

看函数的入参类型：

OPCITEMDEF[] ItemDefArray 

IntPtr pResults

IntPtr pErrors

int itemCount

可以看到在AddItem函数中有一个结构体数组形式的入参
右键查看定义，跳转到dll元数据中（我跟你们讲啊,这个.Net调试起来感觉真是赞..）

下图中可以看到该结构体中有一个IntPtr 指针pBlob



 结构体里存指针，我的直觉告诉我这里可能有问题，（关于这个直觉下文再说）

来了个测试代码



x86模式下编译输出结果是4

x64下输出为8

然后通过ILSpy逆向OpcRcw.da.dll看源码（这个工具还能实现C#和VB.Net的代码互转 http://blog.csdn.net/backspace110/article/details/53525404）


可以看到 Pack = 4 也就是说该结构体是4字节对齐的。

关于结构体对齐的那一堆规则就不说了，有兴趣的可以去查一下，分几种情况的，我也记不全。

反正对齐规则是会影响内存分布的，（之前说的直觉）可能会把x64模式下8字节的IntPtr拆分掉。

主要是之前单片机开发时遇到过结构体对齐的问题。

大体上知道了可能的问题，那么就改成Pack = 8试试。

在ILSpy中FIle -> Save Code 导出为VS工程文件源码

修改Pack = 8 然后重新编译为dll

再回到我的代码中，调用我修改的最新的OpcRcw.da.dll

再次以x64模式编译，问题解决。

上附件，vs2015，x86，x64，anycpu的debug与release模式dll下载
http://dl2.iteye.com/upload/attachment/0121/8582/7100e290-ddb3-32af-850e-e6d6fc382691.zip