了解 .NET 应用程序的经典 COM 互操作

1. 当 C# 中方法参数未被关键字限定时，它通常会映射到 IDL 中的[in]属性，假设是按值传递语义。
2. C# 方法的返回值始终映射到 IDL 中的[out, retval]方向属性。
3. ref 方法参数关键字会映射到 IDL 中的[in,out]方向属性。
4. out 方法参数关键字会映射到 IDL 中的[out]方向属性。
5. .NET 世界中发生的错误不是通过方法的返回值返回的。而是作为异常抛出。

在此处阅读更多关于错误处理的信息。以下是一些 C# 参数类型如何映射到 IDL 中的方向属性的示例

在托管代码中重用经典 COM 组件

互操作的一个优点是，您可以让您的托管 .NET 类使用继承或包含模型来重用现有 COM 组件提供的功能。这很棒，因为消费托管 .NET 组件的 .NET 应用程序永远不会知道该托管组件实际上是在内部利用经典 COM 组件的非托管代码实现。我们将看看托管 .NET 组件如何重用现有 COM 组件的几种方式。

• 混合模式继承
• 混合模式包含

我们称之为混合模式，因为我们的托管类重用了非托管 COM 组件中已有的代码和功能逻辑。

让我们看看您可以通过哪些各种方式从 .NET 类重用现有 COM 组件中的非托管代码。

通过混合模式继承进行重用

在此重用模型中，您可以让您的托管 .NET 类扩展/继承一个非托管 COM coclass。此外，托管类可以选择覆盖 COM coclass 接口中的方法，或接受基 COM coclass 的实现。这是一个非常强大的模型，您可以在同一类中混合托管和非托管实现。

从托管类继承非托管代码

让我们看下面的代码片段以更好地理解这一点。我们将使用 ATL 创建一个名为 Flyer 的 COM 对象，该对象支持一个名为 IFlyer 的接口，其中有两个方法：TakeOff() 和 Fly()。这是组件的 IDL 声明

[
 ....
]
interface IFlyer : IDispatch
{
    [id(1), helpstring("method TakeOff")] 
            HRESULT TakeOff([out,retval] BSTR* bstrTakeOffStatus);
    [id(2), helpstring("method Fly")] 
            HRESULT Fly([out,retval] BSTR* bstrFlightStatus);
};

[
  .....
]
coclass Flyer
{
   [default] interface IFlyer;
};

这是两个方法的实现

STDMETHODIMP CFlyer::TakeOff(BSTR *bstrTakeOffStatus)
{
   *bstrTakeOffStatus = 
       _bstr_t(_T("CFlyer::TakeOff - This is COM taking off")).copy();
   return S_OK;
}

STDMETHODIMP CFlyer::Fly(BSTR *bstrFlyStatus)
{
    *bstrFlyStatus = 
        _bstr_t(_T("CFlyer::Fly - This is COM in the skies")).copy();
    return S_OK;
}

在此组件可以被托管代码消费之前，您必须从其类型库生成此组件的元数据代理。为此，您需要从命令行发出以下命令

tlbimp MyFlyer.tlb /out:MyFlyerMetadata.dll

我们现在将创建继承自此组件的托管类，使用常规的继承语义，以便重用组件的功能。其中一个托管类 Bird 继承自 Flyer COM 对象的元数据类型。这意味着它将继承 Flyer COM 组件的所有方法。另一个托管类 Airplane 使用自己的实现覆盖了 TakeOff 和 Fly 方法。有一个需要注意的地方是，您不能选择性地只覆盖托管代码中 COM coclass 的特定方法。如果您决定在托管代码中覆盖 COM coclass 的单个方法，您将不得不覆盖所有其他方法。换句话说，您不能只为 TakeOff 方法提供覆盖的实现，而隐式地让托管类使用 COM 对象中的 Fly 实现。您还必须在托管类中覆盖Fly方法并为其提供实现。如果您需要重用 COM coclass 的实现，您可以从托管类的 Fly 实现中调用 base.Fly。您可能会在编译时选择性地覆盖特定方法。但在运行时，您最终会遇到 System.TypeLoadException 异常，其错误消息大致如下：“扩展 COM 对象的类型应覆盖基 COM 类实现的接口的所有方法”。

using System;
using MyFlyerMetadata;

// Inherit from the metadata type representing
// the unmanaged COM component
// Use the COM Component's implementation 
// of TakeOff & Fly (Use the base class' implementation)
public class Bird : Flyer 
{

}/* end class Bird */

// Inherit from the metadata type representing
// the unmanaged COM component
// Override the COM object's method implementations in our
// derived managed-class.
// (Also call base class implementation when
// necessary using base.MethodName())
public class Airplane : Flyer
{

    // Override the COM Component's Flyer::TakeOff implementation
    // with our own implementation
    public override String TakeOff() {
    
       return "Airplane::TakeOff - This is .NET taking off";
       
    }/* end TakeOff */

    // Override the COM Component's Flyer::Fly implementation
    // with our own implementation
    public override String Fly() {
    
       // Can call the base class' implementation too if you
       // wish to.
       System.Console.WriteLine(base.Fly());
       return "Airplane::Fly - This is .NET in the skies";
       
    }/* end Fly */

}/* end class Airplane */

public class FlightController
{
    public static void Main(String[] args)
    {
        Bird falcon = new Bird();
        System.Console.WriteLine("BIRD: CLEARED TO TAKE OFF");
        System.Console.WriteLine(falcon.TakeOff());
        System.Console.WriteLine(falcon.Fly());

        Airplane skyliner = new Airplane();
        System.Console.WriteLine("AIRPLANE: CLEARED TO TAKE OFF");
        System.Console.WriteLine(skyliner.TakeOff());
        System.Console.WriteLine(skyliner.Fly());

    }/* end Main */

}/* end FlightController */

您可以使用 DOS 命令行中的以下命令编译上述程序

csc /target:exe /out:FlightClient.exe /r:MyFlyerMetadata.dll FlightClient.cs

运行上述程序，会得到以下输出

BIRD: CLEARED TO TAKE OFF
CFlyer::TakeOff - This is COM taking off
CFlyer::Fly - This is COM in the skies
AIRPLANE: CLEARED TO TAKE OFF
Airplane::TakeOff - This is .NET taking off
CFlyer::Fly - This is COM in the skies
Airplane::Fly - This is .NET in the skies

Bird 和 Airplane 托管类的消费者无需知道这些类实际上是通过继承重用现有 COM 组件的。在必要时，托管类会用自己的实现覆盖 COM 组件中的所有方法。这种托管代码继承非托管代码的重用模型称为混合模式继承重用模型。

通过混合模式包含进行重用

在此模型中，托管类使用与经典 COM 中包含相同的原理。它所做的只是将代表非托管 COM 组件的元数据代理类的实例存储为一个成员。每当需要 COM 组件的服务时，它就会将请求转发给组件的方法。

通过包含/组合重用非托管 COM 代码

托管类能够在其自己的代码之前和之后注入代码，然后在调用包含的 COM 组件。这是一个例子

using System;
using MyFlyerMetadata;

 .....
 
// Contains an instance of the metadata type representing
// the unmanaged COM Component
public class HangGlider
{
    private Flyer flyer = new Flyer();

    // Forward the call to the contained class' implementation
    public String TakeOff() 
    {
      return flyer.TakeOff();
    }

    // Forward the call to the contained class' implementation
    public String Fly() 
    {
       // Do what you need to do before or after fowarding the 
       // call to flyer
       System.Console.WriteLine("In HangGlider::Fly - " + 
                                "Before delegating to flyer.Fly");
       return flyer.Fly();
    }

}/* end class HangGlider */

public class FlightController
{
    public static void Main(String[] args)
    {
        ....

        HangGlider glider = new HangGlider();
        System.Console.WriteLine("HANGGLIDER: CLEARED TO TAKEOFF");
        System.Console.WriteLine(glider.TakeOff());
        System.Console.WriteLine(glider.Fly());
        
    }/* end Main */

}/* end FlightController */

这是上面程序的输出

HANGGLIDER: CLEARED TO TAKEOFF
CFlyer::TakeOff - This is COM taking off
In HangGlider::Fly - Before delegating to flyer.Fly
CFlyer::Fly - This is COM in the skies

在上面的示例中，HangGlider 类创建了 Flyer COM 组件的实例并将其存储为私有成员。每当收到需要 Flyer 组件服务的调用时，它都会通过之前存储的私有实例调用该组件。此外，HangGlider 类可以自由地在委托调用到 Flyer 组件的方法之前和之后注入代码。在混合模式继承重用模型中，除非您在托管类中覆盖所有基类 COM 方法，否则这是不可能实现的。

