出于好奇，将Visual Studio的Reference Manager中的引用添加为“组装框架”与将其添加为“COM类型库”有什么区别“？我意识到COM类型库不适用于所有引用。Visual Studio参考管理器 - 组装框架与COM类型库
例如：如果我想用的Microsoft Speech API的工作，我可以把它作为一个“组件框架”：
或者，我可以把它作为一个“COM类型库” ：
我不是在寻找实现与微软Speech API的任何东西。这只是作为一个例子来阐述我所问的。
使用这两个选项之间有什么区别？
它们指的是相同的库吗？我看到两个屏幕截图中右侧窗格中的版本号不同。
在此先感谢！
使用这两个选项之间有什么区别？
它们是完全不同的平台。 COM已经存在了很长时间，并且在开发.NET之前被用来为Windows应用程序提供通用功能。它现在被认为是“遗产”，而且更难以消除。
这两个论坛之间的差异对于这个论坛来说太多了，但它们就像比较Android和iOS的应用程序 - 它们是为了供两个不同的客户端使用。有些应用程序适用于这两种应用程序，但许多应用程序都适用于其中一种。有些库向两种方法公开方法;一些只有一个或另一个。
如果您是从.NET应用程序引用库，那么除非极少数情况下（例如，如果COM库具有程序集不具备的其他功能），否则您总是需要引用.NET程序集。
它们指的是相同的库吗？
不能直接 - 有可能是包装一个或下使用相同的代码其他，但在互操作水平，他们是不一样的。
您正在获得一个轻微的考古学视图，这些是程序员在.NET变得可用之前使用的apis。在这种情况下，对于SAPI来说，Speech API自1995年以来一直存在。它的COM包装并不完全过时，当你用C++或JavaScript等脚本语言编写代码时仍然使用它。
微软决定为它创建一个更以.NET为中心的包装。公平的呼叫，当你想要听事件时，COM包装器不会做很棒的工作。不是唯一的例子，其他好的例子是System.Management（包装WMI），System.Messaging（包装MQ），System.Data.OleDb（包装ADO），System.DirectoryServices（包装AD）。
没有令人信服的理由，有利于COM包装，System.Speech做得已经相当好，就完成了。总的来说，微软内部强烈推动隐藏COM，编程它可能是相当不愉快的，特别是如果它不是自动化子集。直接编程核心API如WASAPI或DirectX几乎没有什么乐趣。
最完整包装的工作可能是万能的Windows（又名WinRT的，又名商店的应用程序，也称为现代UI，又名UWP），彻底的现代和彻底COM的核心。隐藏得很好，“语言投射”是一个非常巧妙的技巧。否则，您可以直接获得Javascript应用程序与C++组件进行对话的基本方式。而根本原因的错误报告是如此糟糕:)
那么，在'参考Manager'列出的COM对象所在的工作站上？我相信“汇编框架”部分列出的项目来自GAC。在'Microsoft Speech API'示例中，COM类型库是否来自'％windir％\ System32 \ Speech \ Common \ sapi.dll'？ – slayernoah
或者参考管理器中的COM类型取自GAC的其他方式？ – slayernoah
COM库在系统中“注册”，几乎可以在任何位置。所有这些链接都存储在注册表中。没有简单的方法来确定COM库的物理位置。它需要在注册表中进行一些面包屑搜索，这是不愉快的。 –