Discussion :

[Golard]

Bonjour à tous,

Merci d'avance pour vos réponses. Je suis non seulement [Débutant] mais c'est aussi mon premier message dasn le forum ASP.net !

J'ai développé une application dont le résumé des fonctionnalités est le suivant:
- Interface simple avec quelques boutons pour lancer les fonctionnalités
- Lecture de données dans un classeur Excel (xlsx)
- Création et modification de documents Word (docx)

Actuellement, j'ai développé cette application en VBA (lancement à partir d'un classeur Excel xlsm).

Je désire faire évoluer cette application, notamment en consolidant une partie du code dans des dll.
J'ai pensé tout naturellement à développer une application Windows Form en VBnet (l'environnement auquel je suis familier).
Après quelques tests, ça fonctionne parfaitement, mais je me dis (peut-être à tort ?) que déployer une appli avec un setup.exe est un peu dépassé (?) et que le système de fenêtre windows standard n'est pas très adapté aux multiplateformes actuelles...

MA QUESTION: J'envisage donc de migrer mon application afin qu'elle puisse se charger dans le navigateur web du poste.

Après quelques recherches, il apparait que je dois choisir entre une application WPF ou une Web API qui si j'ai bien compris correspond à un développement ASP.net.
Par ailleurs, j'ai lu que le choix Web API était d'avantage tourné vers l'avenir ?

Concernant mes fonctionnalités (dans un premier temps), je souhaite travailler avec des fichiers Excel et Word en local sur le poste (ou en résau bien sur, mais pas sur un serveur distant).

Pouvez-vous me dire si:
* Vouloir travailler avec des fichiers word et excel en local en WPS ou APS.net est possible, ou juste une mauvaise idée ?
* Le choix d'un développement ASP.net pour mon application est-il préférable à celui d'un application WPF ?
* Pourrais-je conserver du code VB dans l'un ou l'autre de ces choix ?
* Si vous étiez à ma place, quel type de projet choisiriez-vous pour faire évoluer mon projet actuellement en vba ?

N'ayant jamais développé d'application dans le navigateur, je m'en remet à vos propositions.

[Momoth]

Bonjour,

* Vouloir travailler avec des fichiers word et excel en local en WPS ou APS.net est possible, ou juste une mauvaise idée ?
Je suppose que tu veux dire WPF et Asp.Net. Donc WPF, oui c'est une bonne idée, c'est bien adapté. Par contre Asp.Net est pas fait pour du local sur le poste client. L'application s'execute sur un serveur IIS, donc a moins d'uploader tous les fichiers word et excel sur le serveur tout ca, c'est pas tres pratique.

* Le choix d'un développement ASP.net pour mon application est-il préférable à celui d'un application WPF ?
Honnettement, ca dépend ton but. Si tu veux qu'un utilisateur puisse par exemple modifier un fichier, et qu'un autre utilisateur puisse modifier ce fichier là par la suite (partage de fichier tout ca). Oui c'est adapter, mais si tu n'as qu'un utilisateurs ou que chaque utilisateurs a ses propres fichiers sur son poste non, le WPF est plus intéressant.

* Pourrais-je conserver du code VB dans l'un ou l'autre de ces choix ?
Oui dans les deux cas, c'est du Dot.Net derrière, donc y'a pas de soucis.

* Si vous étiez à ma place, quel type de projet choisiriez-vous pour faire évoluer mon projet actuellement en vba ?
Personnellement, ca dépend du poste de l'utilisateur. Si tous tes utilisateurs sont en W7, je choisirais WPF ou Windows Form. Si c'est des postes en W8, je choisirais un projet Windows Store parce que j'aime bien.

Apres, c'est surtout mon avis, mais je suis pas fan des applications web quand une application en local suffirait largement. A voir selon tes besoins.

[Golard]

Merci Momoth pour ta réponse détaillée, j'y vois déjà un peu plus clair !

* Vouloir travailler avec des fichiers word et excel en local en WPS ou APS.net est possible, ou juste une mauvaise idée ?
Je suppose que tu veux dire WPF et Asp.Net. Donc WPF, oui c'est une bonne idée, c'est bien adapté. Par contre Asp.Net est pas fait pour du local sur le poste client. L'application s'execute sur un serveur IIS, donc a moins d'uploader tous les fichiers word et excel sur le serveur tout ca, c'est pas tres pratique.