我记得当我刚开始用 COM 编程时，我还没有涉足 COM 线程模型和 Apartment 的复杂领域，对它们到底是什么知之甚少。我认为我的对象是自由线程的，并且简单地认为这将是性能最好的线程模型。我很少意识到幕后发生了什么。我从未意识到STA客户端线程创建我的MTA对象时会带来性能损失。而且，由于我的对象不是线程安全的，我从未意识到当并发线程访问我的对象时会遇到麻烦。当时，对 COM 线程模型的无知确实是一种幸福。然而，这种幸福是短暂的，我的服务器开始意外崩溃。那时，我被迫涉足 COM 线程模型领域，并了解每种模型如何工作，COM 如何管理 Apartment，以及在不兼容的 Apartment 之间调用时会产生哪些性能影响。如您所知，在线程可以调用 COM 对象之前，它必须声明其对 Apartment 的归属，声明它将进入STA还是MTA。STA客户端线程调用 CoInitialize(NULL) 或 CoInitializeEx(0, COINIT_APARTMENTTHREADED) 进入STA Apartment，而MTA线程调用 CoInitializeEx(0, COINIT_MULTITHREADED) 进入MTA。同样，在 .NET 托管世界中，您可以选择让托管空间中的调用线程声明其 Apartment 亲和性。默认情况下，托管应用程序中的调用线程选择驻留在MTA中。这就像调用线程使用 CoInitializeEx(0, COINIT_MULTITHREADED) 初始化自己。但是，考虑一下调用为公寓线程设计的经典STA COM 组件时可能带来的开销和性能损失。不兼容的 Apartment 会产生额外的代理/存根对开销，这当然会带来性能损失。您可以通过使用 System.Threading.Thread 类的 ApartmentState 属性来覆盖 .NET 应用程序中托管线程的默认 Apartment 选择。ApartmentState 属性接受以下任一枚举值：MTA, STA和Unknown。ApartmentState.Unknown 等同于默认的MTA行为。您需要在进行任何 COM 对象调用之前为调用线程指定 ApartmentState。一旦创建了 COM 对象，就不可能更改 ApartmentState。因此，在代码中尽早设置线程的 ApartmentState 是有意义的。

// Set the client thread's ApartmentState to enter an STA
Thread.CurrentThread.ApartmentState = ApartmentSTate.STA;

// Create our COM object through the Interop
MySTA objSTA = new MySTA();
objSTA.MyMethod()

作为一种替代方法，您可以在托管客户端的Main入口点方法上标记 STAThreadAttribute 或 MTAThreadAttribute，以便使用所需的线程归属来启动它以消费 COM 组件。例如，请看下面的代码片段

public class HelloThreadingModelApp {

   .....

   [STAThread]
   static public void Main(String[] args) {
  
        System.Console.WriteLine("The apartment state is: {0}", 
                   Thread.CurrentThread.ApartmentState.ToString());
   
   }/* end Main */

}/* end class */

您将获得的输出将如下所示

The apartment state is: STA

如果设置了 MTAThread 属性，则 ApartmentState 将设置为MTA。如果客户端的 Main 入口点未指定线程状态属性，或者从中创建 COM 组件的线程未设置 ApartmentState 属性，则 ApartState 将为Unknown，默认情况下为 MTA 行为。

在本节中，我们将学习如何从非托管 COM 感知客户端消费托管 .NET 组件。将.NET 组件的客户端限制为仅托管客户端对于许多多年来开发无法一夜之间移植到托管代码的应用程序的开发人员来说，将是难以接受的。 .NET 框架允许不同平台上的不同应用程序通过 SOAP 等SOAP等线协议与托管应用程序通信。非托管 COM 感知客户端仍然有更简单的方式与托管组件通信。 .NET 运行时允许非托管 COM 感知客户端通过 COM 互操作以及框架提供的工具无缝访问 .NET 组件。这确保了 COM 感知客户端可以与 .NET 组件通信，就像它们与普通 COM 组件通信一样。

创建 .NET 组件

首先，让我们构建一个简单的 .NET 组件，该组件允许您查找您所在城市的温度。只有公共类才会被添加到类型库并暴露给 COM 感知客户端。此外，如果类需要可以从 COM 感知客户端创建，则它必须有一个公共默认构造函数。一个公共类，它没有公共默认构造函数，仍然会出现在类型库中，尽管它不能直接从 COM 共同创建。Temperature 组件有两个方法 DisplayCurrentTemperature 和 GetWeatherIndications。它有一个名为 Temperature 的公共读写属性，定义了相应的get/set方法。

using System;
using System.Windows.Forms;
using System.Runtime.InteropServices;

public enum WeatherIndications 
{
   Sunny = 0,
   Cloudy,
   Rainy,
   Snowy
}

[ClassInterface(ClassInterfaceType.AutoDual)]
public class TemperatureComponent
{
   private float m_fTemperature = 0;
   
   // Public Constructor
   public TemperatureComponent()
   {
      m_fTemperature = 30.0f;
   }

   //Public Property Accessors (Defines get/set methods)
   public float Temperature
   {
      get { return m_fTemperature; }
       
      set { m_fTemperature = value;}
      
   }/* end Temperature get/set property */
   

   // Public Method that displays the Current Temperature
   public void DisplayCurrentTemperature() 
   {
      String strTemp = String.Format("The current " + 
                       "temperature at Marlinspike is : " + 
                       "{0:####} degrees fahrenheit", 
                       m_fTemperature);
                
      MessageBox.Show(strTemp,"Today's Temperature");
      
   }/* end DisplayCurrentTemperature */

   // Another public method that returns an enumerated type
   public WeatherIndications GetWeatherIndications() 
   {
      if(m_fTemperature > 70) {
      
        return WeatherIndications.Sunny;
      }
      else {
      
        // Let's keep this simple and just return Cloudy
        return WeatherIndications.Cloudy;
      }
      
   }/* end GetWeatherIndications */
   
   
}/* end class Temperature */

您还会注意到有一个名为 ClassInterface 的属性标记在 Temperature 类上，其值设置为 ClassInterfaceType.AutoDual。我们将在窥探生成的类型库部分了解应用此属性的意义。现在，可以将其视为一种告诉类型库生成工具（如 REGASM.EXE 和 TLBEXP.EXE）将 .NET 组件类的公共成员导出到生成的类型库中的默认类接口的方法。同时请记住，使用类接口公开 .NET 类的公共方法通常不推荐，因为它不利于 COM 版本管理。我们将了解如何显式使用接口来实现相同的功能。显式定义接口，让您的 .NET 组件类派生自该接口，然后在 .NET 组件中实现该接口的方法，这是将 .NET 组件公开给 COM 感知客户端的推荐方法。我们将在窥探生成的类型库部分详细比较和对比这两种方法，并解释为什么前者不推荐。

如果您正在使用Visual Studio.NET，您可以创建一个Visual C# 项目并使用类库模板来编写上述组件。如果您是命令行高手，那么构建组件的命令是这样的。这将创建一个名为 Temperature.dll 的程序集。

csc /target:library /r:System.Windows.Forms.dll 
    /out:Temperature.dll TemperatureComponent.cs

从程序集中生成类型库并注册程序集

您刚刚生成的现在是一个 .NET 程序集，COM 感知客户端（如 Visual Basic 6.0）对此一无所知。您需要从中获取一些 COM 友好的类型信息，以便我们的 VB 客户端能够愉快地与之交互。之前，您使用了一个名为 TLBIMP（类型库导入器）的工具从 COM 类型库创建 .NET 元数据代理。您在这里需要做相反的事情。您需要采用 .NET 程序集并从中生成类型库，以便可以从 COM 感知客户端使用它。 .NET 框架提供了几个这样的工具。您可以使用类型库导出实用程序 (TLBEXP.exe) 或程序集注册实用程序 (Regasm.exe)，它们都可以在您的 .NET SDK 安装的Bin目录中找到。REGASM是TLBEXP实用程序的超集，因为它还做了比生成类型库更多的工作。它还用于注册程序集，以便进行适当的注册表项以方便 COM 运行时和 .NET 运行时将 COM 感知客户端连接到 .NET 组件。我们将使用REGASM.EXE，因为我们可以一次完成程序集注册和类型库生成。但您也可以使用TLBEXP来生成类型库，然后使用REGASM来注册程序集。

regasm Temperature.dll /tlb:Temperature.tlb

对 REGASM.EXE 的上述调用进行了适当的注册表项设置，并从 .NET 程序集中生成了类型库（Temperature.tlb），以便可以从我们的 VB 6 客户端应用程序中引用该类型库。

从 VB 6.0 客户端消费组件

让我们快速构建一个基于 VB 窗体的应用程序，该应用程序创建并调用 .NET 组件，我们已经注册了其程序集并生成了类型库。创建组件与创建 COM 对象的方式相同。您可以引用类型库并早期绑定到组件，或者使用组件的ProgID执行 CreateObject 调用以后期绑定到组件。通常，生成的ProgID是类的完全限定名。在本例中，生成的 ProgID 将是 TemperatureComponent。但是，您可以使用ProgIDAttribute指定用户定义的 ProgID 来覆盖默认生成的ProgID。

