Nicht wenige verwenden, wie ich auch COM Komponenten, aus dem eigenen Haus oder von Fremdherstellern. Eingebunden werden diese COM-Komponenten oft genug über das #import Statement, das ja eine wirklich simple Integration erlaubt.
Lästig ist nur, dass diese Komponenten nicht auf allen Rechnern in den selben Verzeichnissen liegen. Das macht es nicht leicht Projekte und Entwicklungmaschinen so auszustatten, dass alle Projekte gleich zu kompilieren sind. Da fängt es schon an, dass ein Entwickler ein englisches OS (C:\Program Files), ein andere ein deutsches (C:\Programme) und der dritte Entwickler benutzt das Installationverzeichnis der zu entwickelnden Komponente (C:\Dev\Project\Bin).
Aus diesem Grund bin ich dazu übergangen das #import Statement nur einmal auszuführen, und die entstehenden .tlh und .tli Dateien direkt in das Projekt aufzunehmen.
Zu schnell? OK, also schrittweise:
- Ich binde die Komponente also wie gewohnt per #import ein.
- Die entstehenden .tlh und evtl. auch die .tli Dateien werden in das Projektverzeichnis kopiert und in das Projekt aufgenommen.
- Das das #import Statement wird nun auskommentiert und statt dessen entsprechende #include Statements eingesetzt.
- Nachdem man das auch korrekt mit entsprechenden Versionsangaben der Komponente dokumentiert hat und auch dieses Verfahren in die Projektbeschreibung aufgenommen hat ist man fertig!
Vor- und Nachteile:
- Nicht nur, dass dieses Projekt unabhängig kompiliert werden kann. Das Kompilieren ist auch noch schneller, denn die (an sich) statischen .tlh und .tli Dateien werden nicht immer neu erzeugt.
- Vorrausetzung ist hier sicherlich, dass es sich hier um Komponenten handelt, deren Interface sich nicht mehr verändert, und man muss bei einem Update der Komponente natürlich auch manuell die neuen .tli und .tlh Dateien einbauen.
- Ein weiterer Vorteil ist auch, dass das Interface fest eingebunden wird, das auch für die Auslieferung festgelegt wird und keine alte/oder neuere Version zu Überraschungen führt.
- Was auch zu dem genialen Verhalten führt, dass man aus dem Sourcecontrol System eine Software Version erzeugen kann, die noch mit einer älteren/abweichenden COM Komponente erzeugt wurde ohne diese auch noch mal installieren zu müssen!
Möglicherweise hat sich das Verhalten mit den neueren Compilern geändert, aber bei mit von VC6 erzeugten .tli/.tlh-Dateien bin ich kürzlich beim Ändern der Projektstrukturen auf ein kleines Problem gestoßen. In zwei .tlh-Dateien (erzeugt aus MSO.DLL und MSOUTL.TLB) wurden die dazugehörigen .tli-Datei in einer #pragma start_map_region-Anweisung mit vollständigem Pfadnamen referenziert. Das machte dann das Kompilieren unmöglich, weil die .tli-Dateien nicht mehr am alten Ort anzufinden waren.
Wenn man den .tli-Pfadnamen in der .tlh-Datei dann manuell anpasst und relativ zum Projektverzeichnis angibt, dann lässt sich das Projekt auch wieder kompilieren.
Danke für den Hinweis. Ich persönlich benutzte diese Wrapper in der tli gar nicht, sondern arbeite meistens mit den Raw-Interfaces und entsprechenden COM Smartpointern.
Welche Parameter verwendest Du denn immer beim #import-Statement?
Beispiel ADO:
#import „C:\Programme\Gemeinsame Dateien\System\ado\msado15.dll“ rename_namespace(„ADO“), raw_interfaces_only, rename(„EOF“,“adoEOF“)
HTH
Danke Dir, damit werde ich es das nächste Mal auch mal probieren.
Vielen Dank für diesen Tipp. Zufällig habe ich gerade genau diese Problemstellung.
Meiner erster Ansatz war die DLL und die OLB Dateien mit in die Sourcecodeverwaltung zu packen und dann das import Statement anzupassen, so dass alle zumindest die gleichen Pfade haben.
Martins Ansatz gefällt wir aber noch besser und Svens Probleme mit dem Absoluten Pfad in der #pragma start_map_region-Anweisung gibt es auch mit dem VS2008SP1 noch.