走近COM Interop
—— RCW入门

绪言

由于目前加入了一个负责将原有系统移植至.Net平台的项目组，花了些时间对COM-->.Net进行了些基础研究。贴出此文，希望与各位分享。不足之处，请各位指正。先谢啦。

一、基础概念
什么是COM Interop？COM Interop看上去象是介乎于COM和.Net之间的一条纽带，一座桥梁。为了保持向后兼容，COM Interop可以使得.Net程序在不修改原有COM组件的前提下方便的访问COM组件。这一点是非常重要的。事实上，全球的COM组件的代码量估计可能有数十亿行，拥有这些COM组件的公司不可能重写这些组件，所以COM Interop的存在为有此需求的开发者提供了很好的解决方案。
大家都知道，COM和.NET之间存在着非常大的差异，为了使两者可以有机的结合在一起进行协同工作，COM Interop中实际存在着2种桥接方式。一种是RCW，Runtime Callable Wrapper(水平有限，不知道精确的翻译是什么，这儿就不予详解了。)；另一种是CCW，COM Callable Wrapper。后者，将在后续的相关文章中进行讨论，这儿就不再赘述了，本文主要关注的是前者。RCW是在运行时通过CLR从Interop装配件(Interop Assembly)的元数据中获取相关信息动态的实例化而得到的。个人认为，可以把它理解为是介乎于COM和.Net应用程序之间的一个代理，.Net应用程序对COM组件的每个调用请求都是通过这个RCW中转的。使用者将感觉不到自己是在调用COM组件，一切都是这么的自然，和调用一个.Net组件没有任何区别。使用C++的朋友都知道，在C++中如果想要实例化一个COM对象，需要使用CoCreateInstance。而当我们有了RCW之后，一切都变得简单，我们可以在C#中使用new来直接实例化这个COM对象。
需要注意的是，一个COM组件(指的是一个实例，即一个DLL文件)由且仅由一个RCW负责维护。那么这儿有一个问题了，对于一个COM组件的不同版本，是不是就会有不同的RCW与之相对应呢？答案是肯定的。那有些朋友会说，.Net中的组件不是已经解决了COM中的“DLL HELL”问题了吗？按上面的说法，似乎并没有得到解决嘛？这儿我要说的是，在.Net中导入一个COM组件的不同版本，是会出现此类问题。解决此类问题的方法是使用PIA(Primary Interop Assembly)，这部分不在本文的讨论范围之内，我将在后续的相关文章中和大家进行讨论。

二、实战演练
.Net提供三种途径供我们导入一个COM组件：
- 通过Visual Studio .Net提从的“添加引用”功能
- 通过命令行方式——TLBIMP.EXE
- 使用System.Runtime.InteropServices.TypeLibConverter类编程实现导入功能
第一种方式无须赘述，非常的简单。第三种方式我会说明PIA的用法的同时，对此方法的使用加以说明。不过，我的水平不高，各位不要要求太高喽。^_^ 言归正传，本文关注的是第二种方式。我们可以直接使用此工具提供的最简单的调用方式：TLBIMP TestObj.dll。但需要提醒各位的是，如果我们使用这种方式导入一个COM组件的话，我们将“牺牲”原有的COM组件，这样做是很危险的。个人认为，最简单的调用方式是TLBIMP TestObj.dll /out:interop.TestObjLib.dll。这样，执行后将会产生一个名为interop.TestObjLib.dll的COM Interop。下面将给出简单的例子以说明整个过程。
1、首先用VB写的一个简单的ActiveX Dll
'Project name is TestObjList,class name is TestObj
Option Explicit

Public Function Add(ByVal iValue As Integer) As Integer
Add = iValue + 1
End Function

2、使用命令行工具导入这个COM组件
TLBIMP TestObjLib.dll /out:interop.TestObjLib.dll

3、在一个.Net Windows Forms中写一段调用此组件的测试代码
using interop.TestObjLib;
private void button1_Click(object sender,System.EventArgs e)
{
TestObjClass obj = new TestObjClass();
int num = 1;
MessageBox.Show(obj.Add(num).ToString());
}

此处需要说明一点，当TLBIMP.EXE在生成Interop装配件时会在原COM中的类的名字后面加上一个"Class"。调用时，请各位注意。

走近COM Interop
—— 浅谈PIA

序

　　非常的惭愧，因工作原因，《走近COM Interop》系列文章至今才出第二篇。此篇文章将以介绍PIA(Primary Interop Assembly)为主线，其间将穿插一些使用强名称工具(sn.exe)的内容。希望各位多多指教。

一、何为PIA？
　　其定义，MSDN的官方解释为“主 Interop 程序集是一个由供应商提供的唯一的程序集。它包含用 COM 实现的类型的类型定义（作为元数据）。只能有一个主 Interop 程序集，而且该程序集必须由 COM 类型库的发行者用强名称签名。一个主 Interop 程序集可以包装同一类型库的多个版本。”。