Private Sub MyButton_Click()

  On Error GoTo ErrHandler

  ' Create an instance of the temperature component
  Dim objTemperature As New TemperatureComponent

  ' Display the current temperature
  objTemperature.DisplayCurrentTemperature

  ' Set the temperature property
  objTemperature.Temperature = 52.7

  ' Display the current temperature after property mutation
  objTemperature.DisplayCurrentTemperature
  
  ' Check the weather indications
  If (objTemperature.GetWeatherIndications() = _
                     WeatherIndications_Sunny) Then
     MsgBox "Off to the beach"
  Else
     MsgBox "Stay at home and watch Godzilla on TV"
  End If

  Exit Sub
  
ErrHandler:

  MsgBox "Error Message : " & Err.Description, _
           vbOKOnly, "Error Code " & CStr(Err.Number)
End Sub

为了使 .NET 程序集解析器能够找到包含您的组件的程序集，您需要将组件放置在与正在使用它的应用程序相同的目录中，或者将程序集作为共享程序集部署到全局程序集缓存 (GAC)。目前，只需将 Temperature.dll 复制到您的 VB 客户端应用程序可执行文件相同的目录中。如果 VB 可以使用普通的基于 COM 的调用机制，并且仍然能够调用和消费 .NET 组件，那么在 VB6 客户端和 .NET 组件之间必须有一个好心的好人，负责将 COM 调用请求连接到实际的 .NET 组件。我们很快就会看到，幕后发生了什么。

深入了解 COM 互操作的魔力

让我们快速查看一下 Regasm.exe 在我们注册程序集时所做的注册表项。

REGASM 在程序集注册期间创建的注册表项

您可以通过打开 REGASM 生成的类型库的 OLEVIEW.EXE 来检查您的组件的CLSID。查看coclass部分下的uuid属性。如果您导航到注册表中的 HKCR\CLSID\{...Component's CLSID...} 键，您可以看到 REGASM 已创建 COM 激活由 Inproc 服务器托管的对象所需的注册表项。此外，它还创建了一些其他注册表项，如 Class、Assembly 和 RuntimeVersion，这些由 .NET 运行时使用。Inproc Server 处理程序（由 InProcServer32 键的默认值指示）设置为 mscoree.dll，这是核心CLR 运行时执行引擎。COM 运行时调用 MSCOREE.dll（CLR 运行时）中的 DllGetClassObject 入口点。然后，运行时使用传递给 DllGetClassObject 的类 ID (CLSID) 来查找 InProcServer32 键下的Assembly和Class键，以加载和解析将服务此请求的 .NET 程序集。运行时还会动态创建一个COM 可调用包装器 (CCW) 代理（RCW 的镜像），以处理非托管代码和托管组件之间的交互。这使得 COM 感知客户端认为它们正在与经典 COM 组件交互，并使 .NET 组件认为它们正在接收来自托管应用程序的请求。每个 .NET 组件实例都会创建一个 CCW。

幕后：从 COM 感知客户端访问 .NET 组件

俗话说，“一图胜千言”，所以让这里的插图来讲述 COM 感知客户端与 .NET 组件交互时幕后发生的大部分事情。这里的关键参与者是CLR 运行时和由 .NET 运行时创建的COM 可调用包装器 (CCW)。从那时起，CCW 就开始处理大部分工作，以使两者协同工作。CCW 在这里处理生存期管理问题。非托管领域的 COM 客户端在 CCW 代理上维护引用计数，而不是在实际 .NET 组件上。CCW 只持有 .NET 组件的引用。 .NET 组件遵循 CLR 垃圾回收器的规则，就像其他任何托管类型一样。CCW 存在于非托管堆中，并在 COM 感知客户端不再拥有该对象的任何未决引用时被销毁。就像 RCW 一样，CCW 也负责封送在非托管客户端和托管 .NET 组件之间来回传递的方法调用参数。它还负责按需合成 v-table。特定接口的 v-table 是动态生成的。它们仅在 COM 感知客户端通过 QueryInterface 调用实际请求特定接口时才被懒惰地构建。对 CCW 代理的调用最终会被路由到一个存根，该存根实际上会调用到托管对象。

窥探生成的类型库

让我们快速看一下程序集注册实用程序 (REGASM) 生成的类型库中包含什么样的信息。通过OLEVIEW的类型库查看器打开类型库，以便您可以查看从类型库反向工程的 IDL 文件。

// Generated .IDL file (by the OLE/COM Object Viewer)
// typelib filename: Temperature.tlb

[
  uuid(A9F20157-FDFE-36D6-90C3-BFCD3C8C8442),
  version(1.0)
]
library Temperature
{
    // TLib : Common Language Runtime Library :
    // {BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}
    importlib("mscorlib.tlb");
    // TLib : OLE Automation :
    // {00020430-0000-0000-C000-000000000046}
    importlib("STDOLE2.TLB");

    // Forward declare all types defined in this typelib
    interface _TemperatureComponent;

    typedef [uuid(0820402E-B8B6-330F-8D56-FF079E5B4659), version(1.0),
    custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "WeatherIndications")]    
    enum {
        WeatherIndications_Sunny = 0,
        WeatherIndications_Cloudy = 1,
        WeatherIndications_Rainy = 2,
        WeatherIndications_Snowy = 3
    } WeatherIndications;

    [
      uuid(01FAD74C-3DC4-3DE0-86A9-8490FAEE8964),
      version(1.0),
      custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, 
             "TemperatureComponent")
    ]
    coclass TemperatureComponent {
        [default] interface _TemperatureComponent;
        interface _Object;
    };

    [
      odl,
      uuid(C51D54FA-7C81-35A5-9998-3963EAB4AA12),
      hidden,
      dual,
      nonextensible,
      oleautomation,
      custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, 
             "TemperatureComponent")    
    ]
    interface _TemperatureComponent : IDispatch {
        [id(00000000), propget]
        HRESULT ToString([out, retval] BSTR* pRetVal);
        [id(0x60020001)] 
        HRESULT Equals([in] VARIANT obj, 
                       [out, retval] VARIANT_BOOL* pRetVal);
        [id(0x60020002)]
        HRESULT GetHashCode([out, retval] long* pRetVal);
        [id(0x60020003)]
        HRESULT GetType([out, retval] _Type** pRetVal);
        [id(0x60020004), propget]
        HRESULT Temperature([out, retval] single* pRetVal);
        [id(0x60020004), propput]
        HRESULT Temperature([in] single pRetVal);
        [id(0x60020006)]
        HRESULT DisplayCurrentTemperature();
        [id(0x60020007)]
        HRESULT GetWeatherIndications([out, retval] 
                WeatherIndications* pRetVal);
    };
};

如果您查看 coclass 部分，它将默认接口指定为类名的前缀是_（下划线）字符。此接口称为类接口，其方法由类的所有非静态公共方法、字段和属性组成。类接口的生成是因为您将 .NET 类标记为 ClassInterface 属性。此属性告诉类型库生成工具（如 RegAsm.exe 和 TlbExp.exe）生成一个称为类接口的默认接口，并将类所有公共方法、字段和属性添加到其中，以便它可以暴露给 COM 感知客户端。

只有公共方法在类型库中可见，并且可以被 COM 客户端使用。私有成员不会进入类型库，并对 COM 客户端隐藏。类的公共属性和字段被转换为 IDL propget/propput 类型。我们示例中的 Temperature 属性同时定义了set和get访问器，因此，为此属性都发出了 propset 和 propget。还有一个名为 _Object 的接口被添加到 coclass 中。类接口还包含 4 个其他方法。它们是

• ToString
• Equals
• GetHashCode
• GetType

这些方法被添加到默认的类接口中，因为它隐式继承自 System.Object 类。添加到接口的每个方法和属性都会获得一个自动生成的DISPID。您可以使用 DispId 属性用用户定义的 DISPID 覆盖此 DISPID。您会注意到 ToString 方法被分配了 DISPID 0，表示它是类接口中的默认方法。这意味着如果您省略方法名称，将调用 ToString 方法。

' Create an instance of the temperature component
Dim objTemperature As New TemperatureComponent

' Invoke the ToString method (the default method)
MsgBox objTemperature

让我们检查一下我们可以用来促进隐式类接口生成的各种方法。我们将从查看将 ClassInterfaceType.AutoDual 值应用于 ClassInterface 属性的效果开始。

[ClassInterface(ClassInterfaceType.AutoDual)]
public class TemperatureComponent
{
   ....
}

