Automation Excel Mutliversion (Tartine !)
Bonjour la communauté !
sur le long chemin de l'apprentissage du VB.NET, voici que je bute sur une nouvelle pierre (ouch !). Ca fait pas mal de temps que je m'essore ce qui me sert de cerveau et mon petit esprit fécond (en un mot svp) est arrivé à ces 3 théories, mais ne sait faire la part des choses. Je pense que je pars un peu tous azimutes donc veuillez pardonner mes idées foles de débutant !
Je travaille sur des programmes qui ont pour vocation d'être utilisée sur des postes ayant des versions d'Excel (ou même Accèss) différentes voire même aucune, et je dois donc faire en sorte qu'elle fonctionne sous 2003 / 2007 / 2010, donc les version 9.0, 12.0 et 14.0 si je ne me trompe pas. A moins qu'il ne soit possible de se passer carrément de la version présente sur la machine.
Voici le point de mes reflexions et recherches à ce jour :
1 - Il est possible de détecter la version d'Excel présente sur la machine où s'exécute le programme afin d'importer le bon assembly avant d'exécuter le code. Mais sur ce point, la seule méthode que j'ai trouvée consiste à ouvrir Excel et faire un
Code:
Application.Version
, ce qui me dérange un peu car certaines machines sont lentes et ouvrir Excel prend déjà 20 secondes... (eh oui, on a encore des mahcines comme ça !) d'autant plus que pour faire appel à l'assembly d'une version d'Excel, je crois avoir compris qu'elle doit au moins être installée sur la machine où je développe le programme pour le sélectionner dans les références COM. Ce qui n'est naturellement pas le cas. Et ça me semble un peu invraisemblable de penser que tout développeur d'automations sur la Suite Office doit avoir toues les versions sur son poste.
2 - J'ai trouvé une astuce qui propose de ne pas appeler Excel par la commande
Code:
Dim XlApp As Excel.Application
mais par la commande
Code:
Dim XlApp As Object
et continuer ensuite le code de manière classique
Code:
XlApp = CreateObject("Excel.Application") Etc.
ce qui doit normalement lancer excel quelque soit la version présente sur le poste où s'exécute le programme. Mais j'ai peur que cette petite galipette ne soit pas très stable, notamment puisque entre les version, les fonctions et leurs arguments diffèrent. De plus, le programme appelle tout de même l'assembly de la version 2010 donc j'ai peur du résultat.
Naturellement, je n'ai que Office 2010 pour faire mes tests et les bécannes préhistoriques sont dans d'autres locaux éloignés donc pas envisageable d'aller y faire des tests.
3 - Dans un élan d'idées farfelues, j'ai exploré la piste du "faire une automation excel sur un poste qui n'en est pas pourvu" et j'ai trouvé en farfouillant dans les propriété du projet (VBE 2010) que je pouvais choisir "Copie Locale" pour mes références COM
Citation:
Microsoft Office 14.0 Object Library
Microsoft Excel 14.0 Object Library
. Est-ce à dire que je peux par ce moyen "copier les assembly" directement dans les ressources du programme ? A ma connaissance, ce n'est pas possible, mais notre responsable informatitien m'a un jour parlé de "runtime" qui permettent d'utiliser un programme sans qu'il soit installé mais comme il a d'autre chats à fouéter et qu'il travaille sous Fox Pro, il n'a pas creusé la piste. Je suppose que c'est une reflexion à laquelle on est tous amenés en travaillant avec des automations d'applications de la suite Office, mais à ce jour, je n'ai toujours pas trouvé de réponse claire, nette, et définitive.
Ma problématique initiale étant de faire fonctionner mes programmes sur toutes les versions d'excel résulte évidemment de ma conviction (peut être éronnée) que la 3ème option relève du mythe.
En tout état de cause, je me tourne donc vers vous.
A vous lire !
Phoe
