创建 COM+ 应用程序时，向导会提供库和服务器应用程序之间的选择。
服务器应用程序在一个单独的进程中被激活，这可用于廉价地将 64 位消费者与 32 位进程内 COM 组件进行互操作。
在调用者进程中激活的库应用程序有什么用？为什么要使用它们而不是普通的旧的进程内 COM 服务器？
问问题
1933 次
2 回答
3
有几种：
性能 - 它更快一点，因为您不必通过消息自动化（编组和解组）
隔离 - 如果许多不同的应用程序正在使用该库，那么每个应用程序都将拥有自己的副本。在处理 MTA（多线程单元）和 STA（单线程单元模型）之间的差异时，这一点是最重要的
IN-PROC 服务器（实际上是进程外，调用者进程外）由所有不同的调用者共享（这是获得廉价 IPC/RPC 的好方法）
好的，我正在编辑更多定义和更多参考：
- 上下文实际上是围绕对象使用的所有状态。
- 因果关系实际上是一个类似线程的概念，表示在上下文中使用对象。（“因果关系是 COM 方法调用的分布式链，它跨越任意数量的进程中的任意数量的上下文”——来自 ISBN：0-201-61594-0）
这些概念在 Tim Ewald 的优秀著作“Transactional COM+”的第 2 章的大约 30 页中进行了讨论 ISBN：0-201-61594-0
所以直接引用第 2 章的总结：“一个对象可以使用对象上下文与它的上下文交互，并使用调用上下文与给定的因果关系。这两个对象提供了与 COM+ 运行时服务交互的接口。这种编码风格，' “进入上下文”使 COM+ 开发与经典的 COM 开发大不相同。”
最后，第 2 章讨论了“为什么是库应用程序？”，（这与您的问题不同，为什么不只是普通的旧 COM？）他的论点主要表明使用 COM 对象的相同原因，1. 每个应用程序都有自己的实例。2. 加载到非 DLLhost.exe 进程中。3. 更少的开销。4. 普通对象的简单部署。
所以底线是，如果您不是分布式的，并且本质上不是事务性的，那么使用 COM+ 相对于 COM 可能没有真正的优势。但是，如果您编写一个 COM+ 应用程序并将其部署为一个 LIBRARY 应用程序，它的行为就会更像一个 COM 组件。
希望有帮助。
于 2009-11-19T19:40:31.620 回答
1
主要目的是从COM+ 应用程序上下文中受益。
CoGetObjectContext for IObjectContextor IObjectContextActivitywill return E_NOTINTERFACE 从纯进程内组件，而它将成功地在 COM+ 库应用程序（当然还有服务器应用程序）中工作。
安全上下文也可通过CoGetCallContext获得ISecurityCallContext。
它与性能或隔离无关。
作为一个站点说明，检查 COM+ 库应用程序可用的一种方法是运行 dcomcnfg.exe 导航到组件服务、计算机、我的电脑、COM+ 应用程序，创建一个新的库应用程序并检查哪些仍然启用（而不是服务器应用）。
于 2015-06-15T08:30:26.223 回答