Application DotNet gérant des fichiers Excel - qu'est ce qui est le mieux ?

Bonjour,
Sans rentrer dans les détails, Je dois répondre à un appel d'offre interne dans ma société sur une solution d'outil qui gère essentiellement des fichiers Excel en entrée/sortie.
En gros l'application devra permettre à des utilisateurs de synchroniser des fichiers Excel, de modifier des fichiers Excel, d'effectuer différents contrôles (champs obligatoires, cohérences de données, impact liés aux modifications des fichiers Xls)...

Le client ne voulant pas de macro VBA (trop fragile d'après lui), je pense à une application écrite en C# ds le Framework DotNet.
(Nous avons dans un premier temps mis de côté une solution avec base de données, car les utilisateurs travaillent essentiellement en Excel).

J'ai cependant quelques doutes, voici donc mes questions:
- Les utilisateurs devront-ils tous installer un Framework client DotNet sur leur Poste ?
- Un .EXE Dotnet sera t il moins sensible aux futurs changements de versions Excel ? (vu que l'on doit ajouter une référence Excel dans le projet...?)
- Le C# sera t il aussi intéressant que le VB.NET pour gérer des fichiers Excel ? d'ailleurs qu'est ce qui est le mieux , le plus robuste ? VB ou C# ?
- Aurai-je la même souplesse d'utilisation en C# qu'en Macro VBA
- vitesse d'exécution,
- recherche, lecture, écriture ds Excel
- gestion des évènements du WorkBook, des WorkSheets...

Voilà! si une bonne âme peut me répondre, je la remercie du fond du cœur, car j'ai bien trouvé des informations sur Internet, mais c'est trop dense, il me faut une réponse de haut niveau par quelqu'un qui a l'habitude de développer des application utilisant Office. (A savoir que de mon Côté, je code souvent en VBA, et j'ai codé en C# DotNet il y qqs années).
Un grand merci d'avance.
Cordialement
Claire

Citation:

---

Envoyé par clairette95

Les utilisateurs devront-ils tous installer un Framework client DotNet sur leur Poste ?

---

un exe fait en .net (c# ou vb.net) nécessite que le framework utilisé lors du développement soit installé
dans vs on peut choisir quel framework on cible, en ciblant le 4 tu peux cibler de windows xp sp3 à supérieur
avec des framework plus récents les windows cibles diminuent
après chaque version (récente) de windows contient une version du framework par défaut

Citation:

---

Envoyé par clairette95

Un .EXE Dotnet sera t il moins sensible aux futurs changements de versions Excel ? (vu que l'on doit ajouter une référence Excel dans le projet...?)

---

ca dépend des choix techniques, et des versions de fichiers
les xls et xlsx ne sont pas encodés de la même manière
à l'époque on utilisait une référence vers l'interop d'excel, ce qui pouvait poser problème en cas de changement de version, en plus c'est lent et pas pratique
par contre il y a d'autres moyens de lire et écrire dans un fichier excel (explicité plus bas)

Citation:

---

Envoyé par clairette95

Le C# sera t il aussi intéressant que le VB.NET pour gérer des fichiers Excel ? d'ailleurs qu'est ce qui est le mieux , le plus robuste ? VB ou C# ?

---

pas vraiment de différence hormis la syntaxe entre les 2, donc c'est toi qui choisit
les 2 sont compilés sous la même forme au final, et on peut traduire de l'un à l'autre
donc le choix se fait surtout sur

Code:

---

1 2 3 4

If A = 5 Then ' DoSomething End If

---

Code:

---

1 2 3 4 5

if (A == 5) { // DoSomething }

---

en c# tout est entouré d'accolades au lieu des end if/next/end while/end sub/end class ... perso je trouve ça moins lisible mais chacun ses gouts
et c# est sensible à la casse aussi

Citation:

---

Envoyé par clairette95

Aurai-je la même souplesse d'utilisation en C# qu'en Macro VBA

---

voir plus, avec la POO de .net tu pourras faire du code moins fouillis

Citation:

---

Envoyé par clairette95

vitesse d'exécution,
recherche, lecture, écriture ds Excel

---

on en revient au choix technique de comment accéder au fichier excel

comme dit précédemment l'interop c'est lent et parfois problématique ; ca s'utilise un peu comme du vba (.cells, .range ...)
on peut tout faire avec

pour les fichiers xls on peut y accéder comme une base de données avec Jet (provider de microsoft), donc on fait des select, des where, des insert/update/delete ...
pour les fichiers xlsx jet ne fonctionne pas, mais il y a son remplacant, ACE OLE DB
pour jet et oledb on ne peut que lire et écrire les données, on ne peut pas gérer de mise en page
et il faut que les onglets que tu veux lire aient des entêtes de colonnes
après les fichiers peuvent avoir un peu de mise en page faite dans excel avant ca ne pose pas de problème
l'avantage c'est que c'est très simple à comprendre, et très rapide d'exécution
SELECT colonne1, [colonne 2] FROM [tel sheet$]

pour les fichiers xlsx microsoft a aussi fournit une dll tierce .net (donc à copier à côté de l'exe simplement) qui permet de manipuler les fichiers depuis excel 2007 (pas xls je pense), et à priori le format n'a pas changé depuis, cette dll c'est open xml sdk
l'inconvénient de cette dll c'est qu'elle est plutot compliqué à comprendre bien qu'elle puisse tout faire (y compris de la mise en forme, du merge de cell ...)
par contre il y a des dll qui utilise cette dll mais en simplifie grandement l'utilisation, comme closedxml (et il y en a d'autres, epplus doit en etre une aussi)

Citation:

---

Envoyé par clairette95

gestion des évènements du WorkBook, des WorkSheets...

---

open xml sdk permet d'accéder à tout, comme l'interop
avec jet/aceoledb tu peux aussi avoir la liste des sheets, la liste des colonnes etc... (pour ca c'est getschema et getschematable, il y a des exemples sur le net)
par contre évènements je vois pas trop ce que tu veux dire par là

pour résumé je déconseille l'interop (référence vers excel object library)
ace oledb c'est un setup à part à installer sur les postes devant accéder aux fichiers (trouvable chez microsoft)
openxml et les dérivés ne demandent rien de plus que le framework et permet autre chose que du CRUD simple

Merci beaucoup pour cette réponse rapide et précise, je m'aperçois que la techno avance vite, va falloir que je me reforme chez MS !:)

Pour les évènements, je précise le contexte de ma question:
en macro VBA, on sait si une feuille ou une cellule a changé, j'aurai donc besoin de faire pareil en C# (en utilisant des délégués peut être ?) ;
exemple: savoir si une ligne a été ajoutée ou supprimée pour activer une traitement particulier. Donc récupération des évènements Excel des feuilles.
Est-ce aussi simple en C# ?

Merci

ok

en vba le code est dans excel donc il fonctionne quand le fichier est ouvert
moi je t'ai donné les moyens de lire un fichier excel fermé (donc pas d'event)
je suis parti sur la mauvaise piste car faire une appli dans excel à la place d'une vraie application ca se rarifie de nos jours ^^

sinon le remplacant de vba en .net c'est vsto, qui lui travaille sur des fichiers ouverts vu que le code est stocké dans le fichier
à vérifier que c'est pas deprecated
et l'argument de fragilité s'il tient pour vba il sera le même sur vsto je pense

Merci pour ta réponse.

En effet mon application C# ouvrirait des fichiers Excel dans 3 buts:
1/ Lecture d'1 Fichier_1 par l'application (catalogue de matériel complet en lecture seule) , pour voir les évolutions
2/ Ecriture dans un Fichier_2 par l'application (catalogue matériel multi projets modifiable) , suite aux évolutions détectées dans le Fichier 1 (synchro)
3/ Ecriture dans un Fichier_3 par un utilisateur (liste de matériel d'un projet modifiable) à partir des données du Fichier_2.
--> et détection des actions utilisateurs (évènements WorkSheet) pour que l'appli effectue certains traitements de contrôle.

Donc une architecture un peu complexe....
J'ai cru voir sur Internet qu'en C# il existait des classes dédiées aux évènements Excel (WorkSheet_Change), mais je voulais être sûre que cette solution était réalisable....

En tous cas j'ai beaucoup appris avec tes réponses,
pour le point 3/, je vais continuer de fouiller.

Merci Encore

Bonjour,

Je pense cerner à peu près la problématique, mais je pense que la solution à base d'interop Excel est... bancale. En effet, tu vas construire une application qui va ouvrir excel, poser des événements sur les actions qui vont bien pour faire des contrôles, lire d'autres fichiers excel, etc...

Mais que va-t-il se passer si un utilisateur ouvre directement le fichier sans passer par l'application ? Les contrôles ne pourront pas être fait et tu vas avoir des données potentiellement foireuses. Et après, il faut également prévoir une procédure pour rattraper le coup et corriger les données invalides.

Citation:

---

Envoyé par clairette95

Le client ne voulant pas de macro VBA (trop fragile d'après lui), je pense à une application écrite en C# ds le Framework DotNet.

---

Ce n'est pas au client d'éliminer un choix technologique sur un avis qui me semble des plus subjectifs. C'est contre-productif et potentiellement dangereux. Ou alors il faudrait connaître les véritables raisons qui se cachent derrières.

C'est dommage que les utilisateurs ne veulent pas travailler avec autre chose qu'Excel (la résistance aux changements) car une solution avec une base de données me semble adaptée à l'utilisation décrite. En tout cas, la solution qui me semble la plus viable reste l'utilisation de macro.

Je te conseille la bibliothèque payante SpreadSheetGear :

http://www.spreadsheetgear.com/

Je tiens à dire que je n'ai aucun lien commercial avec cette société. J'ai simplement utilisé cette bibliothèque à de nombreuses reprises et constaté son efficacité.

Merci François pour ta réponse,

A vrai dire quand j'ai lu le CDC, j'ai pensé ds un premier temps à une base de données avec des interfaces Web et exports Excel,
mais comme les données d'entrées /sorties sont essentiellement en Excel , je me suis dit qu'on risquait de développer une BDD uniquement pour stocker des donner, et passer notre temps à les exporter et les réimporter, car les utilisateurs sont habitués à Excel (des formulaires Web étant moins souples d'utilisation).

Par conséquent, j'ai proposé une simple application en VBA, solution moins couteuse, mai mon client interne pense que le VBA est trop sensible aux changements de versions.

Il y a donc en effet un risque avec une application externe , c'est de passer son temps à récupérer les évènements liés aux actions des utilisateurs sur les fichiers ouverts par l'application, et d'être obligé de mettre un mécanisme qui force l'ouverture des fichiers uniquement par l'application.

Je vais continuer d'investiguer sur cette solution (maquette) et si cela s'avère trop compliqué, on optera peut être pour une solution Intranet.

Merci encore pour ta réponse
Bonne journée

Merci Dzediar,

J'ai été voir sur Internet, j'avoue que j'ai du mal à comprendre ce que propose cette bibliothèque :roll:

En résumé, elle propose quoi ? sait tu ou je pourrais trouver une démo ? j'en ai trouvé une qui montre des fichiers Excel en mode "formulaire" avec des rapports et graphes, mais je ne saisis pas ses atouts principaux ?

Merci

Ils ont re-développé excel. Tout est dans une dll unique et permet d'ouvrir et de manipuler des fichiers excel en mémoire ou bien d'afficher des classeurs avec WPF, Silverlight, ...

Tout se fait par le biais de classes dot net, pas besoin qu'excel soit installé sur la machine.

L'ensemble est plus performant que excel pour les calculs.

La licence pour un poste de dev coûte 999 $ et permet de distribuer la dll à une infinité de clients utilisateurs.

Ce serait possible de s'appeler pour 2 ou 3 questions sur SpreadSheetGear ?

Non.

Tu as une version d'évaluation de 30 jours disponible ici :

https://www.spreadsheetgear.com/downloads/register.aspx

OK je vais regarder,
c'est bien dommage que SpreadSheet n'ait pas une Démo (différent d'une version d'évaluation) avec toutes les fonctionnalités et des exemples concrets,

Merci et bon WE