Oui effectivement, je voulais dire WPF.
Dans la version actuelle de mon application, les fichiers word et excel sont sur un réseau d'entreprise.
Pour l'instant, il n'est pas question de les "delocaliser" sur un serveur IIS.
Donc le choix semble être WPF...

* Le choix d'un développement ASP.net pour mon application est-il préférable à celui d'un application WPF ?
Honnettement, ca dépend ton but. Si tu veux qu'un utilisateur puisse par exemple modifier un fichier, et qu'un autre utilisateur puisse modifier ce fichier là par la suite (partage de fichier tout ca). Oui c'est adapter, mais si tu n'as qu'un utilisateurs ou que chaque utilisateurs a ses propres fichiers sur son poste non, le WPF est plus intéressant.

Le fonctionnement de mon application est le suivant:
Les fichiers Word s'ouvre sur le poste local de l'utilisateur avec Microsoft Word installé en local.
Un fichier Word peut-être ouvert par plusieurs utilisateurs, mais pas en même temps.
Les fichiers Word ne sont pas "partagés", donc 2 utilisateurs ne peuvent pas ouvrir le même fichier en même temps

Remarque:
Dans certains cas, mon application ouvre des fichiers Word sur Sharepoint, mais je les gère comme s'ils étaient sur le réseau (le "site" sharepoint n'est finalement qu'un emplacement réseau particulier). Dans ce cas, les fichiers peuvent bien être partagés, mais le partage est géré par Sharepoint et pas par mon application.
Je ne pense pas que ce détail change quelquechose à ton raisonnement ?

* Pourrais-je conserver du code VB dans l'un ou l'autre de ces choix ?
Oui dans les deux cas, c'est du Dot.Net derrière, donc y'a pas de soucis.

Bonne nouvelle.
Je suppose que je vais donc pouvoir organiser une partie de mon code dans des dll ?
Peux-tu me confirmer le type de dll que je dois créer pour qu'elles restent compatibles si un jour j'évolue de WPF vers ASP.net ou Windows Store ?

* Si vous étiez à ma place, quel type de projet choisiriez-vous pour faire évoluer mon projet actuellement en vba ?
Personnellement, ca dépend du poste de l'utilisateur. Si tous tes utilisateurs sont en W7, je choisirais WPF ou Windows Form. Si c'est des postes en W8, je choisirais un projet Windows Store parce que j'aime bien.

Les utilisateurs sont sous W7.
Je connaissais pas l'existence des projets Windows Store... Je note que ce sera à étudier quand les utilisateurs passeront sous W10, mais ce n'est pas pour aujourd'hui !


Finalement, grâce à ton message, je vais m'orienter vers un projet WPF et commencer à étudier la structure de ce type de projet.
En lisant les précisions que j'ai apporté dans ce message, peux-tu me confirmer que cela reste le bon choix ?
Merci pour ton analyse !!!

[nachtigal]

Ce que j'ai noté :
1) Tu as un réseau où les utilisateurs accèdent à des fichiers commun même si c'est pas en même temps. Tu as même un SharePoint sur le réseau, ce qui veut dire que tu disposes déjà en interne d'un serveur IIS et donc ASP.NET...
Le fait que les utilisateurs se retrouvent avec des fichiers Word ou Excel qu'ils doivent partager à un moment ou un autre à travers le réseau est simplement dû à un manque de culture réseau et bases de données (sans vouloir t'offenser c'est juste une analyse de la situation présente).
Dès qu'il y a partage, il faut automatiquement t'orienter vers une fonctionnement réseau normal ; faire autrement c'est du bricolage. Il faut oser sauter le pas et adopter les architectures qui te mettront à l'abri pour les 10 prochaines années...
Télécharge donc une version gratuite de Visual Studio qui comporte quasiment tout ce qu'il te faut aujourd'hui pour te mettre dans le bain.
Pendant que tu y es, tu peux également télécharger une version de MS SQL Server gratuite qui comporte également tout ce qu'il te faut pour travailler en local d'abord puis éventuellement envoyer le tout sur le serveur central.
2) Conserver les script VB... Tu vas rire, mais selon ce que fait ton script, tu peux soit le réécrire plus vite et mieux en pure C# ou VB.NET, soit alors le compiler et utiliser directement la DLL obtenue...
3) Puisque nous y sommes, ASP.NET MVC vient avec des générateur de code intégré qui te "mâchent" le travail de base, tu obtiens un squelette fonctionnel de ton application sans avoir écrit une seule ligne de code, c'est dommage de repartir de zéro, réinventer la roue alors que des outils modernes existent déjà te laissant te concentrer au maximum sur la logique applicative et non sur le code...
5) Enfin, puisque JavaScript est à l'honneur, ne t'en prive pas !!
En résumé, orientes-toi sans hésiter vers une architecture réseau, et si tu restes sur du MS alors sans aucune hésitation tu télécharges la totale et tu te jettes à l'eau. Installe Webpi Web Plateforme Installer qui va lui se charger d'installer tout ce dont tu as besoin en résolvant les éventuellement dépendances, les libraires requises, etc...
Installe alors SQL SERVER EXPRESS, puis Visual Studio Express, etc...
Tu modélise ton application en base de données et tu laisses ASP.NET MVC faire le reste, et il le fait très bien tout seul !!
En espérant t'avoir apporter un peu d'eau au moulin et surtout en t'encourageant à faire le saut
Bonne journée !!

