user control .net -> activex

Salut à tous, Je me permets de reposter la question, le pauvre petit gars qui l'avait posée a du passer innaperçu dans le grand trou du mois de mai et n'a jamais eu de réponse :-/ Problématique : modifier un controle utilisateur .net de façon à le rendre accessible comme tout bon vieux activex. But : Réutiliser des controles .net évolués dans des solutions ne supportant pas encore ces controles, vb6 par exemple (c'était le problème d'origine), ou Allfusion Plex pour ma part. Cause : L'architecture COM étant progressivement abandonnée par micro$oft, il n'est plus possible (à priori) de créer directement des composants ActiveX par VB.Net. Les nouveaux composants, appelés "controles windows" (projet de type "Bibliothèque de contrôles windows", fonctionnent de façon assez similaire mais ne sont plus visibles en tant que contrôle activex, on ne peut donc les réutiliser que dans des solutions .net ... C'est un peu chiant, pour ma part j'ai plus de 2000 lignes de code en VB.NET dans mon composant, et ça me saoulerait un peu de devoir les repasser en VB6, sans compter le fait qu'un paquet de librairies risquent de poser problème (adodb, adomd, axowc10 compilé "maison" ...). Solution: A priori il exist(ait) une méthode sur la Beta1 vs.net qui permettait de mapper des fonctions standard COM ("ComRegisterFunction" etc.) de façon à simuler le comportement d'un activex standard. D'après ce que j'ai lu, cette méthode ne fonctionnait plus à partir de la Beta2 (krosoft abandonnant le support autour de COM), mais un illuminé s'est lancé dans l'aventure tout de même. Au final ça donne les méthodologies suivantes : http://www.codeproject.com/cs/miscctrl/exposingdotnetcontrols.asp http://www.codeproject.com/vb/net/serviced_components.asp http://www.codeproject.com/vb/net/COM_Interop.asp J'ai essayé de mixer un peu des trois, dans tous les sens, depuis deux jours, mais rien à faire ... si quelqu'un a déjà tenté et réussi avec succès à déclarer un controle utilisateur .net en le faisant passer pour un activex, je suis preneur ! Si il existe d'autres façons de faire pour réutiliser ces composants je suis preneur de conseils aussi, j'ai l'impression d'être dans une impasse par moments ... Désolé pour la longueur. Désolé pour l'imprécision. Désolé pour l'intérêt tout relatif que représente le sujet. Désolé en fait ... mais au secouuuurs :) Tonio

Salut, as tu regardé ça:




[ Lien ]

Nope, je n'étais pas tombé là dessus dans mes recherches, merci pour le lien ! Je vais tout repasser au crible et voir ce que j'ai pu oublier ... Tonio

Par contre la lecture de posts antérieurs ne m'encourage pas beaucoup, à priori ceux qui ont essayé s'y sont cassé les dents ... affaire à suivre :) Tonio

Salut, ce n'est qu'une idée, mais il faudrait peut-être intégrer une partie des DLL du framework à votre projet, puis y faire appel au lancement du projet, qui celui-ci s'en servira pour loader le contrôle

Chris...
Web : Firstruner - eMail : Support&

Salut Chris, La supposition est parfaitement judicieuse ;) Mais à priori il est plus "propre" d'installer tout bêtement le framework .net sur la machine qui exécute l'appli. Pour moi ça ne pose pas de problème de déploiement, c'est une appli distribuée par Citrix et il n'y a besoin d'installer qu'une machine : le serveur. En plus je n'en suis pas là, l'objectif pour l'instant est de faire tourner un contrôle avec une bête propriété, juste pour prouver que c'est possible ... je verrai après pour faire tourner le -vrai- module :) Tonio

Bon, je laisse tomber, c'est l'enfer ... J'ai appliqué tout ce que j'ai pu trouver de pertinent dans le lien : http://msdn.microsoft.com/library/FRE/cpguide/html/cpconexposingnetframeworkcomponentstocom.asp?frame=true Et un peu plus en fait en prenant en compte ce que j'avais déjà trouvé là : http://www.codeproject.com/cs/miscctrl/exposingdotnetcontrols.asp http://www.codeproject.com/vb/net/serviced_components.asp http://www.codeproject.com/vb/net/COM_Interop.asp Mais ça ne fonctionne toujours pas :( J'ai bien une assembly "strong named" et chargée dans le cache global, des méthodes exposées comme il faut, des fonctions standard d'enregistrement COM, une interface reconnue par le système et déclarée dans la base de registres, et même la librairie de types est accessible, mais toujours pas d'activex visible dans les listes "officielles" de controles COM ... je crois que je vais devoir me fader la conversion en VB6 :( Ce qui est désolant c'est que finalement, toutes les méthodes "magiques" décrites par des gars qui annoncent être parvenus ("tout simplement parceque .net c'est génial") à charger des composants s'avèrent incomplètes. Ils oublient la plupart des déclarations d'interopérabilité, le plus dur donc, et je ne vois pas comment ils peuvent prétendre que leur code marche, à tout les coups ils ne l'ont même pas testé :-/ Ce qui est encore plus désolant c'est l'insondable capacité de microsoft à abandonner des technos en cours de route sans assurer la compatibilité de ce qui suit. Professionnellement c'est moyen ... Tonio escrocs