2009-11-27 9 views
1

Il existe une autre société qui expédie le produit qui consomme IAnotherCompanyInterface. Nous voulons expédier un objet COM qui implémente IAnotherCompanyInterface. Cette interface n'est pas compatible avec Automation, donc la prochaine option la plus simple pour activer le marshaling est l'utilisation d'un proxy/stub. Une autre société ne livre pas le proxy/stub et ne le souhaite pas.Comment enregistrer un proxy/stub pour une interface COM définie par un tiers?

La compilation et l'enregistrement du proxy/stub n'est pas un problème en soi, mais considérez la situation suivante. Notre société expédie un objet COM implémentant IAnotherCompanyInterface et ThirdPartyCompany qui fait la même chose. Les deux composants peuvent donc être déployés sur la même machine.

L'enregistrement proxy/stub est un système pour une interface. Comment leurs implémentations proxy/stub co-résident?

Répondre

0

Vous pouvez ignorer complètement le registre de votre client en utilisant le contexte COM ou d'activation reg-free. Vous pouvez fournir des entrées comInterfaceExternalProxyStub "personnalisées" dans le fichier manifeste qui référence votre implémentation proxy/stub.

+0

Je ne contrôle pas le client, je contrôle uniquement le serveur COM. – sharptooth

+0

Néanmoins, vous pouvez toujours affecter un manifeste avec des entrées comInterfaceExternalProxyStub sous la forme d'un fichier .manifest ou d'une ressource incorporée. Cela ressemble beaucoup à la partie «interception» de la promesse d'interception, de délégation, de proxy transparent »de COM :-)) – wqw

0

Il est un moment que je travaille avec ce genre de choses, donc cela « pensait tout haut », mais nous espérons que ce sera un peu d'aide ...

Je suppose que vous pouvez voir une bibliothèque de type qui décrit l'interface vous vouloir mettre en œuvre. Si c'est le cas, chargez-le dans oleview.exe. Copiez le IDL qu'il vous donne dans un nouveau fichier .idl de votre choix et basez votre propre implémentation sur ce fichier.

Je sais que votre question concerne réellement le proxy/stub DLL. C'est très bien. Le vôtre sera généré avec votre serveur COM actuel, et il fonctionnera sur vos machines et celles de vos utilisateurs. Si votre code est installé sur une machine qui a également installé les bits de "Another Company", cela ne devrait pas ...

Le proxy/stub est juste un peu de code qui indique à COM comment transférer des paramètres et renvoyer des valeurs entre le client COM et le serveur COM. Si le vôtre est construit à partir d'IDL qui a été généré à partir de leur typelib, ils seront fonctionnellement équivalents. Votre serveur COM peut être appelé avec succès via leur proxy/stub et vice versa. Toutefois, s'ils changent de proxy/stub, ils peuvent ne plus être fonctionnellement équivalents. Mais dans ce cas, ils ont probablement aussi changé l'interface et votre serveur COM ne serait plus utilisable par leur client.

+0

Faisons semblant que l'interface ne change jamais. Donc je suppose qu'il n'y a pas de différence dans le proxy/stub utilisé. Maintenant, s'il y a le produit d'une autre entreprise et que j'installe le mien - que dois-je faire avec le talon - enregistrer le mien ou laisser le leur? Que faire si leur produit est désinstallé et supprime également le proxy/stub? – sharptooth

+0

Oui, je vois le dilemme. Il semble en quelque sorte erroné de remplacer leur inscription par la vôtre. Je suppose que la solution idéale serait de laisser les leurs intacts si elle existe déjà, mais si la leur est ensuite désinstallée, vous devriez être capable de détecter l'absence du proxy/stub et installer gracieusement votre propre. – Martin

+0

Je suppose que je pourrais le faire quand le consommateur appelle CoGetClassObject. Peut-être que le problème réside dans le fait que AnotherCompany introduit une interface mais ne délivre pas de proxy/stub. – sharptooth