Discussion :

[SheepSheep]

Bonjour,

Je travaille actuellement sur une application en C++. J'aimerais créer une API pour cette application qui me permettrait d'utiliser ses fonctions depuis l'extérieur. En effet, j'aimerais pouvoir utiliser cette API pour créer des plugins en C++ pour cette application.
Je sais qu'il me faudra créer une bibliothèque, cependant je ne sais pas trop comment m'y prendre pour ne rendre accessibles que certaines de mes méthodes. Par exemple, j'ai une classe "Calculateur", et j'aimerais que seules quelques-unes de ses méthodes soient disponibles dans l'API. J'aimerais (si possible) éviter la duplication de code, et je ne veux pas modifier le code source de mon application.

Quelles sont les possibilités pour créer cette API?

Merci !

[bacelar]

J'aimerais créer une API pour cette application qui me permettrait d'utiliser ses fonctions depuis l'extérieur.

"extérieur", c'est très flou, extérieur du module binaire, extérieur du processus, extérieur de la session, extérieur de la machine, etc...

En effet, j'aimerais pouvoir utiliser cette API pour créer des plugins en C++ pour cette application.

On va dire extérieur du module binaire alors ?
Des plugins sous forme de dll/so et non d'exécutables ?

Clairement, le C++ n'est pas le bon choix pour faire des modules binaires interopérables.

La norme C++ ne spécifie pas d'ABI ni de règles de décoration des noms des symboles.
Résultat, chaque module binaire exportant une API C++ n'est compatible qu'avec les binaires compilés avec le même compilateur, voir la même version du compilateur.
Et en plus, il faut que les options de compilation, d'édition de lien, les versions des librairies tierces utilisés etc... soient compatibles entre elles lors de la compilation module utilisateur client de l'API et lors de la compilation du module implémentant l'API.

En gros, à moins de faire soi-même les plugins du programme, en même temps que le programme et avec aucune chance de pouvoir les modifier après, c'est mort en C++.
Cela rend l'architecture de plugins complètement sans intérêt pour moi.

Le plus raisonnable, c'est d'implémenter une API C ou d'un autre langage spécifiant clairement son ABI et son mécanisme d'exportation.
Faire une API C en C++, c'est pas très compliqué, c'est juste utiliser les séquences

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

extern "C"{....}

quand vous déclarez et implémentez les fonctions qui devront être accessibles depuis l'extérieur du module binaire.
extern "C", ce charge de dire qu'il faut utiliser les conventions de décoration des noms des symboles à la C et pas à la C++, pour les conventions d'appels et autres détails d'API, chaque compilateur fait sa tambouille (à potasser dans la documentation de la chaine de compilation).

Il existe des Framework, tel que COM (Common Object Model), ou XCOM sous Mozilla, ou MSF pour "simplifier" la construction de modules interopérables.
Mais c'est pas le genre de framework qu'on utilise pas "après coup".
Ils imposent des manières de faire très strictes.

La manière de faire la plus basique, c'est d'imposer au module binaire du plugins d'avoir une fonction exportée à la C ( donc une API C) qui permet à l'exécutable de fournir un ensemble de pointeur de fonction C (toujours pour avoir une API C) que le code du plugins pourra appeler au moment "opportun".

Je sais qu'il me faudra créer une bibliothèque

Une Dll/so vous voulez dire ?

cependant je ne sais pas trop comment m'y prendre pour ne rendre accessibles que certaines de mes méthodes.

Heu, là, il n'y a rien de plus trivial, vous ne mettez pas ces méthodes dans l'API, c'est tout.

Par exemple, j'ai une classe "Calculateur", et j'aimerais que seules quelques-unes de ses méthodes soient disponibles dans l'API.

Si c'est une API C, c'est vous qui données l'ensemble des fonctions qui seront exportés (à vous de faire le wapping entre la fonction C et la méthode C++)
Si c'est une API C++, ce que je vous décourage instamment de faire, il suffit de faire dériver "Calculateur" d'une Interface/Classe de base "ICalc" qui ne contient que les méthodes pertinentes pour le plugins. Vous ne fournissez que des "ICalc" dans l'API, et voilà.

J'aimerais (si possible) éviter la duplication de code,

Je veux mon nveux !!!!

et je ne veux pas modifier le code source de mon application.

