.. pour un serveur hors processus, ou puis-je appeler une interface de répartition sans enregistrer de proxy/stub?Est-ce qu'une interface IDispatch "pure" nécessite une DLL proxy/stub?
L'interface en question est très haut niveau, donc la performance est un non-problème, et je pourrais faire la chose sans inscription, ce qui est un gros plus
Je suis sûr que vous n'avez pas besoin de fournir un proxy personnalisé/stub dll si vous limitez votre interface (s) aux types compatibles avec l'automatisation. Dans ce cas, le système peut utiliser le marshaler d'automatisation et n'a pas besoin d'aide supplémentaire. Je crois que les types compatibles avec l'automatisation sont les types qui peuvent entrer dans un VARIANT, par exemple. des types de POD simples, BSTR, et similaires.
J'ai trouvé this KB article qui a une discussion sur le marshaler de l'automatisation, bien qu'il ne soit pas spécifiquement ciblé sur votre question. Il liste les types compatibles, à tout le moins. Il mentionne également que vous devez identifier spécifiquement le marshaler d'automatisation dans l'enregistrement pour votre composant, mais dans mon expérience ce n'est pas nécessaire - votre kilométrage peut varier. Enfin, vous devrez peut-être aussi implémenter IProvideClassInfo; J'utilise généralement l'implémentation fournie par ATL.
Vous avez seulement besoin d'un dll proxy/stub si votre interface doit être rassemblée. Cela signifie que si votre serveur COM est en cours de traitement et que l'interface n'est pas transmise entre les appartements, et que vous ne l'appellerez pas à partir de .Net ou de toute autre situation nécessitant son regroupement, alors vous n'avez pas besoin d'un proxy/stub dll.
Vous voulez donc utiliser le marshaler standard pour * créer * l'enveloppe proxy/stub automatiquement pour vous. La question est de savoir comment vous identifiez IDispatch de cette coclass pour être enveloppé sans entrées de registre pour la coclasse? – wqw
Non, la question est de savoir si je peux * l'utiliser *. – peterchen