Migration des macros Excel

Bonjour,

Nous avons développé plus de 300 macros Excel avec le VBA.
Aujourd'hui notre entreprise nous demande de migrer nos outils sous C# car le VBA ne sera plus autorisé.

Notre outil de travail étant Excel, nous n'allons pas développer des programmes autonomes mais bien externaliser notre code qui pilotera toujours Excel.

Dans quelle direction devons nous partir?
Nous avions imaginé un frontal exe (sorte de vitrine de sélections d'outil) et une dll par macro convertie afin de faciliter les mises à jour et le déploiement. Est ce une bonne solution?

Ensuite, il faudra travailler avec de l'interop Excel. Est ce la meilleure solution?

Merci pour vos conseils.

Bonne journée,
Batseb

C'est une question qui peut amener un éventail de réponses très large.
L'idée d'une DLL par Macro est bien, mais n'est-elle pas un peu overkill?
Ensuite, beaucoup va dépendre du contenu des fichiers Excel. Ne contiennent-ils que des données bien organisées (et bien formatées), ou y'a-t-il également des graphiques, des TCD, combien de lignes, combien de cellules avec des formules? Cela va influencer la prise de décision.
Si les données sont bien organisées, pourquoi ne pas envisager une solution avec une base de données et un outil de reporting (par exemple SQL Server et SQL Server Reporting Services (ce qui au passage permettrait de centraliser les données)?

Sinon, pour revenir à la question de départ, Interop marche bien, mais lentement. Vous pouvez aussi utiliser une connection OleDb et manipuler les fichiers comme un BDD (ici, un article assez complet)

Désolé de ne pas pouvoir donner de réponses plus précises...

Bonjour,

Je dirais qu'il s'agit plutôt d'une décision macro par macro, ou classeur par classeur et de l'obligation de vraiment utiliser Excel ou non. Et évidemment, pour quand tout cela doit être réalisé.

Dans les cas, où il s'agit juste de lire des données dans un feuille et de procéder à des calculs et réenregistrer dans un fichier. une solution de lecture des données dans Excel avec ado.net, calculs dans C# ou VB.net et mise à jour des données dans le même classeur devient intéressante, grâce à la compilation.

Dans le cas où Excel est vraiment, ou même juste pratiquement, indispensable comme pour de tableaux croisés dynamiques, Interop constitue peut-être un meilleur choix. (À moins d'avoir un as capable de reprogrammer des TCD en C aiguisé en un temps record et sans causer d'erreurs.)

Dans les cas où il y a usage de graphiques, c'est une autre histoire. Il faut choisir entre Interop, et garder les graphiques d'Excel, ou réécrire les routines graphiques en C#. Parce que, sauf erreur de ma part, et que ce n'est (pas) vraiment (pas) ma spécialité, je ne pense pas qu'il existe de moyen de convertir automatiquement et sans huile de bras les graphiques Office en graphiques .net. Sauf peut-être des outils spécialisés et possiblement onéreux.

D'un autre côté, dans l'idée où vous auriez des classeurs Excel prévus pour une utilisation "spécialisée" avec des macros qui sont incluses dans le classeur et qui ne serviraient que pour ce classeur, vous pourriez envisager de faire une application (essentiellement une dll ) (anciennement macro-complémentaire, complément, add-in, add-on etc.) spécifique pour ce type de classeur.

Si vous n'êtes pas tenus de recourir a C#, et que vos versions d'Excel (d'Office en fait) sont assez récentes, Microsoft a développé une nouvelle API pour Office qui fait une utilisation poussée de JavaScript.

Et puis là, je n'ai pas encore parlé de System.io.Packaging qui permet de lire, écrire et modifier les fichiers Office au format OpenXML. (Les fichiers Office depuis Office 2007).

Et je n'ai pas parlé non plus du SDK OpenXML qui facilite la vie (enfin c'est ce qu'il disent, même si ce n'est pas encore du gâteau) en encapsulant les éléments pertinents de System.IO.Packaging dans des classes dédiées, mais il est limité à Excel, Word et PowerPoint.

Pour écrire des documents Word, ou des Classeurs Excel, il y a des petits malins qui ont utilisé le SDK Open XML pour ".nettiser" l'écriture et l'exploitation de fichiers Word (DocX) ou Excel (ClosedXML ou EPPLus).

Quelques liens qui pourraient vous être plus ou moins utiles dans l'immédiat:

DocX


ClosedXML


EPPlus

SDK Open XML en ligne

SDK Open XML hors-ligne et la dll indispensable

Documentation Office sur MSDN

Office et VSTO/Office Tools for Visual Studio

Macros xll pour Excel

Mais comme disait un ancien instructeur des Canadiens de Montréal, Claude "Piton" Ruel : "Y'en aura pas de facile."

P.S. Je rajoute en vitesse et sans avoir vraiment de réponse précise en tête. Vérifiez si vos macros font du pilotage d'autres applications. Je ne sais pas trop là quoi faire avec cela (C# qui piloterait directement Excel et l'autre application avec Interop, je pense). Mais cel va demander révlexion.

Bonjour,

Merci pour ces pistes. C'est très intéressant.
ClementMarcotte, merci pour les sources d'information que tu proposes, j'ai commencé à les lire.

Pour avancer sur ma décision,

voici quelques précisions :
- nous manipulons des exports issus de notre ERP (format spool) ou d'autres systèmes (classeurs excel, CSV) ou pages Web
- nous effectuons les mise en formes, calculs, tableaux pour présenter les données à l'utilisateur final
- les fichiers sources ne sont donc pas formatés, pas de cle primaire, et souvent avec une obligation de nettoyer le fichier pour obtenir un vrai tableau de données

voici des précisions sur les classeurs Excel utilisés :
- de 100 lignes à 200000 lignes
- de 2 colonnes à 50 colonnes
- de 2 onglets à 10 onglets
- mise en page
- formules
- TCD / segments
- Graphiques

voici les contraintes de mon entreprise :
- pas de développement direct dans l'ERP
- pas de connexion directe à l'ERP et aux autres systèmes
- pas d'ajout de composants supplémentaires autre que Office 2013, Visual Studio 2015 et Framework .Net 4.5 (même gratuits!)
- suppression imminente de l'accès au VBA et à l'utilisation du VBA dans tous les classeurs Excel
- notre base de données est ACCESS pour certaines macros (autorisée, elle fait partie d'Office ;-))

Cela ne me laisse pas beaucoup de choix...
C'est pour cela que je pensais à un frontal EXE et une dll par macro (car chacune d'elle est un outil d'analyse spécifique)
Le frontal ouvrirait la DLL concernée, piloterait le classeur avec ses fichiers sources.

La DLL peut elle contenir un UserControl qui contiendrait ses boutons spécifiques et qui s'afficherait dans le frontal quand elle serait appelée?

Merci pour votre aide, la migration doit commencer dès janvier 2017 donc je ne voudrais pas partir dans une mauvaise direction.

Bonne journée,
batseb

Bonjour,

Donc, si je comprends bien, ton application ne sera pas accessible aux utilisateurs finaux ? On parlerait en fait d'une sorte de "courtier" ou de "grossiste" qui récupère des données qui pourraient être disparates et qui distribue une solution, disons clef-en-main, à des utilisateurs finaux ?

Si jamais, c'était le cas, je penserais plus à une application peut-être, ou même peut-être pas, plus imposante, avec un nombre suffisant de classes, au pire peut-être autant de classes que de macros, ce sera à toi de voir.

À vrai dire, je trouve que de refaire et valider une DLL à chaque modification de "la commande" me semble (très) lourd. Surtout, si jamais le nombre de dll devait augmenter. Alors que juste modifier et tester une classe dans une "application permanente" est probablement plus court et plus simple à gérer.

Désolé pour la quantité de réponses, je pensais avoir beaucoup moins de résultats. Toutes sortes d'articles pour construire une application .net qui accepte des plug-ins. Dans l'idée où chaque macro pourrait devenir un plug-in que ton application utiliserait au besoin. Je ne sais absolument pas si ce serait mieux que des dll plus conventionnelles. Encore qu'un plug-in ou une dll, cela reste encore du travail de gestion...

Et puis, plus pour le fun. Une façon d'importer un fichier texte (ou même csv) dans un programme C#. (J'en ai fait une version VB, parce que C#, ce n'est pas ma préférence et surtout pas ma spécialité. mais bon...)

En fait, notre service met à disposition des utilisateurs finaux les outils qui permettent de mettre en forme et d'effectuer les calculs nécessaires à partir de leurs fichiers sources.

On leur crée les leviers, les commandes et ce sont eux qui les manipulent.
Avant, on leur fournissait pour chaque outil, une macro avec des boutons et le code VBA qui va bien (généralement : IMPORTER, CALCULER, METTRE EN FORME, EXPORTER)
Demain, on nous demande de faire la même chose mais sans passer par le VBA.

Bien sûr, 350 outils à manipuler, ca faisait 350 macros.
Demain, ca ferait 350 DLL?

Merci,

Bonjour,

C'est ce que je crains, oui.

À moins de pouvoir piger un ensemble de bouts de codes source plus ou moins indépendants (au pire, une macro une classe) et de les regrouper ensemble dans une application que tu lierais au classeur de ton client, sous la forme d'une application avec VSTO/Office Tools for Visual Studio. (C'est dans ma pile de liens.) Là tu serais plus dans une vision de 1 dll par classeur que tu bâtirais à partir de tes codes existants, en ajoutant ce qui manque. Je suis presque sûr, (je me garde quand même une petite gêne) que tu pourrais inclure une Form avec les contrôles qui conviennent à ta DLL, ou même un Ruban ad-hoc). Ou si tu n'as pas besoin d'un menu élaboré, tu peux penser à une bibliothèque de classes dans laquelle tu ajouterais quelques instructions nécessaires pour la rendre utilisable par Office. Notamment la visibilité par COM et certaines entrées de registre dédiées aux applications Office. Selon ta version de VisualStudio, VS peut se charger en tout ou en partie de la visibilité/compatibilité avec COM, mais ce serait à toi de récupérer le GUID de la dll et de composer les instructions d'inscription dans le registre.

