连接COM与.NET的桥梁（一）——预备知识

转自
http://www.vckbase.com/module/articleContent.php?id=1336

本文代码使用ISO C++和.net v1.1框架（VS 2003）编写，但其原理适合所有支持.net框架的语言

一、前言

由于传统的COM技术使用静态的非托管编程，而.net使用动态的托管编程，所以这个题目本质上讨论的是托管与非托管代码之间的互操作中的一个特例。目前的 .net v2.0 提供以下 三种互操作：

模块级别的P/Invoke方法

这种操作方法适合调用在动态链接库 (DLL)（如 Win32 API 中的 DLL）中实现的非托管函数。将在下一节讨论；

组件级别的COM Interop方法

这是本文的重头戏，它分两个部分：

1、导出类型库的方法：本文的主角；

2、使用封装类的方法 ：该方法为CLI C++所独有，由框架自动生成包装类(在COM客户端中为非托管头文件代码)，原理同第三种互操作相同；

代码级别的C++ Interop方法

这种操作方法是 CLI C++ 所独有的，即只能用在VS 2005及以上版本中。其实现非常简单，对外部 DLL 的包装全部都由向导生成，不用写一行代码，所以本文不再描述。（另一个原因是我暂时没有条件使用 VS 2005 ^_^!）

二、类型转换与封送处理

既然是两个平台、两个世界之间的互操作，它们之间的信息传递就必须转换为对方能看懂的类型，这种转换叫做“Marshal”，或者叫做“封送”。数据的封送处理是个异常复杂的过程，感兴趣的读者可以在 MSDN 中搜索描述其原理的文档“Marshaling Details”。下图是 COM Interop 的封送原理。

好在 .net 平台的 Interop 程序集机制可以帮助我们进行一些简单的数据封装工作，把复杂的 Marshal 细节给隐藏了。这样使得我们在 .net 客户端中调用 COM 服务器时传递一些简单的数据会非常方便，但如果传送的数据是自定义的，则仍需手动 Marshal。该机制的原理描述在 MSDN 中的“COM 包装”。

下图摘自 MSDN 2003 版，描述了.net v1.1 将把我们的数据从一个平台的类型转换为另一个平台的何种类型，表中没有没有显式标识的任何类型都将被转换为 Int32 系统类型。

嗯...看上去还真不少，不过别高兴的太早了，在实际的使用中只有如int等较为简单的类型才能保证各种灵活的传递方式而不出问题...@_*。需要注意的是,COM一方的VARIANT类型（这也是编写COM时的推荐类型）将按照其vt的值来转换为具体的类型并封装，所以COM一方设置vt时一定要设对了，别乱设！另外对于表中没有给出的具体类型，最好不要使用或作为自定义类型进行封装。

有关数据类型转换的详细介绍，请参见MSDN中的"COM 数据类型"，自定义类型的描述文档是"自定义标准包装"。如果想让.net组件也像COM组件那样实现回调接口或者连接点，则需要托管接口与该接口的非托管实现之间的通信，这时需要自定义Marshal封送处理，实现这个功能的文档是"自定义封送处理"。

三、错误处理

.net客户端没有 HRESULT 类型，.net 服务器中定义方法函数时也可以没有返回值，那么如何处理错误呢？其实这个工作也由 .net 平台的封送机制帮我们做了。

1、COM 服务器->.net客户端

客户端直接用try()...catch()方式即可得到翻译过的HRESULT信息，系统定义的错误信息在 .net 类库中一般都有定义好的现成类，处理起来很方便。

2、.net服务器->COM客户端

客户端可以像通常那样 HRESULT hr=...; 的方式得到错误信息。

当服务器端不支持丰富错误信息接口 IErrorInfo 时，错误信息将按照下表所示进行双向的翻译。

当服务器端实现了丰富错误信息接口 IErrorInfo 时，错误信息将按照下表所示进行双向的翻译，由于表的内容太多，这里只列出其中的一部分。

这部分内容和上表在 MSDN 中的描述文档是“HRESULT” 和异常，有关.net的异常处理，参见 MSDN 文档“处理和引发异常”。

四、总结

第一篇主要介绍了一些概念，给大家一个思考问题的思路，具体细节没有进行详细讨论，而是给出MSDN中的位置，大家需要的可以去参考参考，建议使用至少MSDN2003以上版本的中文版(翻译的还不错^_^)。这些知识在实践中大多都被编译器隐藏起来了，所以作用并不大，了解一下即可。该篇没有示例代码，下一篇我们就要开始进行实战啦^_^