（私は最初にウィザードを実行したとき、私は「マージプロキシ/スタブ」オプションを選択しましたので。）私はVS2008を使用してATL COMオブジェクトを生成していると、コードが_MERGE_PROXYSTUBと呼ばれる定義への参照が含まれてい_MERGE_PROXYSTUBのポイントは何ですか？
のポイントは何ですかプロキシ/スタブ？私がマージオプションを選択しなかった場合、代わりに別のMyControlPS.DLLが得られます。これはいつ使用されますか？
FWIW _MERGE_PROXYSTUBで囲まれたコードをすべて削除すると、コントロールが登録されて正常に動作しているようです。デバッグビルドでは_MERGE_PROXYSTUBも定義されていませんが、それでも問題なく動作します。
プロキシ/スタブなしでも対応できますか？
COMオブジェクトと異なるスレッドモデルを使用してアプリケーションからCOMオブジェクトを呼び出す場合は、プロキシ/スタブが必要です。
たとえば、特定のスレッドモデル（どちらが覚えていないか）を使用するアプリケーションによってロードされるプラグインがありますが、COMオブジェクトはマルチスレッドアパートメント（MTA）です - プロキシ/スタブは関数呼び出しが行われたときにオブジェクト間でデータを整列するのに必要なスレッド化モデルの規則に従います。
これらのルールが破られている場合、COMが例外をスローするか、そのようなRPC_E_WRONG_THREAD
として失敗HRESULTを返します。いずれかのマージ、プロキシ/スタブオプションをチェックしない場合は、Visual Studioは別々に生成別のDLLにビルドするプロキシ/スタブのプロジェクト。これにより、必要な場合には展開が難しくなりますが、スレッドモデルの問題の影響を受けない場合は、基本的に無視できます。 COMオブジェクトを呼び出すアプリケーションは、あなたのオブジェクトと同じスレッドモデルを使用している場合
ですから、プロキシ/スタブなしで行うことができます
ラリー・オスターマンは、彼のブログでthreading modelsに読める紹介しています。
また、インターフェイスにタイプライブラリに適したタイプ（BSTR、VARIANTなど）のみが含まれ、IDLのライブラリブロックに表示される場合は、「タイプライブラリの整列化」を選択して、提供されたプロキシ/スタブは、タイプライブラリからのメタデータを使用します。
インターフェイスがライブラリブロック内に置かれ、DllRegisterServerがタイプライブラリを登録するようにカスタマイズされている場合（正しくリコールするとTRUEをXxxModule :: DllRegisterServerに渡します）、必要に応じて、記述されているとおりにインターフェイスがシステムによってマーシャリングされますジョンSiblyによって。
この時点では、プロキシ/スタブは使用されていないため、_MERGE_PROXYSTUBは効果がありません。