com2:ComServer

Déclare un point d’extension de package de type windows.comServer. L’extension comServer peut inclure les types d’inscriptions suivants : ServiceServer, ExeServer, SurrogateServer, ProgId ou TreatAsClass.

Hiérarchie d’éléments

<Paquet>

    <Applications>

         <Application>

              <Extensions>

                   <com2:Extension>

                        <com2:ComServer>

Syntax

<com2:ComServer>

  <!-- Child elements -->
  com:ExeServer{0,1000},
  com:SurrogateServer{0,1000},
  com:ProgId{0,10000},
  com:TreatAsClass{0,10000},
  com3:ServiceServer{0,1000},
  com3:ExeServer{0,1000},
  com3:SurrogateServer{0,1000},
  com3:ProgId{0,10000},
  com3:TreatAsClass{0,10000}

</com2:ComServer>

Clé :

{} plage spécifique d’occurrences

Attributs et éléments

Attributs

Aucune.

Éléments enfants

Éléments parents

Remarques

Dans les packages multi-applications, il est important de placer l’inscription du serveur COM sous l’élément manifeste Applications/Application approprié, car les processus serveur COM s’exécutent avec l’identité de l’élément Applications/Application ancêtre.

Les serveurs COM inscrits dans le manifeste obtiennent toujours le comportement d’activation en tant que package (AAP), ce qui signifie que le serveur COM s’exécute avec le jeton par défaut de la session utilisateur avec des revendications de package et d’application ajoutées. Cela diffère du comportement d’activation par défaut des serveurs COM classiquement inscrits, dans lesquels le serveur COM s’exécute avec le jeton du client. Pour la plupart des applications, cette différence ne sera pas perceptible, car les clients s’exécutent généralement avec le jeton par défaut de la session utilisateur. D’autres comportements d’activation, tels que les runAs, ne sont pas pris en charge.

Il est possible d’avoir plusieurs extensions comServer sous l’élément Applications/Application, mais ce n’est ni nécessaire ni recommandé.

Configuration requise