J'ai utilisé une bibliothèque COM 32 bits en l'enregistrant avec regsvr32 et tout fonctionne correctement. Comme j'ai besoin d'y accéder à partir d'un processus 64 bits, je l'enregistre maintenant en tant que COM + via l'outil d'administration de Component Services. Le problème est, il semble que toutes les interfaces COM ne sont plus exposées. Quelles pourraient être les raisons de cela?L'enregistrement dans COM + expose moins d'interfaces que Regsvr32
Il existe deux aspects de ce problème. D'abord, vous contrôlez manuellement les classes exposées via COM + en ajoutant ces classes uniquement dans l'application COM +. Les classes que vous n'incluez pas seront instanciées dans-proc et cette instanciation échouera simplement en raison de l'incompatibilité 32 bits/64 bits.
Puis vient le marshaling. Afin de donner au consommateur un pointeur d'interface de l'objet nouvellement créé, COM + doit savoir comment gérer cette interface. À moins que vous n'impliquiez la mise en place de votre propre rassemblement par défaut, vous l'utilisez. Le marshaling par défaut ne fonctionnera que si les conditions suivantes sont remplies: le serveur COM contient une bibliothèque de types, l'interface est incluse dans cette bibliothèque de types et l'interface est entièrement compatible avec Automation. Ce dernier signifie à peu près qu'aucune des méthodes de cette interface n'a de paramètres de types personnalisés comme les structures par exemple (les interfaces sont correctes). Si ces conditions ne sont pas remplies, COM + renvoie E_NOINTERFACE lorsque le consommateur appelle CoCreateInstance() ou IUnknown :: QueryInterface(). Voir cette question similaire: What is required to enable marshaling for a COM interface? Vous avez fondamentalement trois choix: ne pas interroger l'interface de violation, mettre en œuvre le marshaling personnalisé (dont je ne sais pas par où commencer) ou introduire une nouvelle interface intermédiaire qui serait compatible avec l'automatisation.