Simulando o lado lateral para o processo ActiveX

Question

Estamos adaptando o aplicativo relativamente complicado do lado do cliente (ActiveX / .NET / Delphi / C ++ / com) para usar o SXS para obter implantação e isolamento não administrativos de versões mais antigas do nosso produto.

Conseguimos atingir esse objetivo para quase todos os nossos componentes do Proc, como nossa interface do usuário .NET, Delphi UI e os servidores COM que usamos no PROC, compondo um arquivo de manifesto que descreveu todas as bibliotecas usadas por nosso processo, sem registro no cliente de qualquer um dos componentes (quase).

E aqui vem a quase parte: no momento, nosso aplicativo invoca (da porção C ++) e fora do Proc ActiveX Server (Delphi ActiveX EXE), que por sua vez invoca outro conjunto de servidores do Proc ActiveX (plugins de terceiros, Qualquer coisa vai aqui, Delphi, C ++, qualquer coisa, desde que esteja fora de Proc ActiveX exe e implementa nossas interfaces).

Como sabemos O SXS não suporta os servidores Proc ActiveX. E não podemos usar esses objetos como nos servidores Proc com em nosso processo principal, porque isso exigiria uma grande reescrita de nosso aplicativo e, até pior quebrar o que não podemos permitir.

Nós tropeçamos Este artigo que descreve como o iHTMLDocument2 pode ser extraído de uma janela do Internet Explorer em execução em um processo separado. O que nos fez pensar nessa abordagem:

Criaríamos um aplicativo / processo secundário de satélite que executará o ActiveX como no Process Server. Então vamos usar LResultFromObject e ObjectFromlResult Para transferir uma referência do objeto ActiveX do aplicativo de satélite para o processo de aplicação principal. O aplicativo de satélite terá seu próprio arquivo de manifesto, que permitirá que ele seja executado no modo SXS.

A mesma abordagem será adotada para se comunicar entre este Delphi ActiveX EXE e os plugins de terceiros do Acivex EXE

Existe uma solução alternativa, que, no momento, não preferimos sobre a solução proposta acima, que é usar as classes de remoção .NET e .NET COM Proxy para abrir o canal de comunicação entre os dois processos, traduzindo a solicitação COM para .NET Remoção e volta ao COM no segundo processo.

Então aqui vem a pergunta:

1. O que você acha dessa abordagem?
2. Você vê uma solução melhor para o problema?

Answer 1

É possível fazer. O que é preciso:

• Um aplicativo precisa iniciar um servidor em si, em vez de confiar no COM para fazê -lo. Você não precisa da indireção extra fornecida pelo Registro, basta usar CreateProcess ().
• Um servidor deve registrar suas fábricas de classe em seu método Main () com CoreGisterClassObject ().
• IMPORTANTE: O CLSID que ele usa para cada fábrica deve ser alterado para ser único para cada instância de serviço. Isso garante que o cliente se conecte ao servidor correto. Eu simplesmente xori o ID do processo com um clsid de fábrica de classe. O cliente conhece o ID do processo também pode fazer a mesma alteração.
• O aplicativo deve ligar para o coCreateInstance () em um loop com uma chamada de sono () para esperar a fábrica de objetos aparecer. Não declare fracasso até que pelo menos 60 segundos se passaram (isso me mordeu).
• Tanto o aplicativo quanto o servidor precisam de um manifesto que contém um <file> elemento para cada dll proxy/stub e <comInterfaceExternProxyStub> elementos para cada interface que é removida.

Answer 2

Alex,

Nobugz está certo, você pode acessar a tabela de objetos em execução para criar uma instância de um objeto COM a partir de um processo atualmente em execução do seu exe de automação Delphi.

No entanto, encontrei um grande problema que não posso explicar. Só posso acessar o objeto através do método de despacho da variante ao trabalhar dessa maneira.

Basicamente, se meu X EXE ativo não estiver registrado, recebo um erro "interface não suportada" se tentar instância o objeto através de interfaces, por exemplo:

WebUpdate: Iautomation;

Webupdate: = coautomation.create; <- Não é um erro de trabalho

---

Webupdate: variante;

Webupdate: = createoleObject ('webupdate.automation'); <- funciona bem

Se eu registrar o X Exe ativo usando o RegServer, o problema desaparecer !!

Vai saber!