[Momoth]

Remarque:
Dans certains cas, mon application ouvre des fichiers Word sur Sharepoint, mais je les gère comme s'ils étaient sur le réseau (le "site" sharepoint n'est finalement qu'un emplacement réseau particulier). Dans ce cas, les fichiers peuvent bien être partagés, mais le partage est géré par Sharepoint et pas par mon application.
Je ne pense pas que ce détail change quelquechose à ton raisonnement ?

Non sharepoint devrait pas trop te gener normalement.

Bonne nouvelle.
Je suppose que je vais donc pouvoir organiser une partie de mon code dans des dll ?
Peux-tu me confirmer le type de dll que je dois créer pour qu'elles restent compatibles si un jour j'évolue de WPF vers ASP.net ou Windows Store ?

Un projet pour le code front de type Application WPF. Et tout ton code metier dans des projets de type Bibliothèque de classe.

Les utilisateurs sont sous W7.
Je connaissais pas l'existence des projets Windows Store... Je note que ce sera à étudier quand les utilisateurs passeront sous W10, mais ce n'est pas pour aujourd'hui !

Euh je me suis pas trop renseigner sur W10, faudra voir pour la solution quand tu prévoiras la migration des postes. Je crois avoir entendu dire que WPF ne serait pas de la partie dans W10. Mais je sûr de rien.

Finalement, grâce à ton message, je vais m'orienter vers un projet WPF et commencer à étudier la structure de ce type de projet.
En lisant les précisions que j'ai apporté dans ce message, peux-tu me confirmer que cela reste le bon choix ?
Merci pour ton analyse !!!

Le bon choix, je ne peux pas te le confirmer, mais c'est celui que je ferais.

[DotNetMatt]

Attention à ne pas aller trop vite en besogne ! WPF pourquoi pas mais tu vas garder sur les bras 2 points que tu as mentionné : déploiement via un Setup, et non multi-plateformes.

Pour moi ASP.NET pourrait tout à fait convenir. Il n'est pas obligatoire d'uploader les documents ailleurs, ou alors on peut le faire pour les traitements puis in fine sauvegarder le document où bon nous semble. On peut faire beaucoup de choses avec ASP.NET aujourd'hui, et l'un des gros avantages, c'est multi plateformes et il n'y a pas de déploiement à faire pour chaque utilisateur. On déploie une fois sur le serveur Web et c'est tout.

Autre point puisque tu utilises déjà SharePoint, tu pourrais même y intégrer directement tes fonctionnalités. Ce qui serait probablement plus simple pour tout le monde (développeurs et utilisateurs).

[Golard]

Attention à ne pas aller trop vite en besogne ! WPF pourquoi pas mais tu vas garder sur les bras 2 points que tu as mentionné : déploiement via un Setup, et non multi-plateformes.

