Visual Studioリファレンスマネージャー - アセンブリフレームワークとCOMタイプライブラリ

Question

Visual StudioのReference Managerの参照を「アセンブリフレームワーク」として追加すると「COMタイプライブラリ」として追加することとの違いは何ですか？ "？ COM Typeライブラリはすべてのリファレンスで利用できないことに気付きました。例えば

：

または私は「COMタイプライブラリ」として使用することができます：私はMicrosoft音声APIで作業したい場合は、私は「組立フレームワーク」として使用することができます：

私はMicrosoft音声APIで何を実装するために見ているわけではありません。これは私が求めているものを具体化するための例としてとらえられました。

これらのオプションを使用する違いは何ですか？

同じライブラリを指していますか？私は2つのスクリーンショットの右側のペインでバージョン番号が異なることを確認します。

ありがとうございます！

Answer 1

これらのオプションの違いは何ですか？

これらは完全に異なるプラットフォームです。 COMはずっと長く存在し、.NETが開発される前にWindowsアプリケーションに共通の機能を提供するために使用されていました。それは今や「遺産」と考えられています。

この2つの違いは、このフォーラムでは多すぎますが、AndroidとiOSのアプリを比較するようなものです。これらは2つの異なるクライアントが使用するためのものです。どちらのアプリも両方に存在しますが、多くのアプリはどちらか一方のために存在します。いくつかのライブラリは両方にメソッドを公開しています。いくつかの唯一のまたは他の。

.NETアプリケーションからライブラリを参照する場合は、非常にまれな場合を除いて、常に.NETアセンブリを参照することができます（たとえば、COMライブラリにアセンブリ以外の機能が異なる場合など）。

同じライブラリを指していますか？

直接外 - ラッパー一つまたは下に同じコードを使用することを他のためがあってもよいが、相互運用レベルでそれらが同一ではありません。

Answer 2

あなたは若干考古学的な見解を示しています。それらは、.NETが利用可能になる前にプログラマーが使用していたものです。この場合、SAPIのために、〜1995年以来周りにあったSpeech API。そのためのCOMラッパーは、まったく時代遅れではなく、例えばC++やJavascriptのようなスクリプト言語でコードを書くときにもそれを使用します。

Microsoftは、より.NET中心のラッパーを作成することに決めました。公正な呼び出しでは、イベントを聴きたいときにCOMラッパーは素晴らしい仕事をしません。唯一の例ではなく、System.Management（Wrapをラップする）、System.Messaging（MQをラップする）、System.Data.OleDb（ADOをラップする）、System.DirectoryServices（ADをラップする）などがあります。

COMラッパーを支持する魅力的な理由はありませんが、System.Speechはかなりうまくいって完了です。一般に、COMを隠すためにマイクロソフト内部に強いプッシュがあります。プログラミングは、特にAutomationサブセットではない場合、かなり不愉快なことがあります。 WASAPIやDirectXのようなコアAPIを直接プログラミングすることにはほとんど喜んでいません。

最も包括的なラッピングジョブは、Univeral Windows（別名WinRT、別名Storeアプリケーション、別名UWP）です。徹底的にモダンで完全なCOMです。非常にうまく隠されていて、「言語の投影」はかなりきちんとしたトリックです。それ以外の場合は、JavascriptアプリケーションでC++コンポーネントと直接対話する基本的な方法です。そして、エラー報告がとても厄介な基本的な理由:)