com4:ComServer

Declara um ponto de extensão de pacote do tipo windows.comServer. A extensão comServer pode incluir registros de classe, incluindo detalhes de ativação para os servidores que implementam essas classes, e registros ProgId e TreatAsClass, que fornecem identificadores adicionais usados para referenciar essas classes em runtime.

Hierarquia de elementos

do pacote

    aplicativos <>

          <application>

              extensões de <>

                    <com4:Extension>

                         <com4:ComServer>

    extensões de <>

          <com4:Extension>

               <com4:ComServer>

Sintaxe

<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>

Chave

{} intervalo específico de ocorrências

Atributos e elementos

Atributos

Nenhum.

Elementos filho

Elementos pai

Observações

Em pacotes de vários aplicativos, é importante colocar o registro do servidor COM no elemento de manifesto aplicativos/aplicativo correto, pois os processos de servidor COM serão executados com a identidade do elemento Application/Application ancestral.

Os servidores COM registrados no manifesto sempre obtêm o comportamento de AAP (Activate As Package), o que significa que o servidor COM é executado com o token padrão de sessão do usuário com declarações de pacote e aplicativo adicionadas. Isso é diferente do comportamento de ativação padrão de servidores COM registrados clássicamente, nos quais o servidor COM é executado com o token do cliente. Para a maioria dos aplicativos, essa diferença não será perceptível porque os clientes normalmente são executados com o token padrão de sessão do usuário. Não há suporte para outros comportamentos de ativação, como RunAs.

É possível ter várias extensões de comServer no elemento Applications/Application, mas na maioria dos casos isso não é necessário nem recomendado. Um exemplo de um caso de borda em que várias extensões de comServer são necessárias é se um pacote precisa de alguns dos registros para ter CompatMode="clássico", enquanto outros têm CompatMode="modern", a única maneira de fazer isso é dividi-los entre extensões.

Alterações na extensão com4

A sintaxe da extensão com4 é um novo superconjunto da sintaxe de extensão com anterior. Esta versão da sintaxe dá suporte à mesma estrutura que as versões mais antigas da sintaxe, em que os registros de classe são representados por elementos ExeServer/Class, SurrogateServer/Class, ServiceServer/Class, InProcessServer/Class, InProcessHandler/Class ou ManagedInProcessServer/Class.

A nova sintaxe também dá suporte a estruturas alternativas, em que:

• ExeServer/ClassReference, SurrogateServer/ClassReference, ServiceServer/ClassReference, InProcessServer/ClassReference, InProcessHandler/ClassReference ou elementos ManagedInProcessServer/ClassReference fazem referência a elementos de classe de nível superior

e/ou

• Os elementos SurrogateServer/InProcessServerClassReference fazem referência a elementos InProcessServer/Class (como alternativa, InProcessServer/ClassReference) ou ManagedInProcessServer/Class (como alternativa, ManagedInProcessServer/ClassReference).

A principal finalidade da nova estrutura de sintaxe é habilitar combinações de servidor em processo, manipulador em processo e registros de servidor fora do processo para o mesmo CLSID, como é possível e com suporte com o layout clássico do Registro. Para obter mais informações sobre o layout do registro COM, consulte de chave CLSID.

Requisitos