二、为何需要PIA？
举个例子吧。有2个托管应用程序ShapeTool和TextTool都引用了COM组件Graphic，并且都各自使用自己的密钥生成了为自所用的Graphic的Interop Assembly。COM组件Graphic中提供了一个IGraphicMeta接口，ShapeTool中有一个方法需要传递这个接口的引用。如果此时TextTool需要调用ShapeTool提供的了这个方法，那么它需要将自己生成的Interop Assembly作为参数传递过去。但这样将是非常的危险的，它会引入很多严重的问题。原因应该是显而易见的，因为这2个应用程序分别使用了自己的密钥对其生成的Interop Assembly进行签名，而CLR则会认为它们是2个完全不同的实体。所以，这样将会出现混乱的情况。
　　那么，接下来我们需要考虑的就是如何解决这个问题了。解决之道，在于PIA。PIA与一般的Interop Assembly有什么不同呢？我观察下来，似乎就是多了一个名为PrimaryInteropAssemblyAttribute，这个属性的构造函数有2个参数，分别是其主 Interop 程序集的类型库的主要版本号和次要版本号。见图一。
图一
如今，很多大型软件都已经提供PIA以便开发人员进行二次开发。这样的例子非常多，如：Office、Crystal Report等。

三、实战演练
　　这里我们做一个简单的演示，将生成如图一中所示的Interop.PIADemo.dll。具体步骤如下：
1. 在VB中创建一个ActiveX Dll工程，命名为PIADemo，类名为Test。因为篇幅的原因，这儿以截图代之(见图二)。
图二
2.生成密钥
　我们需要使用sn.exe生成密钥文件。
　C:\>sn -k common.snk
3.生成PIA
C:\>tlbimp PIADemo.dll /primary/keyfile:common.snk /out:Interop.PIADemo.dll
　TlbImp.exe可以带很多参数，具体地请参见MSDN中的相关说明。
4.第3步完成后，PIA就已经被生成了。不过，接下来，组件的发布者需要考虑一下是否将生成的Assembly部署到GAC(Global Assembly Cache)中。如果不打算将其部署到GAC中，那么我们就需要做一些额外的事情。因为调用时，当我们导入一个COM组件，调用者(如：Visual Studio.Net)会到注册表中查询是否有可用的PIA存在，如果没有找到，VS.Net则会自动创建为这个COM组件一个Interop Assembly。为此，我们需要使用.Net提供的RegAsm.exe来注册我们生成的这个PIA。这个工具使用起来很简单：
　regasm Interop.PIADemo.dll
这样，在注册表中我们就能发现它了(见图三、四)。图三
图四
当然，如果将生成的Assembly部署到GAC中就无需如此了(导入时此PIA就会出现在.Net组件列表中了)。将Assembly部署到GAC可以使用.Net提供的GacUtil.exe工具。
gacutil -i Interop.PIADemo.dll
5.编写调用端代码
　在此，我给出一个简单的示例。

　　至此，我们已经完成了一个简单的生成PIA的范例。不过，请注意，如果你的程序集引用第三方COM 类型库中的类型，必须先从发行者获取一个主Interop 程序集，才能生成你的主 Interop 程序集。
　　
　　此外，因时间关系，将以编程方式实现COM类型库引入的内容放到下一篇文章中予以说明。请见谅。

这篇文章是《走近COM Interop》系列的最后一篇，也是涉及技术点最多的一篇。希望我的描述大家能看到懂，难免有错，请各位不吝赐教。
　　书归正传，我开始介绍如果通过编程的方式导入一个COM组件，并生成相应的.Net Assembly。其实，过程非常简单，个人认为只是自己实现了TLBIMP.EXE做的事情而已。（当然，也可以实现TLBEXP.EXE的功能，只是它属于CCW的范畴，这儿就不多说了。）

一、准备工作
　　具体说来，编程实现COM-->Assembly的功能，需要使用的以前几个类：
　　System.Runtime.InteropServices
　　　－TypeLibConverter　　　　　　提供一组服务，将托管程序集转换为 COM 类型库或进行反向转换。
　　　－ITypeLibImporterNotifySink　　提供回调机制，以供类型库转换器向调用方通知转换的状态，并在转换过程本身之中涉及调用方。
　　System.Reflection
　　　－StrongNameKeyPair(可选)　　封装对公钥或私钥对的访问，该公钥或私钥对用于为强名称程序集创建签名。
　　System.Reflection.Emit
　　　－AssemblyBuilder定义并表示动态程序集。

　　此外，还需要使用一个WinAPI，LoadTypeLibEx，具体定义如下：
　　[DllImport( "oleaut32.dll",CharSet = CharSet.Unicode,PreserveSig = false )]
private static extern void LoadTypeLibEx(String strTypeLibName,RegKind regKind,[MarshalAs(UnmanagedType.Interface)] out Object typeLib );
　　为了让这个WinAPI function可以正常使用，我们还需要定义一个枚举，

　　注：上述类的说明来自MSDN。

　　大家都看到了，上述几个类中，仅有StrongNameKeyPair是可选的，这是因为如果我们不需要生成PIA，那么是不需要使用这个类的。同时，如果需要生成PIA，那么需要提供相应的密钥文件。在后面的描述中，我们将使用《走近COM Interop－－浅谈PIA》中的例子做进一步的演示。

二、实战演练
　　在此，我们仍就由VB生成的PIADemo.dll展开演示。
1. 载入一个COM组件