Ich habe eine 32-Bit-COM-Bibliothek verwendet, indem Sie es mit regsvr32 registriert und alles funktioniert gut. Da ich von einem 64-Bit-Prozess darauf zugreifen muss, registriere ich es jetzt über das Verwaltungstool für Komponentendienste als COM +. Problem ist, es scheint, dass nicht alle COM-Schnittstellen mehr ausgesetzt sind. Was könnten die Gründe dafür sein?Registrierung in COM + expose weniger Schnittstellen als Regsvr32
Es gibt zwei Aspekte dieses Problems.
Zuerst steuern Sie manuell, welche Klassen über COM + verfügbar gemacht werden, indem Sie diese Klassen nur in der COM + -Anwendung hinzufügen. Die Klassen, die Sie nicht enthalten, werden in-proc instanziiert, und diese Instanziierung wird nur aufgrund von 32-Bit/64-Bit-Inkompatibilität fehlschlagen.
Dann kommt Marshalling. Um dem Benutzer einen Schnittstellenzeiger des neu erzeugten Objekts zu geben, muss COM + wissen, wie diese Schnittstelle marshaliert werden kann. Sofern Sie das Marshalling nicht selbst implementieren, wird das Standard-Marshalling verwendet. Das standardmäßige Marshalling funktioniert nur, wenn die folgenden Voraussetzungen erfüllt sind: Der COM-Server enthält eine Typbibliothek, die Schnittstelle ist in dieser Typbibliothek enthalten und die Schnittstelle ist vollständig mit der Automatisierung kompatibel. Letzteres bedeutet grob, dass keine der Methoden dieser Schnittstelle Parameter von benutzerdefinierten Typen wie zum Beispiel Strukturen (Schnittstellen sind in Ordnung) hat. Wenn diese Anforderungen nicht erfüllt sind, gibt COM + E_NOINTERFACE zurück, wenn der Consumer CoCreateInstance() oder IUnknown :: QueryInterface() aufruft. Sehen Sie diese ähnliche Frage: What is required to enable marshaling for a COM interface? Sie haben grundsätzlich drei Möglichkeiten: nicht die verletzende Schnittstelle abfragen, benutzerdefinierte Marshalling implementieren (was ich derzeit nicht weiß, wo ich anfangen soll) oder eine neue Zwischenschnittstelle einführen, die Automation-kompatibel wäre.