Bonjour,

Je suis développeur dans l'industrie, et nous utilisons parfois du matériel ancien pour la communication.

Nous développons actuellement en C# WPF avec le Framework 4.8 en x86 afin d'assurer la compatibilité avec les DLL fournies par nos fournisseurs.

Nous allons commencer une phase de refonte de notre logiciel principal pour le passer en 64 bits avec .NET. Cependant, cette migration pose problème, notamment avec un groupe de trois DLL en x86. L'une est en C# (une DLL managée), et les deux autres sont en C et C++ (non managées).

[CONTEXTE]
Je pense que notre fournisseur devra nous fournir une version x64 de la DLL managée ainsi que de la DLL C++, car il vend toujours ces produits. En revanche, nous avons un parc important d'appareils utilisant l'ancienne DLL en C, (matériel qui n'est plus fabriqué). Nous avions déjà rencontré des problèmes lors d'une mise à jour de la DLL managée, qui ne fonctionnait plus avec l'ancienne version. Il avait été compliqué de lui faire ajouter la fonctionnalité nécessaire (uniquement un souci de vitesse du port COM, l'ancienne communique en 9600 bauds, contre 115200 bauds pour la nouvelle).

Je suis persuadé que ce sera de plus en plus difficile d'obtenir ces mises à jour pour l'ancien modèle.

Dans tous les cas, notre logiciel principal passant en x64, nous ne pouvons plus communiquer directement avec la DLL managée. Nous envisageons donc de créer un service intermédiaire qui gérera les DLL et la communication avec les appareils, en utilisant des Pipes ou des Sockets. Cela permettrait d'avoir un logiciel en x64 tout en gérant les DLL en x86.

Je serais plus partant pour l'utilisation de Sockets, car cela permettrait d'externaliser la gestion des DLL sur un autre PC acceptant le 32 bits, Microsoft voulant supprimer l'utilisation de logiciels 32 bits. Même si je suis sûr que cela n'arrivera pas tout de suite, cela arrivera un jour, j'espère après ma retraite.

La DLL managée en C# sert d'interface avec la DLL C++. Comme notre fournisseur nous fournissait les trois DLL ensemble, nous pensions que la DLL managée basculait entre la C++ et la C selon le matériel connecté, mais ce n'est pas le cas. Après analyse (décompilation pour voir comment il gérait le switch du port COM), il s'avère que la DLL managée utilise uniquement la DLL C++, qui contient des méthodes spécifiques présentes dans la DLL en C. Le problème c'est qu'il n'y a pas toutes les fonctionnalités. Dans un projet récent j'ai été obligé de couper la liaison avec la DLL managée afin de me reconnecter en direct la DLL C .[DllImport(@"DLLEnC.dll")], retrouver la définition des méthodes que j'avais besoin, heureusement j'ai la Doc d'origine en C.

Nous prévoyons donc de créer notre propre DLL managée uniquement pour l'ancienne DLL en C. Une fois cela fait, nous n'y toucherons plus, car elle ne sera plus mise à jour, mais j'ai quand même plus de 100 fonctions à remettre en place.

Pour le moment, en phase de pré-étude, nous envisageons donc la configuration suivante : Logiciel 64 bits --> service avec "Sockets" en 32 bits --> les deux DLL managées en 32 bits --> vers chaque DLL non managée respective. Le service s'occupera de basculer vers l'une ou l'autre des DLL selon le matériel connecté ainsi que gérer les re tentative en cas d'erreur voir reconnexion (certains équipement sont parfois compliqué a répondre). Pour la première connexion, nous utiliserons la DLL en C++ car elle sait détecter la génération de matériel, en espérant qu'elle continuera à le faire.

Je ne sais pas si c'est utile de le préciser, mais le dialogue entre le logiciel et les DLL comporte des paramètres de différents types, un ou plusieurs paramètres pour chaque fonction. Le retour est également variable, avec les mêmes types pour les opérations Get ou Set. Il faut aussi pouvoir gérer plusieurs dialogues en même temps. Actuellement, j'ai un projet avec trois lecteurs, ce qui me permet d'avoir trois appareils en même temps. Il faut donc pouvoir initialiser un nombre de sessions.

[/CONTEXTE]


Mais avant de nous lancer, j'aimerais avoir votre avis. Avez-vous déjà été confronté à l'utilisation de DLL 32 bits avec un logiciel 64 bits ? Si oui quelle a été votre stratégie?

Merci