Migration WinDev vers C# : premiers constats et pistes explorées

[Wd_newbie]

Up

1

Down

::

Comme beaucoup, la nouvelle politique commerciale de PC Soft m’a poussé à envisager sérieusement la migration de mes applications vers un autre environnement de développement.

Mon choix s’est naturellement porté sur C#, un langage qui m’a toujours intéressé. Son écosystème open source me semble également plus rassurant et pérenne que des solutions comme Xojo ou Delphi. J’ai également regardé Lazarus, mais son aspect visuel et son approche de l’interface utilisateur me paraissent un peu datés pour les projets que je souhaite développer aujourd’hui.

Mon objectif n’est pas de retrouver un clone de WinDev, mais plutôt de m’assurer que toutes les fonctionnalités dont je me sers quotidiennement dans mes logiciels puissent être reproduites dans un environnement C#.

J’ai donc dressé une liste des points qui me paraissent indispensables :

• Base de données locale et client-serveur.
• Gestion des paramètres via JSON.
• Génération d’états et de rapports personnalisables.
• Compilation ou exécution dynamique de code.
• CRUD simple à mettre en œuvre.
• Composants de type DataGrid performants.
• Gestion des migrations de base de données.
• Gestion des e-mails.
• Gestion des transferts FTP.
• Sauvegarde intégrée des données.
• Interface utilisateur moderne.
• Et certainement quelques autres fonctionnalités auxquelles je ne pense pas encore.

Après plusieurs semaines de tests, voici où j’en suis.

Base de données locale et client-serveur

Dans un premier temps, je me suis orienté vers SQLite pour le mode local et MariaDB pour le mode client-serveur.

Les tests étaient concluants, aussi bien en termes de fonctionnalités que de sauvegardes. En revanche, le fait de travailler avec deux moteurs et deux formats de fichiers différents complique fortement la possibilité de faire évoluer une installation d’un mode local vers un mode client-serveur, ou inversement.

Après quelques recherches, je me suis intéressé à Firebird. Son principal avantage est de proposer un mode embarqué (Embedded) et un mode client-serveur tout en utilisant le même fichier de données.

Pour l’instant, les premiers essais sont très prometteurs. Cela correspond bien à mes besoins, même si ceux-ci restent relativement classiques en matière de bases de données.

Gestion du JSON

Rien de particulier à signaler sur ce point.

La gestion du JSON est intégrée nativement à .NET et répond parfaitement aux besoins de stockage des paramètres locaux.

Génération d’états et de rapports

C’était probablement l’un des sujets qui me préoccupait le plus.

J’ai examiné plusieurs solutions existantes, souvent payantes, mais aucune ne répondait réellement à mon cahier des charges :

• possibilité de modifier les états sans recompiler l’application ;
• personnalisation locale ou partagée ;
• intégration directe dans le logiciel ;
• coût raisonnable.

J’ai finalement opté pour une solution maison basée sur Scriban, un moteur de templates open source permettant de générer du HTML.

Le principe est simple :

• un modèle HTML/CSS de base est intégré à l’application ;
• lors du chargement d’un état, le logiciel recherche une éventuelle version personnalisée dans les répertoires locaux puis partagés ;
• si aucune personnalisation n’est trouvée, le modèle intégré est utilisé.

On retrouve ainsi une logique assez proche d’États et Requêtes.

Les états sont affichés dans une WebView pour l’aperçu avant impression, puis peuvent être imprimés ou exportés au format PDF.

J’ai également intégré un éditeur permettant de modifier directement le HTML et le CSS depuis l’application. Les utilisateurs avancés peuvent ainsi personnaliser leurs documents sans avoir à intervenir dans le code source.

Compilation et exécution dynamique de code

Je n’ai pas encore réalisé beaucoup de tests sur ce sujet.

Cependant, Roslyn, le compilateur C# open source de Microsoft, permet la compilation dynamique de code à l’exécution.

Sur le papier, cela semble répondre à mon besoin principal : ajouter des scripts, des hooks ou des extensions sans devoir recompiler l’application complète.

C’est un point que je compte approfondir dans les prochaines semaines.

CRUD et accès aux données

Je me suis orienté vers Entity Framework Core.

Le principe est intéressant : les classes du modèle définissent la structure des données et EF Core se charge de créer ou mettre à jour la base.

Le fonctionnement est très puissant, mais je le trouve également assez lourd comparé à ce que propose WinDev.

Les migrations automatiques fonctionnent correctement et permettent de faire évoluer la structure de la base lors des changements de version.
Malgré cela, je me demande encore si je ne vais pas développer un mécanisme simplifié inspiré de WDModFic pour gérer certaines évolutions de structure et les conversions de données.

Si certains ont trouvé une approche plus simple ou plus élégante, je suis preneur de leurs retours.

Gestion des e-mails

Les tests réalisés avec MailKit sont très concluants.
La bibliothèque est mature, gratuite, open source et couvre l’ensemble des fonctionnalités dont j’ai besoin pour l’envoi et la réception d’e-mails.

Gestion des transferts FTP

Pour cette partie, j’utilise FluentFTP.

Je l’utilisais déjà depuis WinDev au travers d’assemblages .NET afin de contourner certaines limitations liées aux versions récentes de TLS.
Les tests réalisés en C# sont parfaitement concluants.

