今天在部署系统时碰到引用的COM组件ADOX和ADODB 报错，原来该机器上没有注册这两个组件。
在.NET下任何COM组件被引用时生成的Interop前缀的dll文件只是一种到具体实现的代理，COM仍需要在目标机器上注册。
以下转载：
.Net提供三种途径供我们导入一个COM组件：
1、 通过Visual Studio .Net提从的“添加引用”功能
2、 通过命令行方式：TLBIMP.EXE
3、 使用System.Runtime.InteropServices.TypeLibConverter类编程实现导入功能
什么是COM Interop？COM Interop看上去象是介乎于COM和.Net之间的一条纽带，一座桥梁。为了保持向后兼容，COM Interop可以使得.Net程序在不修改原有COM组件的前提下方便的访问COM组件。
大家都知道，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组件没有任何区别。
需要注意的是，一个COM组件(指的是一个实例，即一个DLL文件)由且仅由一个RCW负责维护。那么这儿有一个问题了，对于一个COM组件的不同版本，是不是就会有不同的RCW与之相对应呢？答案是肯定的。那有些朋友会说，.Net中的组件不是已经解决了COM中的“DLL HELL”问题了吗？按上面的说法，似乎并没有得到解决嘛？这儿我要说的是，在.Net中导入一个COM组件的不同版本，是会出现此类问题。解决此类问题的方法是使用PIA(Primary Interop Assembly)。