Bonjour DotNetMatt et merci pour l'info. ça confirme ce dont je suis en train de me rendre compte.
Je suis en train de migrer un petit outil (à l'origine en VBA excel) en WPF pour me faire une idée avant de migrer ma grosse application.
J'ai donc découvert le xaml qui offre de grosses possibilités en terme d'interface.
J'ai aussi lus dans des discussions les capacités de databinding mais je n'ai pas testé.
J'arrive bientôt au bout de la migration de mon petit outil et je vais donc prochainement découvrir le setup WPF...

Pour moi ASP.NET pourrait tout à fait convenir. Il n'est pas obligatoire d'uploader les documents ailleurs, ou alors on peut le faire pour les traitements puis in fine sauvegarder le document où bon nous semble. On peut faire beaucoup de choses avec ASP.NET aujourd'hui, et l'un des gros avantages, c'est multi plateformes et il n'y a pas de déploiement à faire pour chaque utilisateur. On déploie une fois sur le serveur Web et c'est tout.

Très intéressant.
Une fois mon test terminé sur WPF, je compte développer une petite appli test à partir d'un article que j'ai trouvé sur le net, afin de mieux me rendre compte ce qu'est une appli asp.net.
Ce qui m'inquiète le plus, c'est cette histoire de serveur. Ou se trouve-t'il ? J'ai téléchargé Microsoft Community 2013 (version gratuite)... Vais-je devoir utiliser mon compte Visual Studio Online pour héberger mon appli ? Est-ce possible d'utiliser un autre serveur ?
Voilà pourquoi je suis inquiet: Mon application est utilisée pour certaines fonctionnalités à des moments "critiques" pour l'entreprise. L'utilisateur doit donc être assuré à 100% que l'application fonctionnera... N'y-a-t'il pas le risque que le serveur ne soit pas dispo à l'instant fatidique ? Peux-ton avoir une sorte de sauvegarde locale de l'appli pour ce cas précis ?
Autre inquiétude, financière et législative cette fois-ci: Ai-je le droit d'installer mon appli asp.net chez un client et d'utiliser mon compte gratuit Visual Studio Online ? Puis-je être sur que ce compte est fiable et viable dans le temps ? Combien d'utilisateurs (ou de postes?) auront le droit d'accéder à mon appli ?

Autre point puisque tu utilises déjà SharePoint, tu pourrais même y intégrer directement tes fonctionnalités. Ce qui serait probablement plus simple pour tout le monde (développeurs et utilisateurs).

Pour info, qu'entends-tu par "intégrer directement tes fonctionnalités" ? Quel serait alors le language et le mode de déploiement ?
Concernant mon projet (voir résumé en vert dans mon premier message), les fichiers word se trouvent bien sous Sharepoint pour certains utilisateurs, mais pour d'autres pas du tout. Mon application n'est donc pas "liée" à sharepoint... Je dois proposer les mêmes fonctionnalités que les fichiers word soient sous sharepoint ou pas. Voilà pourquoi je n'envisage pas aujourd'hui d'intégrer mon appli à sharepoint.


Je me rends compte que j'ai posé beaucoup de questions ... Alors MERCI d'avance pour le temps que vous me consacrez !!!

[DotNetMatt]

Ce qui m'inquiète le plus, c'est cette histoire de serveur. Ou se trouve-t'il ? J'ai téléchargé Microsoft Community 2013 (version gratuite)... Vais-je devoir utiliser mon compte Visual Studio Online pour héberger mon appli ? Est-ce possible d'utiliser un autre serveur ?

Il ne faut pas t'inquiéter. Le serveur c'est juste un ordinateur (physique ou une machine virtuelle) connecté au réseau (soit en interne sur le LAN, soit via Internet dans le Cloud). Les clients (les utilisateurs au travers de leur navigateur Web) vont envoyer des requêtes vers ce serveur, et il va leur répondre. Par exemple une requête peut être "Envoie-moi les données de l'utilisateur en cours". Le serveur va l'interpréter puis renvoyer ces données. Pour être plus précis, c'est un logiciel qui va s'en charger et il s'appelle IIS (Internet Information Services). C'est lui qui va réceptionner la requête, faire tourner ton code en conséquence puis renvoyer les données. A noter IIS est disponible sur certaines éditions de Windows 7/8 et sur toutes les éditions récentes de Windows Server.

Avec Visual Studio Online tu n'auras pas de serveur. Ce compte te permet juste d'utiliser Visual Studio, et éventuellement de pouvoir utiliser Team Foundation Services, le gestionnaire de sources de Microsoft en mode Cloud. Si tu veux avoir un serveur, tu peux lier ton compte VS Online à ton compte Azure, et ainsi pouvoir déployer ton code sur ton serveur dans le cloud... Mais avant de partir dans le Cloud ou pas il faut étudier la question.

Voilà pourquoi je suis inquiet: Mon application est utilisée pour certaines fonctionnalités à des moments "critiques" pour l'entreprise. L'utilisateur doit donc être assuré à 100% que l'application fonctionnera... N'y-a-t'il pas le risque que le serveur ne soit pas dispo à l'instant fatidique ? Peux-ton avoir une sorte de sauvegarde locale de l'appli pour ce cas précis ?

Il est très facile de prévoir ces scénarios, il suffit d'avoir N serveurs qui tournent en parallèle et un petit module qui va dispatcher les requêtes sur les serveurs qui tournent. Ainsi quand l'un des serveurs tombe, un autre prend le relais et l'utilisateur ne s'en rend pas compte. En général 2 serveurs suffisent (un actif et un passif - quand l'actif tombe, le passif prend le relais). Pour des scénarios ultra-critiques on peut envisager 3 serveurs voire plus mais il faut en avoir réellement besoin.

Pour les sauvegardes, il est possible d'en faire mais il faut voir si c'est réellement pertinent...

Autre inquiétude, financière et législative cette fois-ci: Ai-je le droit d'installer mon appli asp.net chez un client et d'utiliser mon compte gratuit Visual Studio Online ? Puis-je être sur que ce compte est fiable et viable dans le temps ? Combien d'utilisateurs (ou de postes?) auront le droit d'accéder à mon appli ?

Ton compte Visual Studio Online n'a rien à voir avec le reste. Donc pas de souci de ce côté là, tu es libre de développer et de commercialiser en l'utilisant. Ce qu'il faut prévoir c'est le coût de mise en oeuvre pour le client, en fonction du mode d'hébergement (cloud ou on-premises (= chez le client)).

Si le choix se porte sur on-premises, il faut prévoir le coût d'achat du/des serveurs et la licence Windows.
Si le choix se porte sur le cloud, il y a plus de composants qui rentrent en jeu, mais encore une fois il faut voir si ca en vaut la peine. A noter que ce n'est pas forcément plus cher.

Pour info, qu'entends-tu par "intégrer directement tes fonctionnalités" ?

SharePoint est un gros logiciel qui dispose de 5 briques différentes (gestion documentaire, business intelligence, site Web, etc.). Chacune des briques peut être étendue par du code maison. Donc on peut imaginer beaucoup de scénarios différents ! Par exemple si tes fichiers sont stockés dans SHarePoint via la brique de gestion documentaire, alors il va être possible de mettre à disposition des utilisateurs un bouton dans le ruban pour qu'ils puissent lancer directement un traitement sur le serveur. Ou bien on peut aussi imaginer mettre un bouton qui les amène sur une UI spécifique, depuis laquelle ils pourront lancer tel ou tel traitement.

Quel serait alors le language et le mode de déploiement ?

Le language ca reste du .NET (VB.NET, C#, ou autre...), et ca peut prendre différentes formes selon la visée finale. S'il s'agit de code purement serveur, alors une DLL sera suffisante, sinon il faudra regrouper les fonctionnalités principales dans une DLL puis créer quelques pages ASPX/ASCX qui les utiliseront. Ensuite pour le déploiement, avec SharePoint on parle de Solution, en gros c'est un peu comme un fichier ZIP que tu gères dans Visual Studio, et quand tu déploies, ce fichier est uploadé sur le serveur puis décompressé et les fichiers sont automatiquement rangés au bon endroit (c'est juste pour te donner une image, ce n'est pas exactement comme ca dans la réalité).

Concernant mon projet (voir résumé en vert dans mon premier message), les fichiers word se trouvent bien sous Sharepoint pour certains utilisateurs, mais pour d'autres pas du tout. Mon application n'est donc pas "liée" à sharepoint... Je dois proposer les mêmes fonctionnalités que les fichiers word soient sous sharepoint ou pas. Voilà pourquoi je n'envisage pas aujourd'hui d'intégrer mon appli à sharepoint.

A voir, n'est-il pas possible de les regrouper tous sous Sharepoint ? Si non, et si cela est valide pour ton besoin, il est tout à fait envisageable de n'utiliser SharePoint que pour réaliser les transformations, les fichiers restants stockés là où ils sont... A toi de réfléchir aux différents scénarios, comme on ne connait pas ton projet sous tous les angles, tu es le seul à pouvoir trouver des solutions.