Discussion :

[ClaudeBg]

Bonjour,

Je voudrais un conseil sur la (les) bonne(s) technique(s) pour réaliser un projet modulaire. Je m'explique (désolé, c'est un peu long, mais je pense nécessaire pour cerner la question) :

Le système comporte une série de cartes électroniques disposant de leur propre logiciel embarqué sous microcontroleur (tout ça, ça fonctionne déjà).

Il y a aussi un logiciel de paramétrage et de configuration tournant sur PC, et c'est ce qui concerne ma question. Pour l'instant, ce logiciel tourne en Vb6 et se présente comme un "bloc" non objet. Chaque ajout d'une nouvelle carte impose de revoir l'intégralité de ce logiciel parce que tout communique.

Vu les nouvelles fonctionnalités prévues, c'est devenu ingérable, et c'est pourquoi je vais réécrire le logiciel de gestion en C# dans une philosophie "pur objet". Ceci va me permettre d'intégrer une série de nouveaux modes pas encore existants.

Je souhaite donc réaliser un "logiciel de base", contenant toutes les fonctions "standard" et qui resterait "immuable (sauf correctifs ou updates évidemment).

Et, en //, pour chaque carte, proposer à l'utilisateur un "pack" contenant tout ce qui est nécessaire pour la construction de la carte électronique ET (et c'est là où on arrive au coeur du problème) une dll (ou autre) à placer dans le répertoire du logiciel "principal".

Le logiciel principal, une fois lancé, devrait pouvoir "reconnaître" le matériel à gérer en fonction des librairies installées, et chaque dll devrait pouvoir être "construite" indépendemment du programme principal (méthodes et propriétés respectant un schéma imposé).

De là, mes questions sur la meilleure façon de procéder, dont :

- Comment gérer par le programme principal les librairies ajoutées? (simple "scan" du répertoire??), et comment les instancier dynamiquement?

- Comment "imposer" les noms des méthodes et propriétés : une interface? Obliger à dériver de classes abstraites? Autre méthode plus efficace?

- Comment travailler sur la solution en entier (tester les communications etc) SANS devoir copier manuellement les librairies regénérées dans le répertoire du programme? Bref, comment avoir en mode "exécution par l'utilisateur" un mécanisme d'auto-détection des librairies tout en ayant en mode "debuggage par moi-même" la souplesse d'une solution "intégrée"?

Il s'agit d'un projet qui tourne déjà et dont le développement devrait encore se poursuivre sur plusieurs années. L'état actuel m'impose de revoir le programme "pc" en intégralité, mais je voudrais ne recommencer ça (c'est du boulot) qu'une seule fois, et donc partir sur les bases idéales, d'où mes questions.

En espérant que quelqu'un puisse me fournir des pistes intéressantes, merci d'avance,

Claude

PS : Le projet est open-source

[Graffito]

- Comment "imposer" les noms des méthodes et propriétés : une interface? Obliger à dériver de classes abstraites? Autre méthode plus efficace?

Dériver d'une classe de base avec des methodes abstraites et des méthodes standard qui seront surement aussi utiles.

Comment travailler sur la solution en entier (tester les communications etc) SANS devoir copier manuellement les librairies regénérées dans le répertoire du programme? Bref, comment avoir en mode "exécution par l'utilisateur" un mécanisme d'auto-détection des librairies tout en ayant en mode "debuggage par moi-même" la souplesse d'une solution "intégrée"?

Une solution commune avec des #ifdef référant à des variables du projet.
et aussi, si necessaire, pour partager les sources entre différents projets faire (termes de la version US) "Add Existing Item" et "Add as Link".

[Philippe PONS]

Salut,

Dans l'atelier 4 du coach C#, il y a une partie "DEVELOPPER UNE EXTENSION A VOTRE APPLICATION" qui, je pense, correspond à ce que tu cherches.

Philippe


http://msdn.microsoft.com/fr-fr/vcsh...boratoire.aspx

[ClaudeBg]

Merci pour les réponses.
Désolé pour le retard de réaction, j'étais malade

Claude