请注意，分配给 ClassInterface 属性的值（位置参数值）是 ClassInterfaceType.AutoDual。此选项告诉类型库生成工具（如 RegAsm.exe）将 Class Interface 生成为 dual 接口，并将所有 type information（关于方法、属性等及其相应的 Dispatch IDs）导出到类型库。想象一下，如果您决定要为该类添加另一个公共方法，会发生什么情况。这会改变生成的 Class Interface，并破坏 COM 中基本的 interface immutability 法则，因为 v-table 的结构现在发生了变化。Late Bound 客户端在尝试使用该组件时也会遇到麻烦。由于添加了新方法，Dispatch IDs (DISPIDs) 会重新生成，这也破坏了 late bound 客户端。一般来说，使用 ClassInterfaceType.AutoDual 是非常糟糕的做法，因为它完全不考虑 COM 版本控制。让我们看看您可以为 ClassInterface 属性设置的下一个可能值。将 ClassInterface 属性标记为 ClassInterfaceType.AutoDispatch 会强制类型库生成工具避免在类型库中生成 type information。因此，如果您的 TemperatureComponent 类像下面这样被 ClassInterface 属性标记

[ClassInterface(ClassInterfaceType.AutoDispatch)]
public class TemperatureComponent
{
  .....
}

那么，RegAsm.exe 生成的相应类型库将具有如下 IDL 结构

// Generated .IDL file (by the OLE/COM Object Viewer)
// typelib filename: Temperature.tlb

[
  uuid(A9F20157-FDFE-36D6-90C3-BFCD3C8C8442),
  version(1.0)
]
library Temperature
{
    ......

    [
      uuid(01FAD74C-3DC4-3DE0-86A9-8490FAEE8964),
      version(1.0),
        custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, 
               "TemperatureComponent")
    ]
    coclass TemperatureComponent {
        [default] interface IDispatch;
        interface _Object;
    };
};

您会注意到，默认接口是 IDispatch 接口，类型库中既没有 DISPIDs 也没有方法 type information。这使得 COM 感知客户端只能通过 late-binding 来使用 .NET 组件。此外，由于 DISPID 详细信息未作为 type information 存储在类型库中，客户端会通过 IDispatch::GetIDsOfNames 等方式按需获取这些 DISPIDs。这使得客户端在不破坏现有代码的情况下使用组件的新版本。使用 ClassInterfaceType.AutoDispatch 比使用 ClassInterfaceType.AutoDual 安全得多，因为它在发布组件的新版本时不会破坏现有客户端代码，尽管前者只允许 late binding。建议将 .NET 组件建模以供 COM 感知客户端使用的方法是完全去掉 Class Interface，而是显式地将您公开的方法提取到单独的接口中，并让 .NET 组件实现该接口。使用 Class Interface 是将 .NET 组件公开给 COM 感知客户端的一种快速便捷的方式。但这不是推荐的方式。让我们尝试重写我们的 TemperatureComponent，将其方法显式提取到一个接口中，看看类型库生成有何不同

// Define the ITemperature interface
public interface ITemperature {

   float Temperature { get; set; }
   void DisplayCurrentTemperature(); 
   WeatherIndications GetWeatherIndications(); 
   
}/* end interface ITemperature */


// (1) Implement the ITemperature interface in the TemperatureComponent class
// (2) Set the ClassInterfaceType for the ClassInterface
// atrribute to ClassInterfaceType.None

[ClassInterface(ClassInterfaceType.None)]
public class TemperatureComponent : ITemperature
{
    ......

    //Implement the methods in your class

    // Property Accessors (Defines get/set methods)
    public float Temperature
    {
      get { return m_fTemperature; }
      set { m_fTemperature = value;}
      
    }/* end Temperature get/set property */

    // Displays the Current Temperature
    public void DisplayCurrentTemperature() {
       .....
    }/* end DisplayCurrentTemperature */

    // Returns an enumerated type indicating weather condition
    public WeatherIndications GetWeatherIndications() {
       ....
    }/* end GetWeatherIndications */
   
}/* end class Temperature */

生成的类型库的相应 IDL 文件如下所示。请注意，TemperatureComponent 类的默认接口现在是该类实现的 ITemperature 接口。

// Generated .IDL file (by the OLE/COM Object Viewer)
// typelib filename: Temperature.tlb

[
  uuid(A9F20157-FDFE-36D6-90C3-BFCD3C8C8442),
  version(1.0)
]
library Temperature
{
    ......

    [
      odl,
      uuid(72AA177B-C6B2-3694-B083-4FF535B40AD2),
      version(1.0),
      dual,
      oleautomation,
      custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "ITemperature")    
    ]
    interface ITemperature : IDispatch {
        [id(0x60020000), propget]
        HRESULT Temperature([out, retval] single* pRetVal);
        [id(0x60020000), propput]
        HRESULT Temperature([in] single pRetVal);
        [id(0x60020002)]
        HRESULT DisplayCurrentTemperature();
        [id(0x60020003)]
        HRESULT GetWeatherIndications([out, retval] 
                WeatherIndications* pRetVal);
    };

    [
      uuid(01FAD74C-3DC4-3DE0-86A9-8490FAEE8964),
      version(1.0),
        custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, 
               "TemperatureComponent")
    ]
    coclass TemperatureComponent {
        interface _Object;
        [default] interface ITemperature;
    };
};

这种将 .NET 类的所有方法显式提取到一个接口中，并让该类继承并实现该接口的方法，是向 COM 感知客户端公开 .NET 组件的推荐方式。ClassInterfaceType.None 选项告诉类型库生成工具您不需要 Class Interface。这可确保 ITemperature 接口是 默认接口。如果您不为 Class Interface 属性指定 ClassInterfaceType.None 值，那么 Class Interface 将成为 默认接口。这是我们在本节中学到的要点

另一个有趣的观察是，当 .NET 类或接口中存在重载方法并导出到类型库时，REGASM 和 TLBEXP 如何通过在 IDL 中附加一个 '_' 后跟一个序列号来生成混淆的方法名。例如，如果您公开了 .NET 组件中的以下接口

public interface MyInterface
{
    String HelloWorld();
    String HelloWorld(int nInput);
}

那么，REGASM/TLBEXP 生成的对应类型库的 IDL 将如下所示。

[
  .....
]
interface MyInterface : IDispatch {

    [id(0x60020000)]
    HRESULT HelloWorld([out, retval] BSTR* pRetVal);
    
    [id(0x60020001)]
    HRESULT HelloWorld_2([in] long nInput, 
                         [out,retval] BSTR* pRetVal);    
};

请注意，第二个 HelloWorld 方法附加了 '_2'，以区别于 IDL 文件中的第一个方法。

使用属性调整生成的类型库元数据

了解 RegAsm.exe 或 TlbExp.exe 工具如何通过内省 .NET 程序集来生成 IDL，并随后生成类型库，可以让您根据自己的需求定制类型库的生成。您可以在程序集中注入 .NET 属性，为这些工具提供线索，以修改 IDL 中的元数据，从而影响创建的类型库。例如，您可以使用 InterfaceTypeAttribute 将接口类型从 dual 更改为仅基于 IUnknown 的自定义接口或 纯 dispinterface。以下是一些注入属性以限定 .NET 组件中类型并根据您的需求修改生成类型库的方法。

更改接口类型

默认情况下，.NET 类使用的接口在 IDL 中转换为 dual 接口。这使客户端能够同时获得 early binding 和 late binding 的优势。但是，有时您可能希望该接口是 pure-dispinterface 或仅基于 IUnknown 的自定义接口。您可以使用 InterfaceTypeAttribute 覆盖接口的默认类型。看下面的例子。

[InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface ISnowStorm 
{
 ....
}

[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IHurricane 
{
 ....
}

[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface ITyphoon 
{
 ....
}

public interface IWeatherStatistics
{
 .....
}

如上例所示，InterfaceType 属性用于将元数据信息发出到接口，以便像 RegAsm.exe 和 TlbExp.exe 这样的工具可以使用此信息来生成类型库中相应类型的接口。结果 IDL 将如下所示

  [
     odl,
     uuid(1423FBFA-BE13-3766-9729-9C1AAF5DB08A),
     version(1.0),
     dual,
     oleautomation,
     custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "ISnowStorm")    
 ]
 interface ISnowStorm : IDispatch {
   ....
 };

 [
     odl,
     uuid(D95E54B8-FABC-3BDA-AA45-AC4EFF49AF92),
     version(1.0),
     oleautomation,
     custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "IHurricane")    
 ]
 interface IHurricane : IUnknown {
   .... 
 };


 [
    uuid(676B3B85-7DB8-306D-A1E9-B6AA1008EDF2),
    version(1.0),
    custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "ITyphoon")    
 ]
 dispinterface ITyphoon {
        properties:
        methods:
 };

 [
   odl,
   uuid(A1A37136-341A-3631-9275-FC7B0F0DB695),
   version(1.0),
   dual,
   oleautomation,
   custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, 
          "IWeatherStatistics")    
 ]
 interface IWeatherStatistics : IDispatch {
    .....
 }