Heu, c'est le genre de feature qu'on ajoute sur un coin de table, le jour de la Release.
Cela aurait dû être pris en compte lors de la conception de la solution logicielle.
Si vous n'êtes pas trop exigeant sur la fiabilité, la sécurité et la simplicité d'utilisation un bricolage à base de pointeur de fonction ne devrait pas trop modifier votre code, s'il est bien conçu.

Quelles sont les possibilités pour créer cette API?

Beaucoup, mais commencez par faire simple.

[SheepSheep]

Bonjour,

Tout d'abord merci pour votre réponse.

Je viens dans un premier temps apporter quelques éclaircissements sur mon problème. Je reprends actuellement une application réalisée en C++, qui n'a pas été pensée pour accueillir un système de gestion de plugins. Si cela est possible, je ne suis pas contre le fait de réaliser ce système (ou une partie) et/ou l'API de cette application dans un langage plus adapté.
Quel langage me conseilleriez-vous? Le C# serait-il un bon choix par exemple?

D'autre part, j'ai déjà codé le système de gestion des plugins (ceci dit je suis prête à le reprendre dans un autre langage si cela vaut le coup), et les plugins sont effectivement des .dll chargés durant l'exécution, et j'utilise déjà l'astuce du "extern C".
Ma question touchait à l'API, car en cherchant des moyens de créer cette API je me retrouvais effectivement confrontée à de nombreux problèmes et questionnements:
- la nécessaire compatibilité des compilateurs, sauf en utilisant extern C,
- le choix entre linkage intern et extern (je pense que intern est le mieux pour l'API?),
- le fait de devoir conserver toute l'application, qui est très lourde, pour créer cette librairie,
- la mise à jour de mon application et donc de ma librairie entraînant une mise à jour du plugin, ce qui ne les rend pas très indépendants et diminue les avantages d'un système de plugins,
- ...
Je me suis alors demandé si mon approche était la bonne pour cette API.

Depuis hier, j'ai commencé à coder mon API en ajoutant un fichier api.h et un fichier api.cpp, qui instancie les classes nécessaires et appelle leurs méthodes (un genre de wrapper donc). Je l'ai linké en statique, sans utiliser "extern C" (je ne sais pas comment m'y prendre en statique à vrai dire).

Voilà donc où j'en suis, toutes les suggestions seront les bienvenues! J'apprends en faisant ce projet, donc recommencer et tenter d'autres approches ne me fait pas peur.

J'ai également une question plus avancée:
Est-il possible de faire communiquer un plugin avec l'application qui l'a chargé? Je m'explique: imaginons que mon application ait une classe "Config", singleton, qui contienne des infos en "temps réel" (selon les dernières modifications de l'utilisateur pendant l'exécution de l'application), est-il possible d'accéder à l'instance de cette classe depuis mon plugin?

Merci à vous !

[bacelar]

Ok, merci d'avoir un peu plus défini le cadre du problème.
Mais vous n'êtes pas très causeux/volubile sur le cahier des charges ou les contraintes des plugins (partage de fenêtre, multi-threading, sens des fonctions de callback, langages possibles pour l'implémentation, etc...)
En fonction de ces critères, des approches sont viables ou complètement illusoires.

Je reprends actuellement une application réalisée en C++

Quels framework et bibliothèques ont été utilisés pour la réaliser ? (Qt? MFC? COM? XCOM? WinForms? Win32? DirectX? OpenGL? ILogView? etc...)

qui n'a pas été pensée pour accueillir un système de gestion de plugins.

Mais peut-être que les framework utilisés y ont pensé, eux.

Si cela est possible, je ne suis pas contre le fait de réaliser ce système (ou une partie) et/ou l'API de cette application dans un langage plus adapté.

Faudrait commencer déjà par savoir de quoi on dispose avant de commencer à refaire des roues carrées.
Mixer les langages, c'est sympa, mais faire simple, c'est le principal.

Quel langage me conseilleriez-vous?

Commencez par voir toute les possibilités qu'offre votre langage, qu'offrent les Framework déjà utilisé et ce qu'offre les framework du langage qui sont compatibles avec ceux déjà utilisé.

Le C# serait-il un bon choix par exemple?

Pour faire du COM ou une migration du C++ vers du C++/CLI oui, sinon non pas vraiment.

