Créer un fichier Excel [C#] - C#/.NET managed - Programmation
Marsh Posté le 28-04-2006 à 10:36:42
Tu est en .NET? Sinon j'ai trouve un composant appele CarolsAg qui est pas mal du tout!
Marsh Posté le 28-04-2006 à 11:52:27
Je trouve rien sur le net à propos de CarolsAg
La solution du VBS :
Code :
|
Pkoi on peut pas faire simplement aussi en C# ?
Je sens que je vais m'amuser encore... Pis à débuger, ça va encore être la misère tiens...
Marsh Posté le 28-04-2006 à 12:29:23
Bon ben...
Code :
|
Avec le fichier VBS qui recherche les donnés dans un fichier XML qui va bien... Mon dieu que c'est crade Mais au moins ça marchera quelque soit la version d'Excel...
Marsh Posté le 28-04-2006 à 12:55:54
pour Carlos AG il s'agit de produire des fichiers EXCEL au format XML. Ces fichiers ne sont lisibles qu'avec EXCEL 2003 puisque ce format est apparu avec Microsoft Office 2003.
L'avantage d'une telle solution de reporting est qu'il ne fait pas avoir microsoft Excel sur la machine pour produire les XML compréhensible par EXCEL.
CarlosAg à produit une lib permettant de générer facilement un fichier au format XML.
plus d'infos ici sur ce format:
http://www.labo-dotnet.com/Article [...] /1547.aspx
Marsh Posté le 28-04-2006 à 13:39:36
on peut pas dire que tu ai cherché beaucoup alors pcq le premier lien sur google c'est celui la!
http://www.carlosag.net/Tools/Exce [...] fault.aspx
Marsh Posté le 28-04-2006 à 13:44:29
en fait ton fichier peut avoir l'extention xls avec ca aussi mais il sera effectivement en xml et donc lisible sous Excel 2003
Marsh Posté le 28-04-2006 à 15:14:30
Hmmm, Excel sous .NET ça pose pas de problème, si ?
Code :
|
Ca reste l'appel aux objets classiques en C.
Excel.Application, puis le WorkBook, puis les Worksheets, ...
Marsh Posté le 28-04-2006 à 15:29:56
le problème avec ole automation c'est que si ça plante, c'est un plantage massif... alors qu'avec la lib, c'est plus performant et ça ne plante pas puisque c'est que de la construction d'xml
Marsh Posté le 28-04-2006 à 15:42:35
moi23372 a écrit : pour Carlos AG il s'agit de produire des fichiers EXCEL au format XML. Ces fichiers ne sont lisibles qu'avec EXCEL 2003 puisque ce format est apparu avec Microsoft Office 2003. |
ouais, ok, donc ça m'intéresse pas
je sais écrire ces fichiers à la main, donc passer par un objet ne me sert à rien. et surtout, faut que Excel 97 puisse les relire...
Marsh Posté le 28-04-2006 à 15:44:35
Xas a écrit : Hmmm, Excel sous .NET ça pose pas de problème, si ?
|
ouais, sauf que "Excel.Application", pas moyen de trouver la référence à mettre. J'ai essayé les libs .NET (Office.Tools) et les objets COM (Excel 5.0 et Excel 11.0 -me demandez pas pkoi il y a des bouts de Excel 5.0 sur mon 2003 Server -)
Du coup, je ne peux rien faire. En plus, il me gueule dessus parcequ'il manque une référence "Microsoft.Office.Interop", sauf que je n'ai pas cette référence... Don't know why.
Et sinon, ça revient au même que mon VBS, sauf qu'avec "CreateObject", l'intérêt, c'est que je ne suis pas les poings liés avec la version référencée dans mon code : il prends la version de l'objet qui se trouve sur le PC de l'utilisateur. Ca m'évite de déployer 25 versions différentes de mon EXE (et d'installer 25 versions différentes d'Office sur mon PC...)
Marsh Posté le 28-04-2006 à 15:45:30
moi23372 a écrit : le problème avec ole automation c'est que si ça plante, c'est un plantage massif... alors qu'avec la lib, c'est plus performant et ça ne plante pas puisque c'est que de la construction d'xml |
Oui, mais relis mon premier post : XML = interdit. Je suis le seul dans toute la boîte à avoir Office 2003.
Sinon, j'aurais même pas posé la question : j'aurai utilisé le format XML d'entrée de jeu, c'est un vrai bonheur à utiliser, d'autant qu'on peut y inclure des macro autrement que sous forme de *.mso liés au fichier (on fout direct le code de la macro dans une balise spécifique et zou)
Marsh Posté le 28-04-2006 à 16:03:36
C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Excel\11.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\office.dll
J'ai que ça dans mes références et ça fonctionne...
Marsh Posté le 28-04-2006 à 16:04:00
ah excuse moi... j'ai lu en diagonale. Dans ce cas la il te reste ole automation. Pas trop le choix...
Sinon une autre solution consisterait tout de même à créer le fichier EXCEL en xml et de reconvertir ensuite avec XSL-FO vers un fichier Excel Classique... Mais sincèrement je crois pas que ça changerait bcp que de faire directement tout en ole automation.
Marsh Posté le 28-04-2006 à 16:05:10
moi23372 a écrit : le problème avec ole automation c'est que si ça plante, c'est un plantage massif... alors qu'avec la lib, c'est plus performant et ça ne plante pas puisque c'est que de la construction d'xml |
Suffit de faire une petite classe qui gère les E/S avec Excel.
Un petit try/catch quand on accède aux données et quand ça plante, ben on est toujours sain et sauf coté référence.
Marsh Posté le 28-04-2006 à 16:06:28
Xas a écrit : C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Excel\11.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll |
A priori, il me manque le premier. Je ne sais pas pkoi. Quand je fais "add reference", il n'est pas présent.
Marsh Posté le 28-04-2006 à 16:10:42
moi23372 a écrit : ah excuse moi... j'ai lu en diagonale. Dans ce cas la il te reste ole automation. Pas trop le choix... |
Ca va surtout être la grosse prise de tête
Avec OLE, ça devrait aller.
Je récupère mon DS. J'en fait un "WriteXml", je passe en paramètre à mon VBS le fichier généré.
Je le parse avec MSXML dans le VBS, et je construis dynamiquement mon document Excel via une instance d'Excel ouverte.
Quand j'ai fini, j'affiche la fenêtre et je rends la main au programme.
Comme ça le gus choisi d'enregistrer ou non le fichier, et l'appli peut continuer à tourner pendant ce temps. C'est à la limite mieux qu'avec une lib, parceque Excel est directement ouvert avec le fichier comme ça
Couche de décodage du flux XML à part, j'ai testé et ça marche. Je termine le reste de l'appli, et après je passe à ça. Je vais plus être emmerdé par l'absence d'IDE pour VBS (pratique pour retrouver le nom des méthodes d'un objet créé avec "CreateObject" ) qu'autrechose, pour le reste ça va marcher comme une bête acro Excel (d'ailleurs, je crois que je vais commencer par le faire sous forme de Macro avant d'en faire un VBS).
Marsh Posté le 28-04-2006 à 16:12:02
Xas a écrit : Suffit de faire une petite classe qui gère les E/S avec Excel. |
Borf, un bon gros "On Error Resume Next" dans mon VBS et c'est bon
En plus, l'intérêt c'est que le VBS sera appelé par un Shell.Run() donc même s'il plante, ça foutra pas en l'air mon appli, qui tourne dans un processus totalement séparé
Marsh Posté le 10-05-2006 à 11:35:33
Bon, pour ceux que ça intéresse, je suis donc finalement arrivé à la phase de développement où je pouvais plus faire sans cette fonctionnalité
Du coup j'ai torché ça en 1 heure, ça marche pour moi. C'est à complèter, mais ça pourrais aider à démarrer une personne bloquée comme moi.
Code :
|
Marsh Posté le 10-05-2006 à 12:13:11
sinon :
ftp://ftp2.developpez.be/developp [...] ficeCs.pdf
c'est un pdf qui explique comment generer des docs office au sens large
Marsh Posté le 10-05-2006 à 14:35:05
Perso, j'utilise la librairie Koogra sur sourceforge, totalement independante d'excel (aucunement besoin d'avoir office sur la machine). Par contre, faut se faire la grille à la mano
Marsh Posté le 10-05-2006 à 14:54:04
Merci pour le lien
Par contre, même si c'est crade, je conserve ma version : ton exemple repose sur les COM "de base" c'est à dire que je dois lier la DLL à ma version d'Excel.
Résultat, si je veux que l'appli soit compatible avec plusieurs versions d'Office, je dois installer chaque version d'Excel sur mon poste, puis compiler une version de mon programme pour chaque version d'Excel.
Je préfère donc utiliser mon bignou à deux balles, qui :
-> Instancie depuis C# un environnement de commande, quelle que soit la version de Windows
-> Lance Excel et joue dedans, quelle que soit la version d'Office
Bon, après, je suis d'accord, ça reste un bon gros script de grand-mère mais bon, on peut pas tout avoir...
Marsh Posté le 10-05-2006 à 15:00:03
Citation : |
Si tu regardes la base des registres, tu verras que [HKEY_CLASSES_ROOT\] Excel.Application [\CurVer] pointe vers la version qui est installé sur l'ordinateur
Donc no soucay pour les versions suivantes.
Marsh Posté le 10-05-2006 à 15:22:30
Ben oui justement
Ce qui permet de distribuer le même script quelle que soit la version installée.
Le programme est capable de retrouver la DLL un peut comme l'association des fichiers : on installe un nouvel outil qui se déclare comme étant le destinataire de cet appel et hop ! pas besoin de changer les liaisons dans le programme
Marsh Posté le 10-08-2006 à 09:54:33
Arjuna a écrit : Moi j'ai la 2003 (11), sauf qu'il me manque les "PIA" d'Excel. Et impossible de trouver où les télécharger (y'a un lien dans la MSDN, mais ça tombe sur une liste de dwl qui n'ont rien à voir) Vous avez une idée ? |
http://support.microsoft.com/defau [...] r%3B897646
Tu pouvais les créer toi aussi à partir des fichiers .tlb correspondants et l'outils TlbImp fourni avec Microsoft Visual Studio .NET..
Marsh Posté le 28-04-2006 à 10:35:22
Salut,
J'arrive pas à trouver un moyen pour créer un document Excel à partir d'une application écrite en C#.
J'ai toujours la solution du csv, ou du fichier html renommé en xls, mais je préfèrerais faire un truc simplement.
Sauf que j'ai plusieurs soucis :
- Je ne trouve de la doc que pour faire de l'automation avec Office 10 ou 11 (il y a des offices 97 et 2000 -Office 7 & 8- encore là où l'appli va être déloyée)
- Moi j'ai la 2003 (11), sauf qu'il me manque les "PIA" d'Excel. Et impossible de trouver où les télécharger (y'a un lien dans la MSDN, mais ça tombe sur une liste de dwl qui n'ont rien à voir)
Vous avez une idée ?
Reste la solution de déployer la solution avec un VBS, qui récupère les données d'un fichier XML, et qui bidouille dans Excel comme un grand -ça y'a pas de problème avec WSH- mais ça me lourde les bidouillages, après je comprends plus rien à ce que j'ai fait