.NET的通用语言运行库（CLR）提供的许多服务和经典COM所能提供的的很多服务相同，例如使用不同语言所实现的组件之间的互用性。但是，CLR无法取代COM+所提供的服务，例如自动事务处理、即时（JIT）对象激活和对象池。而.NET框架和CLR所提供的机制能够让.NET的类型使用这些COM+的服务。在本文中，我会讲到一些COM+的基础知识，并解释.NET的类型是如何能够使用COM+的服务的。然后，我会向你示范如何实现一个使用COM+自动事务处理的.NET类型。COM+将组件组织成为叫做应用程序的组。应用程序有两种类型，其区别在于它们所包含组件的实例在被激活的时候在哪里运行。库应用程序组件的实例运行的进程和创建这个实例的客户的进程相同。而服务器应用程序组件的实例运行在另一个由COM+所提供的进程里。
COM+应用程序里的组件叫做配置组件。COM+的运行库会截取客户对每一个配置组件的调用，它还会执行预处理和后处理，为组件提供配置服务。通过操控COM+的用于维护配置组件每个实例的上下文，这个组件能够影响后处理。
在需要对组件使用自动事务处理服务的简单情形下，COM+会在其截取对组件实例调用的时候创建一个事务处理，然后把这个调用转发给这个组件。当这个组件访问数据源的时候，资源管理器会自动地加入这个事务处理。在返回以前，组件会通过其上下文告诉COM+这个事务处理是否已经准备好可以执行了或者它是否应该被中止。当控件返回到COM+的时侯，COM+会检查组件在其上下文里设置的状态，并在返回到客户以前执行或者终止这个事件处理。
为自动事件处理所配置的组件其实也是为JIT激活所配置的，这将保证组件实例只在其被使用的时候才是存活的。当客户创建配置组件实例的时侯，COM+会介入并以透明的方式向客户提供stub。当客户通过这个stub调用方法的时候，COM+创建组件的实例并转发这个调用。当方法返回的时候，COM+会在返回给客户之前销毁这个实例。只有COM+上下文会保留在客户调用之间。通过把组件实例的数量限制到当时所需要的数目，JIT激活让服务器能够支持更多的并发客户。如果创建组件实例的花费太高，那么组件就要按对象池来配置，这样就能让COM+解除实例（而不是销毁它们）并把它们保存在对象池里，以便以后能够被再次激活。
关于配置组件的信息被保存在两个地方。组件的标准COM信息被保存在注册表里的HKEY_CLASSES_ROOT下。组件的COM+配置信息被单独保存在叫做RegDB的数据库里。注册表信息和RegDB合起来叫做COM+目录。
