Delphes et COM :Problèmes de TLB et de maintenance

Question

Dans l'entreprise où je travaille, nous développons toute l'interface graphique en C#, mais le noyau de l'application est principalement développé en Delphi 5 (pour des raisons historiques), avec de nombreux composants réalisés en COM+.Concernant ce type d'application très spécifique, je pose deux questions :

• Gars expérimentés en Delphi et/ou COM, avez-vous des solutions pour travailler avec l'interface buggée de TLB ?Certains des bugs sont :Crash de l'EDI lors de l'édition d'un TLB volumineux, perte des ID de méthodes, corruption du TLB, etc.Ici, nous n'avons trouvé aucune bonne solution.En fait, nous avons essayé de mettre à niveau vers la nouvelle version 2007.Mais la nouvelle interface IDE TLB présente les mêmes bugs que nous avons trouvés auparavant.

• Comment contrôler les versions des TLB ?Le fichier TLB est au format binaire et les résolutions de conflits sont très difficiles à réaliser.Nous avons essayé de le faire en exportant les descriptions d'interfaces vers IDL et en les validant dans CVS, mais nous n'avons trouvé aucun bon moyen de générer des TLB à partir d'IDL en utilisant Delphi.De plus, l'outil MIDL fourni par Microsoft n'a pas analysé correctement les fichiers IDL que nous avons exportés depuis Delphi.

Answer 1

Je pense que vous devriez jeter un bon coup d'œil à Delphi 2009.

Delphi 2009 apporte des modifications à la prise en charge COM, notamment un remplacement textuel des fichiers binaires TLB.

Vous pouvez en savoir plus sur Le blog de Chris Bensen.

Answer 2

Dans un passé lointain (avant de commencer à travailler pour CodeGear), j'ai abandonné l'étrange langage IDL Delphi présenté par l'EDI, j'ai écrit mon propre IDL et je l'ai compilé à l'aide de MS midl.Cela a largement fonctionné ;le seul problème, IIRC, était de s'assurer que les dispids (attribut id) étaient corrects sur les interfaces d'automatisation (dispinterfaces) pour les getters et setters de propriétés - il y avait un invariant attendu par tlibimp mais midl ne le garantissait pas.

Cependant, maintenant que Delphi 2009 utilise un sous-ensemble sûr de la syntaxe midl et inclut un compilateur pour ce midl dans la boîte et intégré à l'EDI, ces problèmes devraient appartenir au passé.

Answer 3

Nous venons également d'installer Delphi 2009 et il semble avoir amélioré la prise en charge des bibliothèques de types.Cependant, je travaille avec COM et des bibliothèques de types depuis un certain temps et voici mes pièges généraux que j'ai découverts au fil des ans.Je serais d'accord que c'est assez bogué et qu'il va jusqu'à Delphi 2006 (notre version avant d'utiliser 2009).

• Assurez-vous toujours que chaque fichier soit accessible en écriture avant de l'ouvrir.Cela peut sembler évident, mais lorsque nous travaillons avec le contrôle de source, nous oublions parfois de le faire et essayons de supprimer l'indicateur en lecture seule après l'ouverture d'un fichier - Delphi ne peut pas gérer cela.Assurez-vous que tlb est accessible en écriture avant de l'ouvrir.
• Si vous modifiez une bibliothèque de types autonome, vous DEVEZ avoir un projet ouvert.Pour une raison quelconque, si vous ouvrez une bibliothèque de types seule, elle ne sera pas enregistrée.Créez un projet vierge, puis ouvrez votre bibliothèque de types.Pour une raison quelconque, cela permet à la bibliothèque de types d'être enregistrée.
• Si votre bibliothèque de types est utilisée par une application ou COM+, assurez-vous que l'application est arrêtée ou que COM+ est désactivé avant d'ouvrir la bibliothèque de types.Toutes les applications ouvertes empêcheront l’enregistrement de la bibliothèque de types.

Cependant, je pense que votre meilleure solution est probablement une mise à niveau.Vous bénéficiez également du support Unicode.

Answer 4

L'utilisation de Delphi 2009 a grandement simplifié la gestion des fichiers TLB volumineux et la conversion de nos objets existants s'est déroulée sans problème, mais nos objets com n'utilisent aucune bibliothèque tierce.

Nous migrerons nos applications graphiques une fois que les fournisseurs de bibliothèques publieront les versions prises en charge.

Answer 5

Même expérience avec l'interface TLB ici :nous avons simplement arrêté de l'utiliser.

Nous travaillons avec plusieurs fichiers IDL distincts (construits manuellement) pour différentes parties de notre framework, en utilisant la construction #include pour les inclure dans l'IDL de l'application réelle, puis générons le seul tlb en utilisant MIDL et tlibimp.Si l'application ne dispose pas de son propre IDL, des versions précompilées des différents fichiers TLB du framework sont disponibles.

Chaque fois que le framework entre dans une nouvelle version, un script est exécuté pour régénérer les GUIDS sur toutes les interfaces nécessaires dans les fichiers IDL.

Cela nous a bien servi pendant de nombreuses années, et pour que nous puissions passer au nouvel ensemble d'outils Delphi 2009 IDL/TLB, nous devrons non seulement être intégrés dans l'EDI, mais également polyvalents en matière de builds automatisés et ainsi de suite.J'ai hâte de me salir les mains avec quelques expériences !