et j'utilise déjà l'astuce du "extern C"

Ce n'est pas une astuce, c'est comme ça qu'on utilise et publie une API C depuis une Dll codée en n'importe quoi.
C'est l'API qui est C, le reste on s'en cogne en quoi c'est fait.

- la nécessaire compatibilité des compilateurs, sauf en utilisant extern C,

L'extern C, c'est la méthode bas-niveau, où tous les détails comme la gestion du multi-threading, le partage de fenêtre, les callback, etc... reste à faire, c'est basique.
Vous pouvez aussi utiliser des frameworks dédiés ou non (Qt, MFC, etc...) pour faire des plugins.

- le choix entre linkage intern et extern (je pense que intern est le mieux pour l'API?),

Pouvez-vous être plus précis ? je ne vois pas de quoi vous parlez.

- le fait de devoir conserver toute l'application, qui est très lourde, pour créer cette librairie,

Il n'est pas rare que la mise en place de plugins permette de réarchitecturer une application monolithique pour en faire une application "composite" bien plus souple et évolutive.

- la mise à jour de mon application et donc de ma librairie entraînant une mise à jour du plugin,

Ce n'est pas obligatoire. En fonction des technologies utilisées et en faisant attention à la conception des API, il est tout à fait possible de maintenir la compatibilité ascendante.

ce qui ne les rend pas très indépendants et diminue les avantages d'un système de plugins,

C'est pour cela qu'il faut faire attention aux technologies utilisées et bien concevoir les API pour les rendre facilement évolutives.

Je me suis alors demandé si mon approche était la bonne pour cette API.

Mais quelle approche ???

Depuis hier, j'ai commencé à coder mon API en ajoutant un fichier api.h et un fichier api.cpp, qui instancie les classes nécessaires et appelle leurs méthodes (un genre de wrapper donc). Je l'ai linké en statique, sans utiliser "extern C" (je ne sais pas comment m'y prendre en statique à vrai dire).

Heu, là, je ne sais pas où vous voulez en venir. Si le cpp est compilé avec le projet, je ne vois pas où est vraiment votre "plugIns".
En "extern C", vous n'avez pas accès à des classes, juste à des fonctions libres et des variables globales.
Si vous utilisez les extensions Visual Studio pour l'exportation de classes, vous vous retrouverez avec une API C++, avec tous les problèmes que cela implique.
Convertir une classe et son ensemble de méthode en un ensemble de fonctions libres ayant un paramètre "HANDLE/void*" opaque supplémentaire permet de facilement wrapper des classes C++ dans une API C.

Voilà donc où j'en suis, toutes les suggestions seront les bienvenues! J'apprends en faisant ce projet, donc recommencer et tenter d'autres approches ne me fait pas peur.

Mais c'est quoi vos contraintes/ cahier des charges ???
Sinon, une API C bien conçu et c'est dans la boite.

Est-il possible de faire communiquer un plugin avec l'application qui l'a chargé?

Oui, sans problème, vous fournissez une API de callback comme paramètre d'une des fonctions que le plugIns doit implémenter (par "API de callback", un ensemble de pointeur de fonction C).

est-il possible d'accéder à l'instance de cette classe depuis mon plugin?

Oui, sans problème, mais vous devez prendre le pli de ne plus raisonner en objet mais en C (ou en C coloré à la POO via des HANDLE pour remplacer les this) quand vous devez passer à travers de l'API C.
C'est facile en plus avec un singleton.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
extern "C"
{
    typedef struct Info{
        char* valeur1;
        char* valeur2;
        int32 valeur3;
    }
 
    Info* getConfigInfo(){
        return Config::Instance.getInfo();
    }
}

Attention à bien fixer toutes les options possibles lors de la compilation de la définition de la structure "Info" pour qu'elle ne varie pas en fonction du compilateur (alignement, sizeof des types utilisés, le pragma pack, etc...).

Vous passez le pointeur sur la fonction "getConfigInfo" au plugins pour qu'il s'en serve.

[SheepSheep]

Merci pour votre réponse, je vais donc donner plus de détails.

Les plugins seraient sous la forme d'une fenêtre supplémentaire, par dessus la fenêtre principale. Il faut simplement qu'ils puissent utiliser les fonctionnalités du logiciel (via l'API) et accéder aux données courantes.

L'application est en C++ et utilise MFC. Comment fonctionnerait grosso modo un système de plugins fait avec MFC? Les plugins eux-mêmes devraient utiliser MFC également?

- le choix entre linkage intern et extern (je pense que intern est le mieux pour l'API?),

Je parlais du choix entre bibliothèque dynamique ou statique pour mon API.

- la mise à jour de mon application et donc de ma librairie entraînant une mise à jour du plugin,

Ce que je veux dire ici c'est que, par exemple, si mon logiciel propose une fonction de calcul, et que celle-ci évolue dans la version suivante de mon logiciel, alors l'API sera à la traîne. Y a-t-il un moyen d'appeler les fonctions courantes du logiciel ? (En gros juste établir la communication entre le plugin et le logiciel en cours d'exécution, et pouvoir utiliser toutes les fonctionnalités du logiciel dans le plugin).

Mais quelle approche ???

La création de l'API via un fichier api.cpp et un api.h, dans le projet de mon application + la création de plugins en .dll utilisant cette API.

Depuis hier, j'ai commencé à coder mon API en ajoutant un fichier api.h et un fichier api.cpp, qui instancie les classes nécessaires et appelle leurs méthodes (un genre de wrapper donc). Je l'ai linké en statique, sans utiliser "extern C" (je ne sais pas comment m'y prendre en statique à vrai dire).

Heu, là, je ne sais pas où vous voulez en venir. Si le cpp est compilé avec le projet, je ne vois pas où est vraiment votre "plugIns".

J'ai codé les fichiers api.cpp et api.h pour faire l'API, pas pour faire un plugin. Les plugins sont sous forme de .dll. Il faut bien ajouter ces deux fichiers api.cpp et api.h à mon application principale pour pouvoir créer ma librairie API, en livrant à l'utilisateur le .lib ainsi généré et le api.h ? Ou bien ça n'est pas la méthode à utiliser ?
Du coup je résume ce que j'ai fait pour que ce soit plus clair:
- une application C+++/MFC
- dans cette application, des fichiers api.cpp et api.h pour mon API, et j'exporte le tout en .lib et fournis le api.h
- un plugin manager, intégré à l'application, qui vient load les plugins
- des plugins en .dll

Mais c'est quoi vos contraintes/ cahier des charges ???

Difficile de vous donner les éléments clefs, ne sachant pas ce qui est déterminant pour choisir une bonne approche pour cette API et ce système de plugins. Le projet lui-même n'est pas totalement fixé puisque je découvre au fur et à mesure les différentes possibilités et les choix à faire. Si ce n'est toujours pas clair, pourriez-vous me poser des questions plus précises, ou bien me donner des exemples de choix selon différents cas ? Merci !

est-il possible d'accéder à l'instance de cette classe depuis mon plugin?

Le problème de cette solution c'est que pour accéder aux différentes classes de mon application C++, je vais devoir tout recoder sous forme de struct etc ?



Merci !

[bacelar]

OK, ça va être beaucoup beaucoup plus simple du coup.
De l’embarra du choix, vous tombez dans "c'est comme ça et pas autrement".

L'application est en C++ et utilise MFC.

MFC implique des contraintes assez strictes sur l'utilisation du mulit-threading, des ressources, de la manière de charger "correctement" les Dll, etc...

Les plugins seraient sous la forme d'une fenêtre supplémentaire, par dessus la fenêtre principale.

Donc "mélange" de l'IHM de plug-ins avec celle de l'application.(le seul fait de vouloir rester au dessus de la fenêtre de l'application, c'est déjà un "mélange").
MFC, la bibliothèque les plus "obsédé du contrôle que je connaisse" (elle colle son code en subclassing de fenêtre Kernel dans toutes les fenêtres de l'application), là, vous êtes dans la mouise si vous ne respectez pas SES règles.

En gros, utilisez des Framework de plugins pour MFC et n'essayez pas de faire le votre, c'est un travail d'horloger pour avoir un truc qui explose pas à l'ouverture de la première fenêtre.

Pas tester, mais mon ami Google me donne quelques résultats intéressants :
https://github.com/tianrolin/Plugin
https://www.codeproject.com/Articles...LL-plug-in-tec
https://stackoverflow.com/questions/...fc-and-c-sharp(via COM/ActiveX voir ci-après)

Bon, je pensais tomber sur plus de choses intéressantes avec Google mais, à la faiblesse du nombre de réponse, j'en déduis que les dernières versions des MFC, que je n'ai pas utilisé, n'ont pas trop axées leur évolution sur la mise en place de "Greffons/PlugIns" simples.
MFC a toujours eu une approche très "isolationniste" vis à vis des autres technologies, la solution classique pour l'extensivité des applications MFC, c'est les Dll d’extension MFC :
https://stackoverflow.com/questions/...fc-and-c-sharp
La seule concession faite par les implémenteurs des MFC vers l'interopérabilité, c'est de supporter les composants COM/ActiveX s'ils disposent des interfaces qui vont bien.
La possibilité d'héberger des contrôles .NET se fait indirectement via COM/ActiveX. Les composants .NET doivent être de composants COM "légal" pour s'intégrer dans une application MFC.

Les Framework de Plus-Ins MFC doivent utiliser ces pauvres fonctionnalités d'interopérabilité pour essayer de faire leur job.
Donc, commencez par évaluer ces Framework avant de vouloir faire une roue carrée.

Il faut simplement qu'ils puissent utiliser les fonctionnalités du logiciel (via l'API) et accéder aux données courantes.

Ce partager une IHM, c'est très loin d'être simple.

Comment fonctionnerait grosso modo un système de plugins fait avec MFC?

Nativement, qu'avec des Dll d'extension ou le hosting de composant COM.
Les Framework devraient planquer ça avec une API plus ergonomique.

Les plugins eux-mêmes devraient utiliser MFC également?

Oui, si c'est à base de Dll d'extention, non si c'est à base de COM/ActiveX.
Pour les composants non graphique, c'est possible de faire quand C++ "de base" mais attention au multi-threading.

Je parlais du choix entre bibliothèque dynamique ou statique pour mon API.

Un plug-ins, c'est un truc qu'on doit ajouter ou supprimer sans avoir à recompiler son exécutable, c'est donc forcement dans une Dll (bibliothèque dynamique), même si des parties du Framework d'interconnexion peuvent être en statique dans l'exécutable et/ou dans la Dll.

Ce que je veux dire ici c'est que, par exemple, si mon logiciel propose une fonction de calcul, et que celle-ci évolue dans la version suivante de mon logiciel, alors l'API sera à la traîne. Y a-t-il un moyen d'appeler les fonctions courantes du logiciel ? (En gros juste établir la communication entre le plugin et le logiciel en cours d'exécution

Oui, c'est une fonctionnalité de base de tout Framework de plug-Ins.
Le Framework fourni à la Dll une API de Callback qui permet à la Dll d'appeler les fonctionnalités dans l'exécutable.
Tant que la fonctionnalité de l'exécutable ne change pas d'API (nom et signature de la méthode de callback), les plug-ins seront compatibles avec les versions successives de l'exécutable (mais attention aux adhérences aux MFC qui pourraient casser la compatibilité en cas de modification de la version des MFC entre l'exécutable et les plus-ins)

, et pouvoir utiliser toutes les fonctionnalités du logiciel dans le plugin).

Il faut qu'elles soient au préalable définies dans l'interface de Callback.

La création de l'API via un fichier api.cpp et un api.h, dans le projet de mon application + la création de plugins en .dll utilisant cette API.

"api.cpp" est dans l'exécutable ou dans le plug-ins ???
Vous voulez partager du code (.cpp) entre l'exécutable et le plug-ins ? Attention à la dépendance très forte que cela implique (même compilateur, options compatibles, ...)
Regardez les exemples dans les Framework. Chacun a sa manière de faire.

Il faut bien ajouter ces deux fichiers api.cpp et api.h à mon application principale pour pouvoir créer ma librairie API, en livrant à l'utilisateur le .lib ainsi généré et le api.h ? Ou bien ça n'est pas la méthode à utiliser ?

Regardez les exemples dans les Framework. Chacun a sa manière de faire.(BIS)
Mais, généralement, un .h devrait faire l'affaire.

Du coup je résume ce que j'ai fait pour que ce soit plus clair:
- une application C+++/MFC
- dans cette application, des fichiers api.cpp et api.h pour mon API, et j'exporte le tout en .lib et fournis le api.h
- un plugin manager, intégré à l'application, qui vient load les plugins
- des plugins en .dll

OK, sauf le .lib qui n'est pas forcement utile, voir en fonction du Framework utilisé.

Le problème de cette solution c'est que pour accéder aux différentes classes de mon application C++, je vais devoir tout recoder sous forme de struct etc ?

Voyez ce qu'offrent les Framework, mais s'ils sont très permissifs sur ce sujet, il y a de bonne chance que cela implique un couplage fort entre l'exécutable et les plug-ins, à moins de se baser sur un standard binaire de représentation des données comme l'offre COM/ActiveX.

[Mat.M]

Bonjour,
Je travaille actuellement sur une application en C++. J'aimerais créer une API pour cette application qui me permettrait d'utiliser ses fonctions depuis l'extérieur. En effet, j'aimerais pouvoir utiliser cette API pour créer des plugins en C++ pour cette application.

le plus simple c'est de commencer par compiler un fichier .lib ou une dll "simple".

Merci pour vos conseils. J'y ai réfléchi et j'ai décidé de faire un plugin sous forme de DLL d'extension MFC, qui affiche lui-même une fenêtre en plus de la fenêtre principale. Comme MFC gère tout ça, et que l'appli et l'extension sont très liées, il n'y a pas de souci à priori.

en général en programmation windows on a recours à des plug-ins développés avec l'architecture Component Object Model plutôt que MFC...

Je sais que ms-office par exemple c'était à 90% peut-être bâti sur une architecture COM maintenant je crois que c'est tout en NET

le projet sur lequel j'avais travaillé d'imagerie médicale c'était majoritairement des plug-ins COM qui sont encore utilisés avec un frontal sous C#/.NET
l'appli avant utilisait VB6 comme ça ça permettait dans le code VB de faire new d'un objet C++.
L'avantage des objets COM c'est qu'ils sont enregistrés dans la base de registre, on peut en charger plusieurs instances
Mais c'est trop complexe pour être expliqué ici

Maintenant je bloque sur l'appel des fonctions de mon Api (qui sert d'interface entre les fonctionnalités de mon application et la DLL) depuis la DLL. Le but étant que la DLL puisse utiliser des fonctionnalités de mon application.

d'où l'intérêt d'une DLL COM ça permet de s'interface plus aisément qu'une dll MFC

J'ai également une question plus avancée:
Est-il possible de faire communiquer un plugin avec l'application qui l'a chargé? Je m'explique: imaginons que mon application ait une classe "Config", singleton, qui contienne des infos en "temps réel" (selon les dernières modifications de l'utilisateur pendant l'exécution de l'application), est-il possible d'accéder à l'instance de cette classe depuis mon plugin?

