com4:ComServer

windows.comServer 型のパッケージ拡張ポイントを宣言します。 comServer 拡張機能には、これらのクラスを実装するサーバーのアクティブ化の詳細を含むクラス登録や、実行時にこれらのクラスを参照するために使用される追加の識別子を提供する ProgId と TreatAsClass の登録が含まれる場合があります。

要素の階層

<パッケージ>

    <アプリケーション>

         <Application>

              <拡張機能>

                   <com4:Extension>

                        <com4:ComServer>

構文

<com4:ComServer>

<!-- Child elements -->
  Class{0,1}
  ExeServer{0,1}
  ServiceServer{0,1}
  SurrogateServer{0,1}
  TreatAsClass{0,1}
  ProgId{0,1}
  InProcessServer{0,1}
  InProcessHandler{0,1}
  ManagedInProcessServer{0,1}
  com5:InProcessServer{0,1}
  com5:InProcessHandler{0,1}

</com4:ComServer>

キー

{} 特定の出現範囲

属性と要素

属性

なし。

子要素

親要素

注釈

マルチアプリケーション パッケージでは、COM サーバーの登録を適切な Applications/Application マニフェスト要素の下に配置することが重要です。COM サーバー プロセスは先祖の Applications/Application 要素の ID で実行されるためです。

マニフェストに登録されている COM サーバーは、常にパッケージとしてアクティブ化 (AAP) 動作を受け取ります。つまり、COM サーバーは、パッケージとアプリケーション要求が追加されたユーザー セッションの既定のトークンで実行されます。 これは、クライアントのトークンを使用して COM サーバーが実行される、従来登録された COM サーバーの既定のアクティブ化動作とは異なります。 ほとんどのアプリケーションでは、通常、クライアントはユーザー セッションの既定のトークンを使用して実行されるため、この違いは目立ちません。 RunAs などの他のアクティブ化動作はサポートされていません。

Applications/Application 要素の下に複数の comServer 拡張機能を含めることも可能ですが、ほとんどの場合、これは必要でも推奨もされません。 複数の comServer 拡張機能が必要なエッジ ケースの例として、パッケージで CompatMode="classic" を持つ登録の一部が必要な場合と、CompatMode="モダン" を持つものもありますが、これを行う唯一の方法は拡張機能間で分割することです。

com4 拡張機能の変更

com4 拡張構文は、前の com 拡張構文の新しいスーパーセットです。 このバージョンの構文では、以前のバージョンの構文と同じ構造がサポートされています。クラスの登録は、ExeServer/Class、SurrogateServer/Class、ServiceServer/Class、InProcessServer/Class、InProcessHandler/Class、または ManagedInProcessServer/Class 要素によって表されます。

新しい構文では、次の代替構造体もサポートされています。

• ExeServer/ClassReference、SurrogateServer/ClassReference、ServiceServer/ClassReference、InProcessServer/ClassReference、InProcessHandler/ClassReference、または ManagedInProcessServer/ClassReference 要素は、最上位クラス要素を参照します

および/または

• SurrogateServer/InProcessServerClassReference 要素は、InProcessServer/Class (または InProcessServer/ClassReference) 要素または ManagedInProcessServer/Class (または ManagedInProcessServer/ClassReference) 要素を参照します。

新しい構文構造のメインの目的は、可能な限り、従来のレジストリ レイアウトでサポートされている同じ CLSID に対して、インプロセス サーバー、インプロセス ハンドラー、プロセス外サーバー登録の組み合わせを有効にすることです。 COM レジストリ レイアウトの詳細については、「 CLSID キー」を参照してください。

必要条件