Microsoft のオールインワン コード サンプル: CSExeCOMServerに記載されているように、C# でプロセス外 COM サーバーを作成する場合、サーバーで (クライアントによって) 作成されるオブジェクトのスレッド モデルを制御するのは難しいようです。
作成されるオブジェクトは、WPF オブジェクトを使用するという事実のために STA に存在する必要があり、そのファクトリは、ExeCOMServer.csの 95 行目で示されているように登録されており、以下に貼り付けられています...
private void PreMessageLoop()
{
//
// Register the COM class factories.
//
Guid clsidSimpleObj = new Guid(SimpleObject.ClassId);
// Register the SimpleObject class object
int hResult = COMNative.CoRegisterClassObject(
ref clsidSimpleObj, // CLSID to be registered
new SimpleObjectClassFactory(), // Class factory
CLSCTX.LOCAL_SERVER, // Context to run
REGCLS.MULTIPLEUSE | REGCLS.SUSPENDED,
out _cookieSimpleObj);
if (hResult != 0)
{
throw new ApplicationException(
"CoRegisterClassObject failed w/err 0x" + hResult.ToString("X"));
}
ただし、CreateInstance 関数は常に MTA 内の新しいスレッドで呼び出されます。ローカル サーバーのメイン スレッドが STA スレッドとしてマークされている (および検証されている) ことは問題ではないようです。
この問題に関するすべての資料は、作成されたオブジェクトのアパートメントが、ファクトリが登録されたスレッドのアパートメントと一致する必要があることを示唆しています。実際、これは ATL COM サーバー (Managed C++ と混合してオブジェクトを作成する) を使用する場合に当てはまるようですが、このメソッドは、初期化パラメーター、特に COM スレッド モデルであるワークフローに新しいスレッドを挿入しているように見えます。 、変更可能ではないようです。
大部分がアンマネージ コードで記述された COM サーバーに頼らずに、この問題を解決した人はいますか。