Bonjour,

J'ai pensé à tout cela à tête reposée et il semblerait que ma formation de gestionnaire a pris le dessus et j'ai un peu brassé la sauce.

Si j'ai bien compris tu as actuellement un certain nombre d'utilisateurs qui utilisent un certain nombre de classeurs qui contiennent un certain nombre de macros.

Et la commande consiste(rait) à remodeler ces classeurs de façon à ce qu'ils conservent leurs fonctionnalités, mais en remplaçant les macros VBA par du code C#.

Le corollaire de la commande est de s'assurer que les développements futurs doivent passer par C#.

Ton souhait est d'avoir une application standardisée pour choisir une dll convenant à chaque classeur particulier.

Mais, là j'ai l'impression qu'en voulant une application unique tu risques de paralyser beaucoup (trop) d'utilisateurs en même et de te faire lyncher. Parce que le temps que tu vas passer à créer ton application unique, tu ne pourras probablement pas développer les nouvelles applications pour les nouveaux besoins, et tu risques aussi de devoir bloquer plusieurs classeurs existants en même temps, pour ajuster le tout.

Mais, tu n'as pas encore converti to code VBA en code C#, et dans l'absolu, deux classeurs qui auraient besoin du même code pour générer des graphiques, devraient avoir la même procédure C# au lieu de toujours reprendre de zéro.