pour faire communiquer l'application soit on utilise des "pipes" en win 32 soit encore une fois des "fires" avec un objet COM

Le projet d'imagerie médicale sur lequel j'ai travaillé c'était le cas..

L'application est en C++ et utilise MFC. Comment fonctionnerait grosso modo un système de plugins fait avec MFC? Les plugins eux-mêmes devraient utiliser MFC également?

utiliser les MFC c'est du 50/50 perso je ne le ferais pas et puis l'API win32 c'est pas si compliqué que cela
MFC simplifie le travail mais ça fait des exécutables plus lourds ou alors il faut redistribuer le runtime

Je pense que tu cherches un peu trop "générique", il faut focaliser tes recherches sur tes besoins précis.
MFC est un Framework graphique d'assez bas niveau ( en terme d’abstraction ).

mais non pas du tout MFC n'est pas bas-niveau.
1-MFC c'est un équivalent de NET (avant la mise en servide de NET ) mais pour le C++ ( quoiqu'on peut faire du code managed en C++ )
Avec MFC on peut créer des fenêtres en 2 ou 3 lignes là où en win32 il faut 50lignes

2- pour un plug-in oui il faut faire forcément générique sinon ça n'a pas d'intérêt donc proposer un certain niveau d'abstracvtion

J'ai déjà fait des trucs où l'interface était créée à partir de méta données contenus dans une base relationnelle, donc c'est possible, et sans utiliser COM/OLE Control/ActiveX, donc il n'y a pas qu'une solution.

oui d'accord mais pour un projet conséquent vaut mieux utiliser COM/Active X...
parce que l'intérêt c'est que le client en NET, VB6..peut instancier des objets