出于好奇，在 Visual Studio 的 Reference Manager 中添加引用作为“程序集框架”与将其添加为“COM 类型库”有什么区别？我意识到 COM 类型库并非对所有引用都可用。
例如：如果我想使用 Microsoft Speech API，我可以将它用作“组装框架”：
或者我可以将它用作“COM 类型库”：
我不打算使用 Microsoft Speech API 实现任何东西。这只是作为一个例子来详细说明我的要求。
使用这两个选项有什么区别？
他们指的是同一个库吗？我看到两个屏幕截图的右窗格中的版本号不同。
提前致谢！
【问题讨论】：
标签： .net visual-studio reference
您得到了一个略带考古学的观点，这些是程序员在 .NET 可用之前使用的 api。在这种情况下，对于 SAPI，语音 API 自 1995 年左右就出现了。它的 COM 包装器并没有完全过时，当您使用 C++ 或 Javascript 等脚本语言编写代码时仍然使用它。
Microsoft 决定为其创建一个更加以 .NET 为中心的包装器。公平地说，当您想监听事件时，COM 包装器做得不好。不是唯一的例子，其他好的例子是 System.Management（包装 WMI）、System.Messaging（包装 MQ）、System.Data.OleDb（包装 ADO）、System.DirectoryServices（包装 AD）。
没有令人信服的理由支持 COM 包装器，System.Speech 做得非常好并且是完整的。通常，Microsoft 内部强烈推动隐藏 COM，对其进行编程可能会相当不愉快，尤其是在它不是自动化子集的情况下。直接对 WASAPI 或 DirectX 等核心 API 进行编程几乎没有什么乐趣。
最完整的包装工作可能是通用 Windows（又名 WinRT，又名商店应用程序，又名现代 UI，又名 UWP），其核心是完全现代和彻底的 COM。隐藏得很好，“语言投影”是一个非常巧妙的技巧。否则，您可以获得 Javascript 应用程序直接与 C++ 组件对话的基本方式。以及错误报告如此糟糕的基本原因:)
【讨论】：
使用这两个选项有什么区别？
它们是完全不同的平台。 COM 已经存在了很长时间，并且在开发 .NET 之前用于为 Windows 应用程序提供通用功能。它现在被认为是“遗产”，并且更难以接受。
对于本论坛来说，两者之间的差异太多了，但它们就像比较 Android 和 iOS 的应用程序一样——它们是供两个不同的客户使用的。一些应用程序适用于两者，但许多应用程序适用于其中之一。一些库向两者公开方法；有些只是其中之一。
如果您从 .NET 应用程序中引用库，您将始终希望引用 .NET 程序集，除非在极少数情况下（例如，如果 COM 库具有与程序集不同的功能）。
他们指的是同一个库吗？
不是直接的 - 可能有 wrappers 用于其中一个或另一个在下面使用相同代码，但在互操作级别上它们并不相同。
【讨论】：
Reference Manager 中列出的COM 对象位于工作站的什么位置？我相信“组装框架”部分中列出的项目来自 GAC。在Microsoft Speech API 示例中，COM 类型库是否来自%windir%\System32\Speech\Common\sapi.dll？