Sauvegarde des données

J’ai effectué plusieurs essais avec SQLite et MariaDB.

Les sauvegardes et restaurations fonctionnent sans difficulté particulière et des bibliothèques existent pour automatiser ces opérations.
Comme je m’oriente désormais davantage vers Firebird, je n’ai pas poursuivi plus loin ces développements sur mon application de test.

Interface utilisateur

C’est probablement le domaine sur lequel j’ai le plus changé d’avis.

Mes premiers essais ont été réalisés avec WPF.

Même si les possibilités sont importantes, je trouve personnellement l’expérience de développement assez complexe. L’éditeur visuel ne m’a jamais vraiment convaincu et j’ai souvent eu l’impression de devoir écrire une grande partie du XAML à la main.

Je reconnais toutefois que les outils d’IA m’ont beaucoup aidé à franchir cette étape.

Le principal inconvénient de WPF reste son orientation exclusivement Windows.

Or, même si Windows demeure aujourd’hui ma cible principale, je n’exclus pas la possibilité de viser d’autres plateformes à moyen terme.

C’est pourquoi je m’intéresse actuellement à MAUI et surtout à Blazor Hybrid.

L’approche me semble particulièrement intéressante :

• composants réutilisables ;
• interface basée sur HTML et CSS ;
• possibilité de mutualiser une grande partie du code ;
• ouverture vers plusieurs plateformes.

Pour quelqu’un qui possède également une expérience du développement web, la prise en main est beaucoup plus naturelle que celle de WPF.

Conclusion

Je n’en suis encore qu’au début de cette migration et je découvre progressivement l’écosystème C#.

Pour le moment, je n’ai trouvé aucun équivalent direct à WinDev, mais j’ai l’impression qu’il existe une réponse à pratiquement chaque besoin, souvent sous la forme de bibliothèques open source spécialisées.

A ce stade, j’ai pu retrouver une partie des fonctionnalités voulues, et sans payer 250 € par poste, 120 € par chaise et avec un supplément de 22 € si l’utilisateur a des lunettes 😊

Si certains d’entre vous ont déjà effectué une migration WinDev vers C#, je serais très intéressé par vos retours d’expérience, notamment concernant :

• 1 – les migrations de base de données ;
• 2 – les moteurs d’états ;
• 3 – l’exécution dynamique de code ;
• les DataGrid ;
• 4 – la gestion des personnalisations utilisateurs ;
• … ou tout autre point qui vous a posé problème lors de votre transition.

Merci d’avance pour vos conseils et retours d’expérience.

 

 

 

 

Pièces jointes (max.4x512kb):

You must be logged in to view attached files.

[Wd_newbie]

Up

0

Down

::

Avec une interface Blazor

Pièces jointes (max.4x512kb):

You must be logged in to view attached files.

[Didier Fournier]

Up

0

Down

::

Très intéressant, merci pour ce partage.

[Sitolog]

Up

0

Down

::

Je viens de commencer à regarder la série de tuto microsoft sur Blazor. Je trouve l’ensemble avec C# MAUI dans VS cohérent.
Mais ce qui me semble comprendre, c’est que même avec cet ensemble de couches à apprendre et maitriser, on n’a toujours pas d’interface graphique pour construire les UI (genre WPF, mais multi plateforme).
Il faut construire ses UI en codant du HTML/CSS. Exact ?

Cela me semble fou qu’en 2026 on en soit encore la. Il existait des outil de dev de site HTMl en no code il y a 20 ou 30 ans. Quel recul…

J’espère me tromper. Pas de petit pluggin qui se greffe sur ce stack, pour pondre le HTML/CSS à la souris avec une bibliothèque de composant graphiques réutilisables ?

[Wd_newbie]

Up

0

Down

::

Effectivement ce serait pas mal d’avoir une éditeur WYSIWYG, mais visiblement à part un un deux truc pas vraiment finalisé, on ne trouve pas grand-chose

Bon Blazor c’est un espèce de HTML/Css (je teste plutôt MudBlazor) , c’est moins fouillis que le WPF à mon sens.

En PJ une image de mes premiers tests en Blazor Hybride  : gestion de la connexion a une base Firebird en mode local / CS.
C’est fonctionnel, ça gère la création de la base si elle n’existe pas / le test de connexion

Pièces jointes (max.4x512kb):

You must be logged in to view attached files.

[Wd_newbie]

Up

0

Down

::

Bon les premiers tests sous Blazor Hybrid son assez concluants :

– interface en HTML / css
– connexion a des données sous Firebird en mode embeded (local) et serveur
– interaction CRUD avec la base relativement simple

Pour la gestion de la base, j’utilise Beaver Community : multibase et open source (gratuit pour un usage commercial également).
C’est nettement au dessus de HeidiSQL que j’utilisait avec Laragon (php)

Pour l’instant le projet de mise en place d’un environnement de base en Blazor avance bien.

Je vais poursuivre en mettant en place ce que j’avais testé sous WPF : un éditeur d’état maison en HTML/css avec le moteur Scriban (open source et gratuit)

A suivre …

Pièces jointes (max.4x512kb):

You must be logged in to view attached files.

[Auteur]

Messages