Pour t'assurer que les choses puissent continuer de tourner à peu près normalement durant la période de transition, j'ai l'impression que tu devrais procéder classeur par classeur et envisager une application temporaire pour chaque classeur. Cela te permettrait de réviser chaque classeur indépendamment des autres et de minimiser les risques de blocage de toute la compagnie. En même temps, tu vas acquérir une connaissance profonde des aménagements à apporter à ton application globale finale, ou, en voyant chaque classeur individuellement, tu devrais voir dans quelle mesure ton application unique et un parc de dll est possible. De toutes façons, tu ne peux pas échapper à la conversion de chaque macro individuelle, même si c'est juste pour en fusionner deux dans une seule.

Déjà que même la conversion directe de VBA en VB.net est impossible, tu vas devoir ajouter la traduction en C#. Même les UserForms de VBA doivent être repris de 0.

Et puis, une chose qui n'a pas été abordée est la suppression du module VBA des différents classeurs. Pour un classeur au format xlsm directement créé dans Excel 2007 et les versions suivantes ou enregistré par Excel 2007 et suivant en oubliant le mode de compatibilité, cela peut se faire les yeux fermés avec le SDK Open XML. Pour les xls, tu vas probablement devoir le faire manuellement.

Merci pour vos réponses.

Bonne journée.
Batseb