Discussion :

[phoenellion]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

Dim XlApp As Excel.Application

mais par la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Dim XlApp As Object

et continuer ensuite le code de manière classique

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[Pol63]

http://msdn.microsoft.com/fr-fr/libr...=vs.80%29.aspx
http://www.microsoft.com/en-us/downl...s.aspx?id=3508

[phoenellion]

Merci pour ces infos. Instructif, quoiqu'un peu déroutant.

Arrêtez moi si je me trompe, mais a priori, si lors de l'installation de mon programme, j'ajoute le .net framework et les PIA office 2010, mon programme sera à même de fonctionner sans avoir à installer office ?

Et moi qui voulait faire une application "légère"...

[Pol63]

non, il faut office à priori, par contre si j'ai bien compris en ajoutant les bonnes pia en référence et au déploiement ca permet que le code fonctionne avec toutes les versions d'excel installées ...

[Sankasssss]

non, il faut office à priori

Je confirme.

par contre si j'ai bien compris en ajoutant les bonnes pia en référence et au déploiement ca permet que le code fonctionne avec toutes les versions d'excel installées ...

Par contre si cela est vrais, je me complique actuellement la vie car moi je prend les DLL d'office 2003 pour mes développements ce qui m'assure que ça fonctionne même sur des versions plus récente. C'est ce que je dis de faire à tout le monde pour l'automation, comme dans ce poste : http://www.developpez.net/forums/d88...-incompatible/
Y aurait-il mieux?

P.S. : Il existe mieux que l'automation, il existe des librairies qui écrivent directement des fichier Excel au format office open xml mais malheureusement je ne serais vous guider vers une solution car c'est toujours en test chez une de mes collègues. Piste à explorer et qui parait prometteuse si j'en crois ma collègue pour ces raisons : Rapidité (Plus besoin d'attendre l'ouverture d'office (20sec de gagnées) + export de 10000 lignes en 1 seconde. Et plus besoin d'intégrer les DLL ofiice...

[Pol63]

Par contre si cela est vrais, je me complique actuellement la vie car moi je prend les DLL d'office 2003 pour mes développements ce qui m'assure que ça fonctionne même sur des versions plus récente

si ca marche avec les dll de 2003 sur les versions plus récentes ca peut suffire
concernant les pia je ne suis pas expert en manipulation office et j'ai cru comprendre une réponse d'un intervenant disant que ca permettait de s'affranchir de la version installée, ca reste à tester donc (et ca se teste facilement ...)



après si on peut se passer de dll c'est toujours mieux, les fichiers docx et xlsx pouvant être lu sur 2003 via un addon
pour excel il y a aussi OleDb qui permet de manipuler les fichiers sans avoir les dll, et avec de bonnes performances aussi, par contre ca ne permet pas la mise en page
on peut alors faire create table pour créer un sheet, insert into, delete etc...