Discussion :

[Esposito]

De nos jours les fabricants de matériels de tout poil abandonnent progressivement les ActiveX au profit des .net suivant en cela les directives de Microsoft.
La question clé est donc comment utiliser un assemblage .net lorsque l'on développe en Delphi XE2 ou XE3 ou XE4.

La documentation Embarcadero dit ceci:
Importer un assemblage .NET
Cliquez sur cet élément pour importer un assemblage .NET en tant qu'objet COM. L'assemblage .NET GAC recensé que vous sélectionnez sera l'ancêtre du composant que vous créez.
Donc inutilisable avec un PC 64 bits
Remarque : L'expert Importer un composant examine seulement le registre 32 bits. Lorsque l'exécution s'effectue sur un système 64 bits, vous devez utiliser directement TLIBIMP.EXE si vous voulez importer un contrôle ActiveX ou une bibliothèque de types spécifique à un système 64 bits.
La doc dit donc implicitement que l'on ne peut pas charger d'assemblage .net en 64 bits. Et pourtant Embarcadero dit le contraire dans sa Pub.

Le tentatives faites en essayant de charger des composants fournis en version .net (exemples: eVision, MIL, VrMagic, OpenCV, ComponentOne...) à l'aide du bouton "ajouter" se soldent par des échecs cuisants (pas de visibilité des classes, composants non enregistrés, erreur de chargement de la dll et j'en passe). Le développeurs de ces produits n'ont aucune directive à donner s’abritant derrière un sibyllin "on ne connaît pas Delphi et on ne maintient rien pour cette plateforme".

J'ai fait aussi des tentatives avec des assemblages que j'utilise en version composants VCL (Teechart par exemple) sans plus de succès.

Les quelques discussions dans le forums sont assez décourageantes un exemple:
https://forums.embarcadero.com/threa...threadID=38369
http://stackoverflow.com/questions/7...-in-delphi-xe2

Les essais avec Crosstalk et Hydra sont tout aussi peu concluants. Pour Crosstalk il n'importe que des objets non visuels... et Hydra ne prend en charge que des assemblages d'un certain type.

Je suis prêt à collaborer avec tout développeur confronté à ces problèmes pour trouver des solutions.

A toutes fins utiles les ActiveX avaient ce mérite d'être effectivement utilisables avec toute plateforme de développement civilisée. Il ne semble pas que ce soit le cas pour les assemblages .net.
Et pourtant tout se passe bien lorsque l'on utilise ces assemblages en C# Visual Studio. Volonté de Microsoft de faire de l'ombre à Embarcadero.
Les développeurs des Versions récentes de Delphi ont-ils des solutions à proposer?

[Paul TOTH]

je ne rencontre pas cette problématique, mais il semblerait que .Net 4 propose le Hosting CLR sous Windows natif

[ShaiLeTroll]

En C++Builder, on a eu le même problème avec CystalReport 2008 (v12) remplaçant petit à petit CR8
CR8 était disponible soit via une Lib Delphi complète soit par import du TLB\OCX
CR12 ne semble fournir que .NET ou Java !

On a pas cherché longtemps, un coup de Visual Studio pour faire un Wrapper Component en C# exposant ce que l'on a besoin de CrystalReport 12
On expose ce qui existe en C# plus on reconstruit certains éléments pour que notre Wrapper émule le comportement de CR8
Dans notre code, on utilise soit l'ActiveX de CR8 soit notre Wrapper2008 en fonction du rapport (on a pas migré tous les rapports, cela se fait petit à petit)

Il faut ACTIVER le support du COM !
Une assembly.NET ne l'active pas par défaut, c'est quelque chose à faire soit même !
Puis on enregistre via RegASM du C# 2.0 !
Pour le 64Bit, on n'a pas vérifié, mais on fait du C++Builder 32 Bit donc forcément une DLL Wrapper en 32bit aussi