如上所示，将 InterfaceType 属性设置为 ComInterfaceType.InterfaceIsIUnknown 会生成仅基于 IUnknown 的自定义接口。将 InterfaceType 属性设置为 ComInterfaceType.InterfaceIsIDispatch 会生成纯仅 dispatch 的 dispinterface。将 InterfaceType 属性设置为 ComInterfaceType.InterfaceIsDual 或完全忽略 InterfaceType 属性（如示例中的 IWeatherStatistics 接口）会生成 dual 接口。

更改 GUID 和 ProgID

当这些类型导出到类型库时，像类和接口这样的类型的 GUID 会由 REGASM/TLBEXP 工具自动生成。但是，如果您需要为接口或类分配特定的 GUID，您仍然拥有最终决定权。您可以使用 Guid 属性指定用户定义的 GUID。您还可以影响特定类生成的 ProgID 的方式。默认情况下，RegAsm.exe 工具会将类的完全限定类型名称分配给 Progid。您可以使用 ProgId 属性为您的 coclass 分配用户指定的 ProgID。

[  
   GuidAttribute("AD4760A9-6F5C-4435-8844-D0BA7C66AC50"),
   ProgId("WeatherStation.TornadoTracker")
]
public class TornadoTracker  {
  .....
}

当 Guid 属性应用于类后，IDL 文件如下所示

[
  uuid(AD4760A9-6F5C-4435-8844-D0BA7C66AC50),
  version(1.0),
  custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "TornadoTracker")
]
coclass TornadoTracker {
   ....
};

请注意，coclass 部分中的 uuid 属性（代表 COM 类的 CLSID）包含我们指定的 GUID 值。如果您检查 HCKR\CLSID\{AD4760A9-6F5C-4435-8844-D0BA7C66AC50}\ProgID 注册表项，您应该看到值 WeatherStation.TornadoTracker，代表该类的 ProgID。

隐藏公共类型，不向 COM 公开

您之前看到，类中的所有公共类和接口如何自动添加到类型库中，以便 COM 感知客户端可以引用和使用它们。但有时您可能需要阻止某些公共接口和公共类对 COM 不可用。您可以使用 ComVisible 属性来实现此目的。将此属性设置为false 会阻止应用该属性的类型出现在类型库中。

[ComVisible(false)]
public interface IWeatherStatistics
{
    float GetLowestTemperatureThisMonth();
    float GetHighestTemperatureThisMonth();
}

在上例中，当程序集导出到类型库时，IWeatherStatistics 接口不会作为 type-information 导出到类型库。如果 IWeatherStatistics 类型被任何其他公开给 COM 的类型使用，它将在类型库中被替换为 IUnknown 接口。例如

HRESULT SetWeatherStatistics([in] IWeatherStatistics* pWeatherIndications);

变成

HRESULT SetWeatherStatistics([in] IUnknown* pUnkWeatherIndications);

不过，这里有一个注意事项。将 [ComVisible(true)] 应用于启用私有或受保护成员的可见性是没有意义的，因为它们永远无法公开给 COM。

ComVisible 属性不仅可以应用于类和接口，还可以应用于其他各种类型，如程序集、方法、字段、属性、委托、结构等。请看下面的示例，其中我们选择性地隐藏了接口中特定方法不向 COM 公开。

public interface IHurricaneWatch {

    void AlertWeatherStations(String strDetails);
    
    [ComVisible(false)]
    void PlotCoordinates();
    
    void IssueEvacuationOrders();    
}

上面的代码片段指示类型库生成器（RegAsm.exe/TlbExp.exe）我们打算隐藏 IHurricaneWatch 接口的 PlotCoordinates 方法，使其不出现在生成的类型库中。以下是生成的类型库的IDL 如下

 [
   ....
 ]
 interface IHurricaneWatch : IDispatch {
    
    [id(0x60020000)] HRESULT AlertWeatherStations([in] BSTR strDetails);
    [id(0x60020002)] HRESULT IssueEvacuationOrders();
 };

更改类型的封送处理行为

当运行时将托管类型封送到非托管世界时，它遵循某些数据类型转换规则。例如，托管类型（如 String）始终转换为 BSTR。像 String 这样的类型在非托管世界中可能有一个以上的可能表示形式，例如 ANSI 字符数组（LPSTR）、UNICODE 字符数组（LPWSTR）或 BSTR。当非托管域中的目标数据类型对底层托管类型有多种可能的表示形式时，我们就称这些类型为非同构类型。COM Interop 将非同构类型转换为特定的默认目标类型（例如，String 始终转换为 BSTR）。考虑 C# 类中的以下代码片段

public void SetProductName(String strProductName) { ... }

当上述代码通过 Typelibrary exporter（如 TLBEXP 或 REGASM）运行时，我们在 IDL 中与生成的类型库对应的结果如下

HRESULT SetProductName([in] BSTR strProductName);

但是，有时您可能需要为类型提供替代表示形式。例如，您可能希望将托管类型（如 String）转换为以 null 结尾的 ANSI 字符数组（LPSTR），而不是 BSTR。这时 MarshalAs 属性就派上用场了。您可以使用 MarshalAs 属性来控制托管类型和非托管类型之间的转换方式。因此，如果您希望将托管 String 转换为以 null 结尾的 ANSI 字符数组，而不是 BSTR，则需要在方法参数上应用 MarshalAs 属性，如下所示

public void SetProductName( [MarshalAs(UnmanagedType.LPStr)] 
                            String strProductName) { .... }

最终的转换在 IDL 表示形式中看起来会像这样

HRESULT SetProductName([in] LPSTR strProductName);

因此，当您需要调整托管世界和非托管世界之间类型的表示映射时，MarshalAs 属性会非常有用。

异常处理 - .NET 异常与 COM HRESULT 的比较

让我们看看 .NET 组件引发的异常如何映射到基于 COM 的 HRESULT。您会注意到，当通过类型库导出器运行时，.NET 组件方法返回类型会被转换为 [out,retval] IDL 类型。IDL 中方法的实际返回类型是 HRESULT，它指示方法调用的成功或失败。失败的 HRESULT 通常是系统异常或因业务逻辑失败而引发的用户定义异常的结果。如果方法调用正常进行，并且 .NET 组件没有引发异常，那么 CCW 会将返回的 HRESULT 填充为 0 (S_OK)。如果方法调用失败或业务逻辑验证失败，则 .NET 组件应引发异常。此异常通常会分配一个失败的 HRESULT 和相关的错误描述。CCW 从 .NET 异常中提取错误代码、错误消息等详细信息，并以 COM 客户端可用的形式提供这些详细信息。它通过实现 ISupportErrorInfo 接口（表示它支持丰富的错误信息）和 IErrorInfo 接口（通过它提供所有错误信息详细信息），或者通过传递给 IDispatch::Invoke 调用的 EXCEPINFO 结构（如果 COM 感知客户端通过 dispinterface 进行 late binding）来实现这一点。错误传播是无缝发生的，.NET 异常被映射到其等效的 COM 对应项，并由 CCW 传递给 COM 客户端。让我们修改 Temperature 属性的 set 方法，以便在指定温度超出可接受范围时引发用户定义的错误。我们很快就会看到 VB 客户端如何使用常规的 COM 错误处理机制捕获此错误。

public class TemperatureComponent
{
   private float m_fTemperature = 0;

   /* Temperature Property (In Fahrenheit)*/
   public float Temperature
   {
      get 
      {
         return m_fTemperature;

      }/* end get */
      
      set
      {
         if((value < -30) || (value > 150))
         {
            TemperatureException excep = new TemperatureException(
                                "Marlinspike has never experienced" + 
                                " such extreme temperatures. " + 
                                "Please recalibrate your thermometer");
            throw excep;
         }

         m_fTemperature = value;

      }/* end set */
      
   }

}/* end class TemperatureComponent */


class TemperatureException : ApplicationException
{
   public TemperatureException(String message) : base(message)
   {
   }

}/* end class TemperatureException*/

这是一个 VB 客户端，它试图在 Marlinspike 中设置一个超出方法接受的温度读数范围的值，这会触发 .NET 组件的异常。

Private Sub MyButton_Click()

 On Error GoTo ErrHandler

 ' Create an instance of the temperature component
 Dim objTemperature As New TemperatureComponent

 ' Set the temperature to the boiling point of water
 objTemperature.Temperature = 212

 Exit Sub

ErrHandler:
    MsgBox "Error Message : " & Err.Description, _
           vbOKOnly, "Error Code: " & CStr(Err.Number)

End Sub

在上例中，VB6 客户端通过 On Error Goto 语句设置的 ErrorHandler 块使用 VB 的全局内置 Err 对象来获取 CCW 从 .NET 异常映射到实现了 IErrorInfo 接口的 COM 特定错误对象的所有错误详细信息。

