O que é necessário para permitir o empacotamento para uma interface COM?

Question

Eu tenho um componente ATL COM 32 bits sem uma biblioteca tipo. Tem uma fábrica de classe para uma determinada classe que implementa várias interfaces.

Quando eu usá-lo como um servidor in-proc, tudo funciona bem - o cliente invoca colaterais CoCreateInstance (), o objeto é instanciado e QueryInterface () recupera um ponteiro para a interface solicitada. Mas quando eu colocar o componente no COM + Eu já não pode instanciar a classe -. CoCreateInstance () agora retorna E_NOINTERFACE

Eu acredito que o problema é que COM + não pode executar empacotamento por causa da ausência de biblioteca de tipo - que não tem idéia de como fazê-lo. Eu preciso para gerar e registrar uma biblioteca de tipos para resolver este ou há alguma outra maneira?

Answer 1

Urk. Eu recomendaria perguntando sobre microsoft.public.vc.atl como eu acho que você vai encontrar mais especialistas lá. Eu acho que (embora eu não sou um especialista) a questão tem menos a ver com COM + do que a questão dos registrados proxy / stubs. (Em outras palavras, mesmo se você escreveu seu próprio cliente COM para aceder aos seus out-of-process componente, você provavelmente correr para o mesmo problema) Se você tiver interfaces de automação compatível com padrão, o Windows sabe como empacotar seus objetos apenas bem. Mas caso contrário, é confusa.

Sem uma biblioteca de tipos, você quer necessidade de registrar proxy / stubs, ou necessidade de implementar IMarshal-se para lidar com empacotamento personalizado. (Ou há também esse "manipulador de empacotamento" coisa que eu não entendo)

O seu comentário sobre por que você não tem uma biblioteca de tipos (implementação de uma interface já definida pela Microsoft, mas que não tem um typelib) levanta uma bandeira vermelha comigo. Você pode fornecer mais detalhes? Se é algo em um arquivo .dll ou .exe, mas as informações de tipo é dentro da própria biblioteca (em vez de um arquivo .TLB externa) é provavelmente possível extrair a informação certa para fazer tudo funcionar, eu não sou apenas familiarizado com o processo.

ATL

(Para que conste, eu deixei / COM programação em favor de Java, por isso, embora eu posso deixar você sabe o que eu me lembro, no passado, eu não usar as ferramentas agora e seria difícil para mim para voltar a eles para fornecer mais ajuda. Mas o pessoal no microsoft.public.vc.atl são muito inteligentes.)

Answer 2

Typelibs são uma forma de triagem apoio, DLLs / stub proxy (genereated do IDL) são outra. Em ambos os casos, no entanto, você vai precisar do IDL, em primeiro lugar.

Se a Microsoft não fornece um typelib / DLL proxy ou IDL para esta interface, as probabilidades são de que há uma razão para isso: Talvez a interface utiliza estruturas de dados não-marshalable, requer ponteiros de função a ser passado como parâmetro de método ou coisas como isso? Se este for o caso, não há nenhuma maneira de fazer este trabalho interface para DCOM.

Talvez você possa reconstruir o IDL, mas muito possivelmente, ele simplesmente não será viável. Em seguida, a sua última fallback poderia ser para uso personalizado ou triagem manipulador, mas isso não é provavelmente vale a pena o esforço. Dito isto, eu recomendo considerar outras rotas que não envolvem o uso de interfaces para DCOM que não foram projetados para ser usado para DCOM.

Answer 3

Para uma interface COM para ser marshallable usando marshaller padrão da Microsoft, a interface tem que ter tanto o DUAL ou a propriedade oleautomation definido no seu cabeçalho.

Se há argumentos para os métodos definidos que são de interface ponteiros, a mesma exigência se estende a essas interfaces.

Além disso, o nome da interface deve estar presente na seção Biblioteca da IDL defini-la. Isso também se estende a outras interfaces referenciadas.

Se estas condições não forem cumpridas, a interface não será marshallable.