COM ist bekannt dafür, Abwärtskompatibilität bei der Veröffentlichung neuer Komponenten oder Anwendungen zu ermöglichen. Dies ist möglich, weil die Schnittstellen in COM stabil sind, d. H. Sie ändern sich nicht.
Ich habe mich bemüht, eine Referenz oder ein Buch zu finden, das sich mit einer Beschreibung beschäftigt, wie man eine COM-Schnittstelle von Version zu Version weiterentwickelt.
Folgendes sind meine Anforderungen:
Wir haben eine Anwendung, die von Ole Automation angetrieben werden kann. Neue Versionen dieser Anwendung können parallel zu älteren Versionen installiert werden.
COM-Clients dieser Anwendungen können die versionsunabhängige PROGID verwenden. In diesem Fall arbeiten sie mit der neuesten Version der Anwendung oder einer versionsabhängigen PROGID. In diesem Fall arbeiten sie mit der spezifischen Version der Anwendung.
Änderungen an der COM-Automatisierung sollten keinen der Clients unterbrechen.
Sehen wir uns ein Beispiel an:
%Vor%Nehmen wir an, ich möchte Version 2.0 dieser Anwendung veröffentlichen, die einige Schnittstellen erweitert. Hier ist meine naive Herangehensweise an Version 2.0:
%Vor%Ist das der richtige Weg?
Soll ich der Registry eine Klasse Application10 und Application20 hinzufügen, um eine Möglichkeit zu schaffen, die verschiedenen Versionen der Anwendung für Script-Clients zu instanziieren?
Ist es richtig, die Version und die GUID der Typbibliothek zu ändern?
IDocument in Version 2.0 hat eine neue IID. Kann ich IDocument weiterhin in IApplication.ActiveDocument verwenden?
Wie sollte ich die Co-Klasse oder Schnittstelle in der Windows-Registrierung in den verschiedenen Versionen registrieren?
Bitte beachten Sie, dass ich weder ATL noch andere Bibliotheken als die WIN32-API verwende.
Wenn Sie wissen, wo ich Informationen dazu finden kann (Bücher, Referenzen, etc.), schlagen Sie bitte einen vor.
Ich würde Ihre Hilfe sehr schätzen.
Ja, Sie müssen die Klassen-ID Ihres Objekts ändern wenn mehrere Versionen nebeneinander existieren sollen. Sie können jedoch eine versionsunabhängige Programm-ID wie "Word.Application" verwalten "oder" InternetExplorer.Application ", die zu der Klassen-ID der aktuellen Version . Die Abwärtskompatibilität ist sehr schwer aufrechtzuerhalten. MSXML gab offensichtlich die Praxis der versionsunabhängigen progID auf.
Wenn Sie alte Schnittstellen beibehalten (empfohlen), müssen Sie sowohl neue als auch alte Schnittstellen in Ihrem neuen Objekt implementieren.
Möglicherweise möchten Sie die Registrierungsdaten von Microsoft Office überprüfen. Es behält die Abwärtskompatibilität recht gut bei.
Der vorgeschlagene Name neuer Schnittstellen wäre der Name des Interfaktors plus die Versionsnummer, z. B. IHtmlDocument6 .