.NET 组件在此引发了 TemperatureException，它继承自 ApplicationException 类。通常会引发 ApplicationException 来指示与应用程序业务逻辑中常见的平凡失败相关的错误。TemperatureException 调用基类来初始化错误消息。由于没有指定显式 HRESULT，ApplicationException 类会生成一个失败的 HRESULT 并返回。如果您想控制 HRESULT 的值，而不是接受基类自动生成的 HRESULT 值，那么您可以使用 ApplicationException 类中的 HResult 受保护成员（TemperatureException 类可以访问它）来指定要返回的特定 HRESULT 值。从 .NET 组件抛出异常的另一种方法是使用 System.Runtime.InteropServices.Marshal 类的 ThrowExceptionForHR 方法。此方法接受一个表示标准 HRESULT 参数的整数。这些标准 HRESULT 大多映射到 .NET 异常类型，并抛出相应的 .NET 异常。例如，如果您使用

System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(COR_E_OUTOFMEMORY);

那么，将抛出 OutOfMemoryException。

在非托管事件接收器中处理 .NET 组件的事件

我们之前看到，非托管世界中的 COM 对象如何使用Connection Points 异步引发事件，以及 .NET 应用程序如何消耗这些事件。现在我们将看看反过来的情况。我们将让 .NET 组件引发事件，然后让一个非托管接收器消耗这些事件。.NET 组件应声明表示其事件接口中每个方法的委托实例。当事件被引发时，该事件列表中的所有委托都将被调用。这些委托引用通知目标的处理程序，因此可以调用订阅者提供的正确处理程序函数。非托管接收器像与支持事件接口的 COM 对象交互一样订阅事件，使用连接点。CCW 负责映射这两种事件处理模型，以便 COM 客户端的非托管处理程序在托管 .NET 事件发生时仍然可以接收通知。

创建源事件的 .NET 组件

让我们创建一个 .NET 组件，它会在恶劣天气条件下通知订阅者。该组件允许气象站站长设置已记录的风速。如果风速超过某个限制（300 mph），它会感知到即将发生的龙卷风，并通过触发 OnTornadoWarning 事件来通知订阅者。

using System;
using System.Runtime.InteropServices;
using System.Runtime.CompilerServices;
using System.Reflection;
using System.Diagnostics;

// Outgoing Event Interface which the Sink implements. We'll
// use a dispinterface here so that it remains friendly to
// scripting clients 

