.NET 技术FAQ(九)-----关于 COM

9. 关于 COM
9.1 COM 消亡了吗？
我的理解是：COM 包含很多内容，并且对于不同的人而言它是不同的东西。但是对我来说，COM 基本上是关于一小段代码如何找到另一小段代码，以及当它们相互找到后该如何相互通讯。COM 准确地指明了这种定位和通讯该如何进行。在完全由 .NET 对象构成的“纯” .NET 世界里，小段代码依然相互寻找并相互交谈，但它们不使用 COM 来做这些。它们使用在某些地方和 COM 很相像的一种模型—例如，类型信息保存在和组件封装在一起的表单中，这和在 COM 组件中封装一个类型库十分相似。但它不是 COM。
所以，这里有什么问题吗？好吧，我确实不关心大多数 COM 消失了—我不关心寻找组件不再和注册表有关，我也不使用 IDL 来定义我的借口。但有一件东西我不希望它消失—我不希望失去基于接口的开发这种思想。照我看来，COM 最强大的力量是它坚持在接口和实现之间竖起铸铁般的隔墙。不幸的是，看来 .NET 不再那样坚持—它允许你做基于接口的开发，但它并不坚持。一些人可能会辩解说有一个选择总不会是坏事，可能他们是对的，但我不能不觉得这可能是一个退步。
 
9.2 DCOM 消亡了吗？
差不多是，尤其是对于 .NET 开发者。.NET 框架有一个不基于 DCOM 的新的远程模型。当然 DCOM 还会在互操作场合下使用。
 
9.3 MTS/COM+ 消亡了吗？
不。第一个 .NET 版本考虑的是提供对现有 COM+ 服务 (通过一个互操作层) 而不是使用 .NET 自己的服务来取代它们。很多工具和属性被用以实现尽可能平滑的过渡。.NET SDK 的 PDC 版本包括对核心服务 (JIT 活动、事务) 的支持，但不包括一些高层服务 (例如 COM+ 事件、队列化组件)。
在一段时间内看来，互操作性可以预期是无缝集成的—这意味着一些服务将成为 CLR 的一部分，并且/或者意味着一些服务将以可管理代码的形式重写并运行在 CLR 的顶层。
  
9.4 能在 .NET 中使用 COM 组件吗？
可以。可以通过 Runtime Callable Wrapper (RCW) 从 .NET 中访问 COM 组件。它通过将 COM 组件映射为与 .NET 兼容的接口来使 COM 接口可以被访问。对于 oldautomation 接口，可以自动地从一个类型库中产生。对于非 oleautomation 接口，可以开发一个定制的 RCW，以便手工地将 COM 接口的类型映射为与 .NET 兼容的类型。
对于熟悉 ATL 的读者，这里有一个简单的示例。首先，创建一个 ATL 组件以实现以下 IDL：
import "oaidl.idl";
import "ocidl.idl";
 
[
 object,
 uuid(EA013F93-487A-4403-86EC-FD9FEE5E6206),
 helpstring("ICppName Interface"),
 pointer_default(unique),
 oleautomation
]

interface ICppName : IUnknown
{
 [helpstring("method SetName")] HRESULT SetName([in] BSTR name);
 [helpstring("method GetName")] HRESULT GetName([out,retval] BSTR *pName );
};

[
 uuid(F5E4C61D-D93A-4295-A4B4-2453D4A4484D),
 version(1.0),
 helpstring("cppcomserver 1.0 Type Library")
]
library CPPCOMSERVERLib
{
 importlib("stdole32.tlb");
 importlib("stdole2.tlb");
 [
  uuid(600CE6D9-5ED7-4B4D-BB49-E8D5D5096F70), 
  helpstring("CppName Class")
 ]
 coclass CppName
 {
  [default] interface ICppName;
 };
};
建立了组件以后，你会得到一个 typelibrary。在 typelibrary 上运行 TLBIMP 实用程序，就像这样：
tlbimp cppcomserver.tlb
如果成功，你会得到像这样的信息：
Typelib imported successfully to CPPCOMSERVERLib.dll
现在你需要一个 .NET 客户端—我们用 C# 创建一个包含以下代码的 .cs 文件：
using System;
using CPPCOMSERVERLib;

public class MainApp
{
 static public void Main()
 {
  CppName cppname = new CppName();
  cppname.SetName( "bob" );
  Console.WriteLine( "Name is " + cppname.GetName() );
 }
}
注意我们使用 typelibrary 的名字作为命名空间，COM 类的名字作为类名。我们也可以选择使用 CPPCOMSERVERLib.CppName 作为类名而且不需要语句 using CPPCOMSERVERLib。
像这样编译以上 C# 代码：
csc /r:cppcomserverlib.dll csharpcomclient.cs
注意，编译被告知，引用我们刚才用 TLBIMP 从 typelibrary 产生的 DLL。
现在你应该可以运行 csharpcomclient.exe，并从控制台得到如下输出：
Name is bob
 
9.5 能在 COM 中使用 .NET 组件吗？
可以。可以通过一个 COM Callable Wraper (CCW) 从 COM 中访问 .NET 组件。这和 RCW 很相似 (参见上一个问题)，但以相反的方向工作。同样，如果它不能由 .NET 开发工具自动产生，或不想要自动产生的行为逻辑，可以开发一个定制的 CCW。为使 COM 可以“看见” .NET 组件，.NET 组件必须在注册表里注册。
这里是一个简单的例子。创建一个名为 testcomserver.cs 的 C# 文件并输入下面的代码：
using System;

namespace AndyMc
{
 public class CSharpCOMServer
 {
  public CSharpCOMServer() {}
  public void SetName( string name ) { m_name = name; }
  public string GetName() { return m_name; } 
  private string m_name;
 }         
}
然后编译 .cs 文件：
csc /target:library testcomserver.cs
你会得到一个 dll，这样将它注册：
regasm testcomserver.dll /tlb:testcomserver.tlb
现在你需要创建一个客户端程序来测试你的 .NET COM 组件。VBScript 可以—将以下内容放到一个名为 comclient.vbs 的文件中：
Dim dotNetObj
Set dotNetObj = CreateObject("AndyMc.CSharpCOMServer")
dotNetObj.SetName ("bob")
MsgBox "Name is " & dotNetObj.GetName()
运行此脚本：
wscript comclient.vbs
嘿！你得到一个显示文本“Name is bob”的消息框。
(注意，编写此程序时，看起来可以通过几种路径将 .NET 类作为 COM 组件访问—为了避免问题，在 testcomserver.dll 相同的目录下运行 comclient.vbs。
一种替代的方法是使用 Jason Whittington 和 Don Box 开发的 dm.net moniker。
 
9.6 在 .NET 的世界中 ATL 是多余的吗？
是的。如果你在编写 .NET 框架内的应用程序。当然许多开发者希望继续使用 ATL 来编写 .NET 框架以外的 C++ COM 组件，但当你在 .NET 框架内时你差不多总是希望使用 C#。在 .NET 世界里，原始的 C++ (以及基于它的 ATL) 并没有太多的地位—它太直接了，并且提供了太多的适应性，以至于运行库不能管理它。