Ciò che è necessario per consentire marshalling per un'interfaccia COM?

Question

Ho un componente COM ATL a 32 bit, senza una libreria di tipi. Esso ha una fabbrica di classe per una data classe che implementa diverse interfacce.

Quando lo uso come un server in-process, tutto funziona bene - il lato client richiama CoCreateInstance (), l'oggetto viene creata un'istanza e QueryInterface () recupera un puntatore a un'interfaccia richiesto. Ma quando ho messo il componente in COM + non posso più creare un'istanza della classe -. CoCreateInstance () ora restituisce E_NOINTERFACE

Credo che il problema è che COM + non può eseguire il marshalling a causa della mancanza di libreria di tipo - non ha idea di come farlo. Ho bisogno di generare e registrare una libreria dei tipi per risolvere questo o c'è qualche altro modo?

Answer 1

Urk. Consiglierei di chiedere il microsoft.public.vc.atl come penso troverete più esperti c'è. Penso che (anche se non sono un esperto) la questione ha meno a che fare con COM + che la questione della registrati proxy / stub. (In altre parole, anche se hai scritto proprio client COM per accedere il componente out-of-process, si sarebbe probabilmente incorrere nello stesso problema) Se si dispone di interfacce standard di automazione-compatibile, quindi Windows sa come effettuare il marshalling gli oggetti solo bene. Ma per il resto è confuso.

Senza una libreria di tipi, si sia necessario registrare proxy / stub, o la necessità di implementare IMarshal se stessi per gestire il marshalling personalizzato. (O c'è anche questa cosa "handler marshalling" che non capisco)

Il tuo commento sul perché non si dispone di una libreria di tipi (implementazione di un'interfaccia già definito da Microsoft, ma che non dispone di una libreria dei tipi) solleva una bandiera rossa con me. Si può fornire maggiori dettagli? Se si tratta di qualcosa in una DLL o .EXE, ma le informazioni sul tipo è all'interno della libreria stessa (piuttosto che un file tlb esterno) è probabilmente possibile estrarre le informazioni giuste per far funzionare tutto, io sono solo non hanno familiarità con il processi.

(Per la cronaca, ho lasciato ATL programmazione / COM a favore di Java, quindi anche se posso farvi sapere quello che mi ricordo in passato, io non uso gli strumenti ora e sarebbe difficile per me per tornare in loro di fornire più aiuto. Ma la gente sul microsoft.public.vc.atl sono abbastanza intelligente.)

Answer 2

Typelibs sono un modo per sostenere le DLL di smistamento, proxy / stub (genereated dal IDL) sono un altro. In entrambi i casi, tuttavia, è necessario l'IDL, in primo luogo.

Se Microsoft non fornisce una DLL libreria dei tipi / proxy o IDL per questa interfaccia, le probabilità sono che c'è una ragione per questo: Forse l'interfaccia utilizza strutture dati non marshalable, richiede puntatori a funzione per essere passato come parametro del metodo o cose come questo? Se questo è il caso, non c'è proprio nessun modo per fare questo lavoro interfaccia per DCOM.

Forse si può ricostruire l'IDL, ma molto probabilmente, semplicemente non sarà fattibile. Allora la vostra ultima ripiego potrebbe essere quella di utilizzare personalizzato o gestore di smistamento, ma non è probabilmente vale la pena. Detto questo, io consiglierei di considerare altre vie che non comporta utilizzo di interfacce per DCOM che non sono stati progettati per essere utilizzati per DCOM.

Answer 3

Per un'interfaccia COM per essere marshallable usando marshaller di default di Microsoft, l'interfaccia deve avere sia la DUAL o la proprietà oleautomation definiti nella sua intestazione.

Se ci sono argomenti per i metodi definiti che sono puntatori di interfaccia, lo stesso obbligo si estende a quelle interfacce.

Inoltre il nome di interfaccia deve essere presente nella sezione LIBRARY della IDL definirla. Questo si estende anche ad altre interfacce di riferimento.

Se queste condizioni non sono soddisfatte, l'interfaccia non essere marshallable.