Autant il n’y a pas de déploiement .net en client léger, autant j’ai du mal à comprendre le déploiement des client lourds.
Il faut obligatoirement que l’ordinateur cible ait le framework de 50 Mo ???
Il n’y a pas un moyen comme dans Delphi (et les autres langages compilés) de linker les librairies à l’éxécutable ?
On retombe donc dans les mêmes problèmes que le déploiement des applications, faites avec certains environnement de développement, avec douze mille DLL.
Autant l’architecture n-tiers de .net me séduit beaucoup, autant l’architecture client lourd me fait peur voire me fait fuir. Je prefère alors rester dans ce cas avec Delphi & co.
Je sens venir une réponse style “Dans la prochaine version de windows .net sera de base” mais la migration du parc existant ne se fera pas en un jour comme le montre le parc actuel. Donc à part le cas d’un gros parc homogène dans une entreprise, c’est pas top pour le déploiement dans les autres cas.
PS: Je n’ai aucune expérience en .net, je me renseigne. J’ai installé le framework, le SDK, CsharpDevelop (et webmatrix qui ne fait pas partie de ma question, cette dernière étant sur les clients lourds) mais pas Visual Studio. Je développe en base de données je ne m’interesse donc pas aux langages bas niveau comme le C.
Ce message a été édité par phili_b le 04/12/2003 à 21h28 Ce message a été édité par phili_b le 04/12/2003
c’est vrai, dans un sens tu n’as pas tort. mais alors, que faire ?
pour moi, ms a eu le courage de remettre les choses à plat pour repartir sur des bases saines. mais il faut le payer.
sinon, qu’est-ce qu’on fait ? on devrait continuer à bricoler des constructions branlantes avec des briques en terre cuite parce qu’on en a sous la main, ou on passe au parpaing, quite à allez en chercher au PointP un peu plus loin, pour faire des trucs un peu plus audacieux ? (sacré parallèle là, fuuu…)
[quote]pour moi, ms a eu le courage de remettre les choses à plat pour repartir sur des bases saines[/quote]Je ne suis pas contre une remise à plat de l’architecture, mais on devrait avoir le choix entre faire appel à des librairies partagées ou linker uniquement le code objet qui nous interesse dans le cas de déploiements pénibles ou utilisateur final.
[quote]Je ne suis pas contre une remise à plat de l’architecture, mais on devrait avoir le choix entre faire appel à des librairies partagées ou linker uniquement le code objet qui nous interesse.[/quote]ce qui remet aussi potentiellement en cause la nouvelle gestion des dll. la solution est pas évidente, surtout si on considère que bilou lui même ne l’a pas trouvée (non de dieu, j’suis en train de le défendre maintenant… )
–edit–
ces foutus smileys fantomes, ça me rendra fou Ce message a été édité par Tupperware_ass le 04/12/2003
Quand Glop se levera il te donnera surement plein de détails professionels, moi je peut te donner mon point de vue d’amateur pour tuer le temps : il faut effectivement que le framework (qui ne fait pas 50Mo, mais 20) soit installé, et de préférence à jour.
Et comme tu le suppose bien, dans les prochaines version de winwin, il sera compris dedans. L’avantage par rapport à toutes les autres DLLs que je voit, c’est qu’il n’a besoin d’être installé qu’une fois pour toute. Si ca continue de te choquer, pense à DirectX et la manière dont c’est rentré dans les moeurs.
Bien sur, quand je fait un programme qui pese 54Ko une fois compilé et demande à l’utilisateur d’avoir 20Mo de packages, ca semble un peu gonflé.
Après … Tu peut développer tes applications dans différentes optiques :
commerciale : dès l’instant où ton programme est le meilleur du marché, et que des gens sont pret à le payer, personne ne trouvera a redire à ces 20Mo
freeware/logiciel libre : étant donné que tu demande rien à personne et que tu offre quelque chose, les gens seraient gonflés de raler
shareware : là, y a un probleme effectivement car pour pousser les gens à l’utiliser puis l’acheter, les 20Mo supplémentaires peuvent être un frein.
Enfin, tu ne précise pas si il s’agit d’application web ou d’applications windows (rapport à WebMatrix). Dans le premier cas (sauf erreur d’amateur de ma part), tu n’a pas besoin de t’en préoccuper puisque seul le serveur doit avoir le framework installé. Dans le deuxième, on retombe sur les problèmes précédement soulevés.
Comme je disait, c’est un point de vue totalement amateur, et pas du tout dans une logique professionelle. Comme je dit dans les readme qui accompagnent mes softs : “vous avez besoin du framework.net pour faire fonctionner ce logiciel. Installez le, c’est le futur de toutes facons.”
Ben j’ai pas grand chose a rajouter a la reponse de Bishop.
Oui c’est le futur, on y coupera pas. Les nombre d’application utilisant le framework en rich client va monter exponentiellement. Les debuts sont difficiles, personne n’ose… puis de plus en plus de monde considere qu’apres tout, c’est pas la mort 20 megs et que, en plus les gens ont une chance de plus en plus grande de l’avoir. Les premiers a sauter le pas prennent un risque c’est sur mais ils y gagnent en temps de developpement et en flexibilite. Alors que faire? La reponse est pas facile et tout est question de priorite, familiarite des devs avec le framework, objectifs strategiques a court et long termes. En revanche une boite qui ignore completement le framework en se disant “de toute facon on verra plus tard” a mon avis c’est du suicide. Je pense que meme si beaucoup de boites considerent que leur v next n’a pas besoin du framework, ne pas penser deja a comment l’integrer pour la v+2 c’est nawak Meme regarder ce que fait longhorn commence a etre logique pour beaucoup de societes avec un prodct cycle long (12 a 24 mois).
Au final de nombreuses societes sont deja passe a .Net pour leur rich client en milieu controlle (genre en entreprise sur un jeu de poste donne), ou meme pour des applications distribuees sur CD avec du matos (la gestion des photos pour HP par exemple est faite en .Net). On voit encore peu d’applications sur le modele “installe, teste, si c’est bien c’est un succes parceque d’autre vont l’installer” qui utilisent .Net a cause justement de la barriere du framework. Mais quand la premiere categorie atteindra une masse critique, le probleme disparaitra de lui meme. Exactement comme pour directx…
Pour un amateur, comme l’a dit Bishop, a mon avis il y a pas d’excuses. C’est a tout le monde aussi de participer pour encourager les gens a installer le framework… si ils ne l’ont pas deja
[quote]Oui c’est le futur, on y coupera pas. […]Les debuts sont difficiles, personne n’ose… puis de plus en plus de monde considere qu’apres tout, c’est pas la mort[/quote]Je comprends bien que c’est le futur mais ça ne réponds pas à ma question sur les cas de déploiement difficiles:
Pourquoi ne peut-on pas linker uniquement les librairies nécessaires ?
C’est une limitation technique ? C’est une obligation demandée par les commerciaux pour faire en sorte que .NET ait une visibilité chez l’utilisateur ?
edit: Par contre j’ai compris que .NET apporte une unification des méthodes de développements et des sources entre les clients légers et les clients lourds, voire multi-plateforme. Ce qui est tout de même nouveau venant de microsoft (bien que j’ai lu qu’il y a des difficultés de portage).
[quote]Je comprends bien que c’est le futur mais ça ne réponds pas à ma question sur les cas de déploiement difficiles: Pourquoi ne peut-on pas linker uniquement les librairies nécessaires ?[/quote]Parceque le CLR va bien plus loin qu’une suite de librairie. C’est un nouveau type d’executable qui n’a rien a voir avec les executables classiques. Ca n’est pas un process qui se charge, s’inserant entre un exe .net et l’OS et qui se met a compiler a la volee le MSIL. Ca va beaucoup plus loin avec un JIT qui descend tres bas dans l’OS. Un simple bibliotheque ne saurait pas repondre a ces besoins et c’est pour ca que ca va vite… La vision depuis le depart est de remplacer la maniere dont on construit et on execute les executables sur une machine, pas de rajouter une couche supplementaire a la “virtual machine”. Stricto sensu .Net n’utilise d’ailleurs pas de machine virtuelle contrairement a ce qu’on peut lire ici et la. C’est bel et bien un choix technologique, pas du tout une raison marketting ou je sais pas quelle raison farfelue. Ce message a été édité par GloP le 05/12/2003
[quote]La vision depuis le depart est de remplacer la maniere dont on construit et on execute les executables sur une machine, pas de rajouter une couche supplementaire a la “virtual machine”. Stricto sensu .Net n’utilise d’ailleurs pas de machine virtuelle contrairement a ce qu’on peut lire ici et la.[/quote]Oui, oui, tu l’as déja dis… Bien que quand on me demande d’expliquer comment ca marche, je suis toujours tenté de l’expliquer par là.
Ma question est donc, comment expliquer simplement le principe de fonctionnement aux “novices” ?
Contredit moi si je dis une connerie GloP mais .Net a été développé
pour faire face au Java. Donc c’est une technologie qui est d’abord
concu pour les entreprises. Pour une entreprise, faire une
maj de 20Mo sur un serveur ou même sur tous le parc informatique est un détail, ils
suffit de rajouter .Net à la tonnes de maj de sécurités hebdomadaire.
[quote]Donc c’est une technologie qui est d’abord concu pour les entreprises. Pour une entreprise, faire une maj de 20Mo sur un serveur ou même sur tous le parc informatique est un détail[/quote]Donc .NET n’est pas très adapté pour les PME de 5 personnes qui ont un pentium 450 Mhz et 500 Mo de disque dur rempli à mort.
Et il y a beaucoup plus de PME de cette taille que l’on ne le croit. Même problème pour les logiciels style FNAC ou petits sharewares.
Sinon je conviens que les innovations apportées par cette plateforme feront vite oublier ce défaut dans les entreprises avec un minimum de moyens informatiques.
[quote]Contredit moi si je dis une connerie GloP mais .Net a été développé pour faire face au Java. Donc c’est une technologie qui est d’abord concu pour les entreprises. Pour une entreprise, faire une maj de 20Mo sur un serveur ou même sur tous le parc informatique est un détail, ils suffit de rajouter .Net à la tonnes de maj de sécurités hebdomadaire.[/quote]Non c’est faux. .Net a ete concu pour remplacer la maniere dont on developpe sous windows pour tout le monde et tout les logiciels, du particulier a l’application serveur. Cependant il faut bien commencer quelque part dans le deploiement et le particulier est bien sur au bout de la chaine. Dans sa conception .Net a integre des le debut les contraites liees aux particuliers… A quoi bon se tirer une balle toutes les semaines pour que ca marche le mieux possible sous 98 ou avec des acrhi vieillottes sinon …
De plus ca a pas ete developpe pour “faire face a Java“, mais parceque Java ne repondait pas aux attentes et ne cadrait pas avec ce que voulait faire les ingenieurs de MS pour repondre a la question : “Comment on va programmer sous windows dans 10 ans?”. Le coeur de .Net, le CLR, a ete developpe par des gens qui ont pas du tout bosse sur le Java de MS a la base et qui se sont plus inspires des bases que sont SmallTalk et C++. Mais tout le monde semble oublier ce qu’est Smalltalk qui est l’inventeur du model-view-controller, et d’a peu pres tout les concepts derriere Java. Un peu comme quand on dit qu’Aplle est l’inveteur de l’ordinateur personel en oubliant la dizaine de machines qui l’ont precede… D’ailleurs le groupe qui faisait J++ et les extension a Java a la base est l’ancetre du groupe qui fait windows forms, pas celui qui fait le CLR. Il doit rester une personne a tout casser depuis le temps cela dit…
Enfin donc, oui tout le monde est bien conscient que .Net vient mettre la zone dans les plans de Java, et c’etait sans doute pris en consideration dans le dev de .Net mais c’est clairement ultra reducteur que de dire que ca a ete fait “pour ca”. C’est meme loin d’etre la raison principale. .Net est bien plus ambitieux que de “rajouter une couche” differente et plus facile. Si ca semble etre le cas avant longhorn c’est pas du tout la vision a moyen/long terme qui consiste a en faire la base du devel sous windows, s’integrant tres bas dans l’archi de l’OS, pour la majorite des taches. .Net a ete fait en pensant pour 10/15 ans et sur le futur de la programmation sur la plate forme windows, en concertation avec le futur de l’OS et du reste des API, pas juste “houla il faut faire qqch pour repondre a X, Y ou Z”. Quand on fait ca, on reste toujours a la traine…
[quote][quote]Contredit moi si je dis une connerie GloP mais .Net a été développé pour faire face au Java. Donc c’est une technologie qui est d’abord concu pour les entreprises. Pour une entreprise, faire une maj de 20Mo sur un serveur ou même sur tous le parc informatique est un détail, ils suffit de rajouter .Net à la tonnes de maj de sécurités hebdomadaire.[/quote]Non c’est faux. .Net a ete concu pour remplacer la maniere dont on developpe sous windows pour tout le monde et tout les logiciels, du particulier a l’application serveur. [/quote]lol. c’est vraiment tendre le baton pour se faire battre là…
[quote]Le coeur de .Net, le CLR, a ete developpe par des gens qui ont pas du tout bosse sur le Java de MS a la base et qui se sont plus inspires des bases que sont SmallTalk et C++. Mais tout le monde semble oublier ce qu’est Smalltalk qui est l’inventeur du model-view-controller, et d’a peu pres tout les concepts derriere Java.
ah Glop, je t’écouterais parler pendant des heures de Smalltalk…
j’adore ce truc, c’est mon chouchou perso
Un autre truc qu’il faut savoir, c’est que ça fait belle lurette que le Framework est distribué par Windows Update. Donc si vous faites vos mises à jour régulièrement, vous l’avez déjà. Sauf si vous n’installez que les mises à jour critiques.
Et il est d’origine dans Windows 2003 (et non dans la prochaine version comme il a été dit).
Je ne connais pas les chiffres, mais la diffusion est déjà bien large.
Je me suis surement mal exprimé, j’aurai plutot du dire que .Net était
fait pour ‘remplacer’ java plutot que pour faire face au java (même si
il ne faut pas le réduire qu’à ca, j’ai bien compris). Sinon, tu connais beaucoup de PME qui
utilisent .Net, GloP ? Dans quels genres d’applications ? La semaine
dernière j’ai suivis une conférence d’un mec de chez IBM qui disaient
que ce qui marchaient le mieux dans les PME c’était l’eServer. Le mec,
il faisait ca propre pub, forcément, mais c’est vrai que ce type de
serveur répond à pas mal de besoin. Je sais aussi qu’il est possible de
rajouter une carte d’extention Windows en plus du couple Linux/OS400,
mais est-ce que beaucoup d’entreprises le font.