[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface ITornadoWatchEvents 
{
   void OnTornadoWarning(int nWindSpeed);

}/* end interface ITornadoWatchEvents */


// Incoming interface containing the methods
// being exposed to COM aware clients
public interface IWeatherNotify {

  int WindSpeed { get; set; }

}/* end interface IWeatherNotify */


// Delegate representing the OnTornadoWarning method of the 
// outgoing event interface
public delegate void TornadoWarningDelegate(int nWindSpeed);


[ 
  ComSourceInterfaces("ITornadoWatchEvents"),
  ClassInterface(ClassInterfaceType.None)
]
public class WeatherNotify : IWeatherNotify
{
    // Indicates Windspeed in Miles Per Hour 
    private int m_nWindSpeed = 20;

    // Define an event associated with the TornadoWarningDelegate 
    public event TornadoWarningDelegate OnTornadoWarning;

    // Constructor
    public WeatherNotify() {
    }

    public int WindSpeed
    {
       get {

          // Return the current Wind speed 
          return m_nWindSpeed;
       }
       
       set {

          // Set the WindSpeed to the new value
          m_nWindSpeed = value;

          // Check if the Wind Speed warrants an event notification 
          if(value >= 300) {
         
            try  {

              // Check if the delegate instance for the event exists
              if(null != OnTornadoWarning) {

                // Twister on the loose. Run for cover !!!. 
                // Fire the event to all the managed/unmanaged sink handlers 
                // that have registered for this event.
                
                OnTornadoWarning(m_nWindSpeed);
                
               }/* end if */

            }/* end try */
            catch(Exception ex) {

               Trace.WriteLine(ex.Message);
            }/* end catch */

          }/* end if */

       }/* end set */

    }/* End WindSpeed Property Accessors */

}/* end class WeatherNotify */

让我们稍微剖析一下代码，试着理解发生了什么。ITornadoWatchEvents 接口是事件接口，非托管接收器需要实现它才能接收事件通知。此接口包含一个方法 OnTornadoWarning，它通知客户端发生龙卷风的可能性以及当前风速。您会注意到，事件接口 ITornadoWatchEvents 标记了 InterfaceType 属性，其位置参数为 ComInterfaceType.InterfaceIsIDispatch。这是因为默认情况下，该接口将被导出到 IDL，然后导出到类型库中作为 dual 接口。脚本客户端通常在尝试接收 dual 接口时出现问题，而它们只对纯 dispinterface 友好。因此，我们注入了一个 InterfaceType 属性，其值为 ComInterfaceType.InterfaceIsIDispatch，以强制类型库生成工具为事件接口生成纯 dispinterface。您需要定义一个委托（TornadoWarningDelegate），该委托与事件接口中 OnTornadoWarning 方法的签名完全匹配。如果您在事件接口中有多个方法，则需要为每个方法定义匹配的委托。现在我们完成了事件接口和匹配的委托的定义。接下来是最重要的部分。您需要定义事件，这些事件代表您为事件接口中的方法定义的委托。

public event TornadoWarningDelegate OnTornadoWarning;

事件所代表的委托实例的名称需要与事件接口中相应方法的名称相同。这意味着代表 TornadoWarningDelegate 委托实例的事件将需要命名为 OnTornadoWarning。仅此而已。您现在可以发送事件通知了。在我们的示例中，当 WindSpeed 设置为大于或等于 300 的值时，将发送事件通知。您首先需要检查事件的委托实例是否存在，然后触发 OnTornadoWarning 事件。由于事件所代表的委托是多播委托，因此委托调用列表中的所有 COM 接收器和订阅者都将收到有关即将到来的龙卷风的通知。您可以使用以下命令构建上述 .NET 组件

csc /target:library /r:System.dll /out:WeatherNotify.dll WeatherNotify.cs

您现在可以通过 RegAsm.exe 运行该程序集来注册它，并从中生成类型库。然后，您可以在 VB6 客户端中引用此类型库，该客户端将接收事件。

regasm WeatherNotify.dll /tlb:WeatherNotify.tlb

在 VB6 客户端应用程序中处理事件

这是一个 VB 6.0 客户端，它订阅 WeatherNotify 组件的 OnTornadoWarning 事件通知。这是一个简单的Form 应用程序，它使用 WithEvents 关键字订阅事件通知。当 WindSpeed 设置为大于或等于 300 的值时，objWeatherNotify_OnTornadoWarning 子例程会接收来自 .NET 组件的事件通知。

Dim WithEvents objWeatherNotify As WeatherNotify.WeatherNotify

Private Sub Form_Load()
    ' Create an instance of the WeatherNotify Component
    Set objWeatherNotify = New WeatherNotify.WeatherNotify
End Sub

Private Sub SetWindSpeedButton_Click()

    ' Clear the warning label
    Me.LabelWarning = ""
    
    ' Set the Windspeed property in the WeatherNotify component
    objWeatherNotify.WindSpeed = Me.WindSpeed
    
End Sub

Private Sub objWeatherNotify_OnTornadoWarning(ByVal nWindSpeed As Long)
    
    ' We've received a notification from the WeatherNotify Component
    ' that there could be a Tornado on the prowl
    Me.LabelWarning = "Tornado Warning: Current Wind Speeds : " & _
                    nWindSpeed & " mph"
    
End Sub

之前，您看到 RCW 和元数据助手类如何将 Connection point 事件处理转换为委托类事件处理语义，以便 .NET 应用程序可以接收 COM 组件的事件。类似地，这里的 CCW 完成了大部分底层工作，允许非托管代码订阅 .NET 组件的事件通知，并将这些事件传递给非托管 COM 领域中各自的处理程序。

部署托管 .NET 组件的程序集

在您之前看到的示例中，您将 .NET 组件和 COM 元数据代理程序集放在了消耗它的应用程序的同一目录下，以便运行时Assembly resolver 在探测程序集时能够找到它。以这种方式部署在引用它的应用程序同一目录中的程序集称为Private Assemblies。另一种定位已引用程序集的方法是使用配置文件来告知Assembly resolver 在哪里查找已引用程序集。当.NET runtime 解析并绑定到这些私有程序集时，它不会考虑版本控制。如果您的程序集经常被大量应用程序使用，那么将其部署到一个全局存储库中是有意义的，这样其他应用程序就可以共享和使用它们。这个共享程序集存储库称为Global assembly cache (GAC)。部署在 GAC 中的程序集称为Shared Name Assemblies 或Strong Name Assemblies。这是因为这些程序集具有与之关联的唯一“Shared Name”或“Strong Name”，并且它们的身份由文本名称、版本号、公钥标记、区域信息和数字签名唯一限定。那么，我们如何为程序集生成Strong name 呢？您需要做的第一件事是使用Strong Name utility (SN.exe) 生成公钥-私钥对。您可以在命令行上运行 SN.exe 来创建一个新的随机密钥对。

sn -k MyKeyPair.snk

如果一切顺利，您应该会看到以下消息

Key pair written to MyKeyPair.snk

生成密钥对后，您需要将此密钥对与您需要生成共享名称的程序集关联起来。您可以使用 System.Reflection.AssemblyKeyFileAttribute 来实现此目的。AssemblyKeyFile 属性将 SN.exe 生成的密钥对文件与程序集关联起来，以便可以使用公钥和数字签名（使用私钥和程序集清单中的信息生成）来生成程序集的共享名称。密钥对文件通常在编译时需要，以生成完全限定的共享名称签名。但出于安全原因，大多数组织都不太愿意将其私钥传递给程序集开发人员。因此，有一个延迟签名选项可用。System.Reflection.AssemblyDelaySignAttribute 允许您稍后用私钥对程序集进行签名。

让我们将我们之前使用的 Temperature.dll .NET 程序集作为Strong named assembly。为此，您需要在组件中添加 AssemblyKeyFile 属性。如果您使用的是 Visual Studio.NET，那么在项目解决方案的 AssemblyInfo.cs 文件中，有一个占位符用于此属性和其他类似的全局属性。您可以编辑该文件，并将 MyKeyPair.snk 指定为包含密钥对的文件。

[assembly:AssemblyKeyFile("MyKeyPair.snk")]

您可以使用 System.Reflection.AssemblyVersionAttribute 指定程序集的版本信息。此属性允许您指定程序集的版本。版本通常遵循 major.minor.build.revision 模式。在 Visual Studio.NET 的 C# 类库解决方案的 AssemblyInfo.cs 文件中，通常也有此属性的占位符。您可以进入并编辑此属性。

[assembly: AssemblyVersion("1.0.0.0")]

在编辑了 AssemblyInfo.cs 文件中指定的两个属性后，重新构建 Temparature 组件。您的程序集现在具有关联的strong name。要验证这一点，请使用 Strong Name utility 发出以下命令来列出程序集的公钥和令牌。

sn -Tp Temperature.dll

返回类似以下的输出

Public key is
0024000004800000940000000602000000240000525341310004000001000100ed87f0432cbf37
fc70eec5d0e59d7e47327729cd99e257a2790c690957691f20c01b47d46a72b20b4f37a829f6ad
82e6594221bbd0193b5499ca0a83db7fc9b78bcb07177f02ef9c827688246f6073f34405e9a441
37017cf6ed52c5001272b0b820926f078bbe8705fa9d411a18d692c94be9541bb3fde38b1b1f79
5a06dde8

Public key token is f80b1601a4d8a9dd

如果对没有强名称关联的私有程序集使用相同的命令，您将看到以下结果

sn -Tp WeatherNotify.dll

WeatherNotify.dll does not represent a strongly named assembly

现在，您已准备好将 Temperature.dll 部署到Global Assembly Cache (GAC)，以便当应用程序尝试加载或使用该程序集时，程序集解析器可以在GAC 中找到它。您可以使用以下命令列出GAC 中所有程序集

gacutil -l

或者，您可以使用 shfusion.dll 中的 Windows shell 扩展，它允许您查看、添加和删除 GAC 中的程序集。如果导航到 Windows 目录下的Assembly 文件夹，此扩展将提供 GAC 中已部署程序集的视图，以及Name、Type、Version、Culture 和Public key token 等属性。要部署 Temperature.dll 程序集，只需在命令行中输入以下命令，它将部署到 GAC。

gacutil -i Temperature.dll

如果一切顺利，您将看到类似以下的消息

Assembly successfully added to the cache

您也可以将强命名程序集拖放到 shell 扩展提供的视图中，它会自动为您安装。一旦您的程序集部署到 GAC，您就不必将程序集放在应用程序的文件夹中，也不必修改配置文件来告诉解析器在哪里查找程序集。现在，程序集解析器将在 GAC 中找到该程序集。

将程序集部署到 GAC 具有优势，如不同版本号的程序集的侧面执行、程序集的单例（也称为代码页共享），允许运行时在多个应用程序使用时加载较少的程序集副本、减少加载时间，以及支持基于快速修复工程 (QFE) 的程序集的热部署。

在从 .NET 应用程序角度理解 COM 线程模型和 Apartment 部分，您看到了 .NET 应用程序如何在创建经典 COM 组件之前声明调用线程的 Apartment 亲和性。现在，让我们看看另一面。特别是，.NET 组件在从非托管 COM 感知应用程序创建时所表现出的线程行为。 .NET 组件的线程亲和性由对象生存的上下文定义。Context 本质上是由AppDomain（轻量级进程）承载的环境，对象在该环境中创建。每个上下文又承载具有共同使用需求的 objRequest，例如Thread Affinity、Object pooling、Transaction、JIT Activation、Synchronization 等。这些上下文在运行时根据对象的属性和所需拦截服务按需创建。如果存在符合对象使用规则的现有上下文，那么运行时就会在该上下文中为其提供容纳。如果找不到匹配的上下文，则会为对象创建一个新上下文来容纳它。

话虽如此，每个AppDomain 也承载一个Default context。Default Context 又承载Context Agnostic (Context Agile) 对象。这些对象不绑定到任何上下文。Context Agile 对象不需要任何属性、特殊使用策略和拦截服务。请看下表，总结了 .NET 组件在其上下文敏捷性方面的跨上下文访问场景行为

当被非托管 COM 感知客户端访问时的线程中性行为

当程序集通过 REGASM.EXE 运行时，.NET 组件如何向 COM 公告其线程模型，以便为 COM 感知客户端查找创建适当的注册表项。

InprocServer32 下的 ThreadingModel 键的值为'Both'。在经典 COM 中，将 ThreadingModel 广告为'Both' 的对象愿意移入调用者的 Apartment，无论是 STA 还是 MTA。此外，'Both' 线程对象还会聚合 Free-threaded marshaler，并为它们所在的 Apartment 提供直接接口指针引用，而不是代理。Context Agile .NET 组件（那些不继承自 ContextBoundObject 的组件）类似于聚合了 free-threaded marshaler 的线程中性 COM 对象。让我们看看当我们在非托管客户端的 Apartment 之间传递接口引用到 .NET 组件时，.NET 组件的行为。看这个简单的 C# 类，我们将把它公开给非托管 COM 客户端

using System;
using System.Runtime.InteropServices;
    
public interface IHelloDotNet {

  String GetThreadID();

}/* end interface IHelloDotNet */

[ClassInterface(ClassInterfaceType.None)]    
public class HelloDotNet : IHelloDotNet
{
   public HelloDotNet() {
   }
   
   public String GetThreadID() {

      return AppDomain.GetCurrentThreadId().ToString();
   }

}/* end class HelloDotNet */

上述类实现了 IHelloDotNet 接口的 GetThreadID 方法。此方法返回加载了该对象的AppDomain 中当前正在执行的线程的 ID。要将上述类构建为程序集并为 COM 创建适当的注册表项，请在命令行中发出以下命令

csc /target:library /out:HelloDotNet.dll HelloDotNet.cs
regasm HelloDotNet.dll /tlb:HelloDotNet.tlb

现在，我们将从 COM 感知客户端开始使用 .NET 组件。我们将使用一个 C++ 控制台应用程序，它将在其主线程（一个 STA）中创建 .NET 组件，然后通过生成两个工作线程将其传递到另外两个 Apartment（一个STA Apartment 和一个MTA Apartment）。我们将看看当对象原始接口指针跨 Apartment 传递时会发生什么。然后，我们将通过使用显式跨线程封送调用（使用 CoMarshalInterface/CoUnmarshalInterface API 系列）来查看当封送引用跨 Apartment 传递时会发生什么。看下面的代码（为简洁起见，省略了代码中的错误检查）

.......
 
#import "mscorlib.tlb"
// Import the .NET component's typelibrary
#import "HelloDotNet.tlb" no_namespace

// Worker Thread functions
long WINAPI MySTAThreadFunction(long lParam);
long WINAPI MyMTAThreadFunction(long lParam);

// Use the compiler generated smart pointer wrappers
IHelloDotNetPtr spHelloNET = NULL;

// Stream ptr that will contain the marshaled interface
IStream* g_pStream1 = NULL;
IStream* g_pStream2 = NULL;

int main(int argc, char* argv[])
{
    .......

    // Make the primary thread enter an STA
    ::CoInitialize(NULL);

    // Log the thread id 
    cout << "The Thread ID of the primary STA thread is : " 
         << ::GetCurrentThreadId() << endl;

    // Create the .NET object via the COM Interop
    hr = spHelloNET.CreateInstance(__uuidof(HelloDotNet));

    cout << "From .NET when called from the primary STA Thread : " 
         << spHelloNET->GetThreadID() << endl;

           .......

    // Marshal the interface pointer to a stream so that the
    // worker threads can get back an unmarshaled reference from it.
    hr = CoMarshalInterThreadInterfaceInStream(_uuidof(IHelloDotNet),
                                               spHelloNET,
                                               &g_pStream1);

    hr = CoMarshalInterThreadInterfaceInStream(_uuidof(IHelloDotNet),
                                               spHelloNET,
                                               &g_pStream2);

    // Create a worker thread that enters a STA
    hThreadSTA = CreateThread(NULL,0,
                             (LPTHREAD_START_ROUTINE)MySTAThreadFunction,
                              NULL,0 ,&dwThreadIDSTA);

    // Log the thread id 
    cout << "The Thread ID of the STA based Worker thread is : " 
         << dwThreadIDSTA << endl;

    // Create a worker thread that enters a MTA
    hThreadMTA = CreateThread(NULL,0,
                             (LPTHREAD_START_ROUTINE)MyMTAThreadFunction,
                              NULL,0,&dwThreadIDMTA);

    // Log the thread id 
    cout << "The Thread ID of the MTA based Worker thread is : " 
         << dwThreadIDMTA << endl;

    // Wait for both the worker threads to complete
    ::WaitForSingleObject(hThreadSTA,INFINITE);
    ::WaitForSingleObject(hThreadMTA,INFINITE);

    // Return the status
    return 0;

}/* end main */


/*
 * Worker Thread Function that enters a STA Apartment
 */
long WINAPI MySTAThreadFunction(long lParam)
{
    // Let the thread enter a STA
    ::CoInitializeEx(NULL,COINIT_APARTMENTTHREADED);

    // Invoke the method using the raw interface pointer
    cout << "From .NET when called from the STA Worker Thread (Direct Access) : " 
         << spHelloNET->GetThreadID() << endl;

    // Unmarshal the interface pointer from the stream
    IHelloDotNetPtr spHello = NULL;
    HRESULT hr = CoGetInterfaceAndReleaseStream(g_pStream1,
                                    __uuidof(IHelloDotNet),
                                        (void **)&spHello);
                                        
    if(S_OK == hr)
    {
       cout << "From .NET when called from the STA Worker Thread (Marshaled) : " 
            << spHello->GetThreadID() << endl;
    }

    // Exit from the thread
    return 0;

}/* end MySTAThreadFunction */


/*
 * Worker Thread Function that enters a MTA Apartment
 */
long WINAPI MyMTAThreadFunction(long lParam)
{

    // Let the thread enter a MTA
    ::CoInitializeEx(NULL,COINIT_MULTITHREADED);

    // Invoke the method using the raw interface pointer
    cout << "From .NET when called from the MTA Worker Thread (Direct Access) : " 
         << spHelloNET->GetThreadID() << endl;

    // Unmarshal the interface pointer from the stream
    IHelloDotNetPtr spHello = NULL;
    HRESULT hr = CoGetInterfaceAndReleaseStream(g_pStream2,
                                     __uuidof(IHelloDotNet),
                                         (void **)&spHello);

    if(S_OK == hr)
    {
       cout << "From .NET when called from the MTA Worker Thread (Marshaled) : " 
            << spHello->GetThreadID() << endl;
    }

    // Exit from the thread
    return 0;

}/* end MyMTAThreadFunction */

控制台应用程序运行时会得到如下输出

The Thread ID of the primary STA thread is : 2220
From .NET when called from the primary STA Thread : 2220
The Thread ID of the STA based Worker thread is : 2292
The Thread ID of the MTA based Worker thread is : 2296
From .NET when called from the STA Worker Thread (Direct Access) : 2292
From .NET when called from the STA Worker Thread (Marshalled) : 2292
From .NET when called from the MTA Worker Thread (Direct Access) : 2296
From .NET when called from the MTA Worker Thread (Marshalled) : 2296

请注意，对于所有这些调用，客户端的调用线程和.NET 组件中实际调用方法的线程之间没有线程切换。换句话说，.NET 组件是Context agile，并且始终在调用者的线程中执行。从上面的代码片段可以看出，封送对象引用（使用 CoMarshalInterThreadInterfaceInStream/CoGetInterfaceAndReleaseStream 等跨线程封送 API）的效果与在 Apartment 之间传递直接对象引用相同。最终，接收 Apartment 会获得一个Apartment-neutral 接口指针，可用于调用 .NET 组件。该 .NET 组件表现出所有类似于聚合了 free-threaded marshaler 的Both 线程的经典 COM 组件的行为。

结论：COM 在功能强大的 .NET 世界中的地位

在本文的第一部分，我们讨论了如何将经典 COM 组件公开给在Common Language Runtime (CLR) 范围内执行的 .NET 应用程序。我们看到了 COM Interop 如何无缝地允许您在托管代码中重用现有的 COM 组件。然后，我们简要介绍了如何同时使用early binding 和late binding 调用 COM 组件，以及如何进行运行时类型检查和动态类型发现。我们深入了解了委托在 .NET 中的工作原理、它们在 .NET 事件处理模型中的作用，以及 COM Interop 如何充当适配器，将经典 COM 中的连接点事件处理模型与 .NET 中的委托类事件处理模型连接起来。我们讨论了如何将 COM 集合公开给 .NET 应用程序，并使用 C# 的 foreach 语法轻松迭代集合元素。然后，我们研究了 IDL 文件中的方向属性如何映射到 C# 中相应的定向参数类型。我们还学习了 .NET 应用程序使用继承和组合重用经典 COM 组件的一些选项。最后，我们看到了托管线程在调用 COM 组件时如何声明其 Apartment 亲和性。

在本文的后半部分，我们深入探讨了 .NET 时代之前的 COM 感知客户端如何像使用经典 COM 组件一样使用 .NET 组件。我们看到了CCW 和CLR 如何在编程上无缝地实现这一点。我们简要探讨了使用属性将元数据发出到 .NET 类型以根据您的需求定制和微调生成类型库的可能性。我们研究了两个世界中的异常处理机制是如何关联的。我们还讨论了如何在非托管事件接收器中从 .NET 组件接收异步事件通知。然后，我们将注意力转向了部署选项，以及如何将 .NET 组件部署为共享程序集。最后，我们讨论了 .NET 组件的线程中性行为，并看到 Context-agile .NET 组件类似于聚合了 free-threaded marshaler (FTM) 的经典 COM 'Both' 线程组件。

作为一名 COM 开发人员，您可能会想，继续编写 COM 组件是否明智，或者直接过渡到 .NET 世界，使用 C#、VB.NET 或您喜欢的任何生成CLR 兼容托管代码的语言，将所有组件和业务逻辑代码包装为托管组件。在我看来，如果您有大量无法在短期内迁移到托管代码的 COM 代码，那么利用 Interop 的能力从 .NET 应用程序重用现有的 COM 组件是有意义的。但是，如果您从头开始编写新的业务逻辑代码，那么最好使用生成CLR 托管代码的语言之一，将您的代码包装为托管组件。这样，您就可以避免在托管和非托管边界之间转换时产生的性能损失。最终，我们 COM 开发人员不必绝望。我们心爱的 COM 组件将继续与 .NET 应用程序很好地配合。 .NET 框架提供的工具以及运行时提供的 COM Interop 机制使得从编程角度来看，无论您的 .NET 应用程序访问的是经典 COM 组件还是托管组件，都变得无缝。所以，本质上，COM 与这个崭新而强大的 .NET 世界的结合应该会是幸福的，而我们都喜爱和熟悉的 COM 仍将是我们生活的重要组成部分。

引言

"COM 编程模型的几乎所有方面都得以保留（接口、类、属性、上下文等等）。有些人可能认为 COM 已死，仅仅因为它认为 CLR 对象不依赖于 IUnknown 兼容的 vptrs/vtbls。我认为 CLR 为我花了七年时间工作的编程模型注入了新的生命，我知道还有其他程序员有同样的感受。"

- Don Box，在他的 MSDN Magazine (2000 年 12 月) 的 'House of COM' 专栏中。

"COM 以精神而非肉体而存活！"

- Peter Foreman，在 Developmentor DOTNET 邮件列表中。

参考文献

• House of COM - 将本机代码迁移到 .NET CLR - MSDN Magazine，2001 年 5 月。
• House of COM - COM 已死？ - MSDN Magazine，2000 年 12 月。

致谢

我谨向 Tom Archer 表示最诚挚的感谢，感谢他鼓励我写作，并将本教程的一部分收录在他的书 Inside C# 中。我还想感谢 Developmentor DOTNET 邮件列表 的精彩人士，他们每天为 .NET 开发者提供思考。