[Débat] Expériences au sujet de .NET [Débat]

Hello. Je vous trouve très gentil avec MS. Moi, je n'y arrive plus. En fait, je suis programmeur VB depuis QB 2.0. Je suis passé par QB 2.0, QB 4.5, MSPDS 7.0, VB DOS 1.0, VB WIN 2.0, VB WIN 4.0, VB WIN 5.0, VB WIN 6.0.... A l'époque, j'avais fais un peu de C, de C++ et de l'assembleur avec MASM 6.0 (j'oublais : un peu de GWBASIC aussi!) sans pouvoir décrocher de la famille du basic à cause de son enorme facilité de dev rapide et ce malgré ses problèmes de mémoire et de vitesse.

J'ai attendu longtemps d'avoir un VB7 et aujourd'hui, je peux vous dire que je suis très décu. Au point que je viens de changer de langage en choisissant borland c++ 6.0 Builder. J'aime pas delphi, c'est pas forcement logique mais surtout viscéral.

Pourquoi suis-je décu ? J'ai bien sur reçu les bétas de .NET, j'ai fais un peu de dev dessus puis j'ai arrêté, non sans prendre un abonnement MSDN pour être sur d'avoir la version finale des qu'elle sortirait.

Et des qu'elle est sortie, je me suis mis sur un projet perso plutôt technique et complexe - vu la force de .net, je me suis dis que je pouvais mettre le paquet : un gros logiciel d'analyse graphique pour la bourse

Très bien. Je commence et à part quelques problèmes de clarté dans le langage à propos des déclarations valeur/référence, tout va bien.... Et j'apprécie énormément le compilateur intégré qui permet de recompiler du langage VB.NET depuis un exécutable .NET - Ca permet à mes utilisateurs de programmer eux même des courbes graphiques et en plus ça compile.

Seulement, quand je commence à afficher une dizaine de courbes graphiques calculées en temps réel, je me rend compte que le truc va franchement pas assez vite et qu'il sera rapidement dépassé, je cherche des solutions, je pleure sur les NG de microsoft, j'obtient quelques réponses que j'applique à mon programme, ça s'améliore un peu mais finalement ça me convient toujours pas. Pour palier définitivement à ce problème, j'utilise la bibliothèque de compatibilité .NET / VB6 et je dessine mes graphiques en utilisant DirectX8. La, plus de problèmes, ça booste. La lenteur provient donc bien de GDI+. Bon, je me sens pas très bien quand même parce que ça m'oblige à distribuer le framework : 20 méga, DirectX 8 : environ 10 mega, mon programme : 300ko.

Par acquis de conscience, je fais un test d'installation de tout ça sur un windows 98 formaté. Je copie le necessaire : .NET framework redist, DirectX 8.0 et mon programme.

Je double clique sur .net framework installation et vlan premier message : il faut IE6 pour installer le truc. Resultat: Je télécharge IE6 : 80 mega, Je l'installe puis j'installe le framework : premier reboot. J'installe DirectX : deuxieme reboot. Je clique sur mon programme pour le lancer : vlan, il manque MDAC (pour les bases de données). je télécharge MDAC 2.6 et j'installe : troisième reboot. Je clique à nouveau sur mon programme, vlan, il manque MS-JET 4.0 (Gestion des bases de données Access) que je télécharge aussitôt : 5 MEGA. Je reclique sur mon programme (va t'il marcher un jour?) ben non, vlan, il manque les bibliothèques de compatibilité VB6 (pour DirectX) fournies avec VS.NET mais pas avec le Framework. J'installe les bibliothèques et enfin mon programme marche. Mais sacrée galère quand même.

Pour faire tourner un programme de 300 ko sur un poste w98 vierge, j'ai du installer environ 120mega de programmes compressés. C'est pas mal pour un programme que je veux distribuer en shareware !!! Absurde !!!

Si le framework est bien en substance, il se traine des tares monstres. C'est à dire qu'il faut quasiment distribuer une version .net de windows pour un programme de 300ko. De plus, il est franchement trop lent. Si sur de nombreux points, il est plus rapide que VB6, je suis persuadé que sur d'autre il l'est moins. Tout ceci, m'a dégouté et me fait changer de langage, avec regrets mais sans choix.

J'ai aussi testé ASP.NET et je peux vous dire que mes programmes fait en ASP 2.0 était compilé et tournaient très vite car j'utilisais ASP uniquement comme passerelle de quelques lignes pour lancer des DLL ActiveX. De ce point de vue, ASP.NET ne révolutionne rien pour moi. La compilation existait déjà bien avant. Concernant les WEB Controles, ils n'ont aucun interet, si ce n'est de faire ramer l'application web. En effet, ces contrôles se comportent comme les contrôles d'une applications windows classique : ils déclenchent des événements qui sont immédiatement renvoyés vers le serveur mais avec l'énorme problème que cela passe par internet et que ca ralentit grave. En intranet, ça peut être interessant, mais sur internet : zéro. On en revient à la programmation classique de site web, mais avec l'avantage évident de pouvoir programmer avec de vrais langages : VB.NET, C# et bientôt DELPHI.NET, c'est quand même bien pour ça, ces langages sont nettement plus évolués que les anciennes versions d'ASP. Par contre, programmer un site web avec .NET, c'est pas une sinécure car 1) VS.NET rame lourdement et l'alternative WEBMATRIX n'en est pas une car elle est trop limité : pas d'intellisense, pas de mise en forme de la syntaxe, etc. Ensuite, il faut au minimum windows xp pro ou windows 2000 et bien sur IIS version 5 minimum. Auparavant, on pouvait créer son site web avec PWS (personal web server) gratuitement et sous windows 98. Donc financièrement, c'est pas la même histoire non plus. En revanche, le concept des web services semble très intéressant pour les applications distribuées.

En conclusion, à l'heure actuelle il apparait évident que .NET n'est pas adapté au developpement d'applications windows critiques, rapides, portables entre différentes versions de windows, à des distributions grand public par internet sous forme de sharewares ou freeware, etc

Il apparait, par contre, être une évolution sérieuse du langage ASP en permettant la programmation, sous différents langages, de sites web et integre les controles web pour des applications intranet. Ou encore des applications distribués via les services web.

C'est donc plutôt un produit qui vise les entreprises. L'installation du framework sur tous les postes serait un véritable plus dans de nombreux cas malgré l'importante mise à jour necessaire. Si l'on devait faire une comparaison avec Java, je dirais que si Java n'avait pas la portabilité qu'il a, il serait écrasé par par le trio Visual Studio.NET / .NET Framework / C# mais comme ce n'est pas le cas, les choses sont différentes. Dans le cas ou l'on le poid du déploiement des outils ne pose pas de problème et que la plate forme cible est windows/internet, .net reste l'outil de premier choix. Dans le cas contraire, il faut utiliser Java sans discuter.

Quand à moi, je respecte cette façon de voir, et j'ai choisi borland Builder c++ car il dispose d'outils rad inexistants ailleurs que chez microsoft. En effet, BC++ Builder permet de construire une appli de la même façon qu'avec vb.net. La bibliothèque fournie avec Borland C++Builder version entreprise est plus riche que celle de .net. par ailleurs, les applications produites avec Borland C++Builder sont rapides et portables (linux,windows95,98,etc). Il est d'ailleurs fort probable que je change de plate forme pour linux pour des raisons économiques: la dependance microsoft revient chere (notament à cause des licences)

Même si j'ai évité les aspects purement techniques, j'espère avoir apporté un peu de lumière sur .net.

A+

.NET est une technologie permettant le développement d'application distribuées utilisant des WebServices et ne s'affiche pas comme le dernier outil permettant de créer des graphiques et de jeux. DirectX est effet l'API optimisée pour ce genre ce traitement c'est ce qui a pu être vérifié.

Désolé, mais DirectX est une api faite pour les jeux (ses fonctions 2D sont des plus primaires - pas de primitives telles que rectangles ou cerles). DirectX est essentiellement un composant pour faire de la 3D. J'ai un peu triché en l'utilisant pour palier aux faiblesse de GDI+.

J'utilise désormais les outils de dessins de bc++. J'ai enfin une vitesse correcte cela passe directement par GDI. Tout ce que je peux dire c'est que GDI+ possède de jolie fonctions pour le dessins, mais qu'il est très lent. Très, très lent. Et pourtant je travaille avec un pc1,7ghz et une carte geforce4. Impossible de demander à des utilisateurs de changer de machine pour faire tourner mon logiciel, c'est moi qui change d'environnement. Si je ne le fais pas, je cours à ma perte.

Tu n'as pas besoins de IE6 pour installer le framework.NET : IE6 est seulement conseillé lors de l'installation mais pas obligatoire !

IE5.01 est obligatoire au minimum, sinon le programme d'install t'envoie bouler. Donc tu téléchargeras IE6.0 parce que l'on ne trouve plus IE5.01.

Pour ce qui est de la librairie MDAC, tu pux l'inclure à un setup avec le framework, et ton prog. Tu n'arrives donc qu'a 1 setup, et 1 reboot

C'est juste. Mais, je préfère changer de langage et distribuer un fichier de 350ko qui fait la même chose, plus vite et moins lourdement plutôt que de "tenter" d'imposer aux utilisateurs une montagne de DLL dont, ne l'oublions pas, le contenu reste obscure et qui, en plus, se permet de modifier le système destinataire sans autorisation. Or, ce n'est pas le rôle d'un programme utilisateur que de modifier autant le système client. C'est le rôle d'un service pack. Microsoft aurait pu faire autrement mais il désire surtout s'imposer très profondément dans les PC même si pour cela il doit utiliser la crédulité des programmeurs qui lui font confiance.

- S'imposer n'est pas un vain mot d'après ce que j'ai pu lire à propos de la future plate forme PALLADIUM - On pourrait même dire greffer, s'incruster, etc...

En forcant l'installation d'IE6 avec son framework, celui lui permet aussi de contourner l'interdiction qui lui est fait d'installer automatiquement IE avec Windows et de laisser à l'utilisateur le choix du navigateur internet. On peut logiquement se demander ou est l'interêt d'IE6.0 dans un programme d'installation.

J'ajoute qu'il est possible de faire dix fois fois plus de chose avec un bc++ qu'avec un c# ou un vb.net. La librairie VCL et ses satellites est beaucoups plus importante que le framework, sans parler de l'open source gigantesque et gratuit disponible en c/c++.

De plus, avec bc, nous ne sommes pas dans le monde fermé et controlé de .net mais en c++. La philosophie est radicalement différente.

Un exemple, si je veux faire un web service avec borland c++, j'hérite du composant de base, j'expose ses propriétés et méthodes, je lui attribue un n° de port sur la machine hôte et ça marche. Pas besoin de IIS et d'une plate forme W2000 ou XP Pro !

Autre exemple, si je veux une grosse base de données puissante, il existe Interbase. Multiusers, Transactionnelle, etc.... Gratuite et en open source.
Ou encore Berkeley Database, capable de gérer les clusters, etc...Gratuite aussi.

C'est toute la politique de MS que je met en cause. Avec .NET, L'utilisation d'un élément entraine quasi systématiquement l'utilisation d'un autre produit (généralement MS). Et, à ce propos, je trouve le prix de VS.NET trop cher car il ne fourni que la base et ne donne pas vraiment les moyens de créer soi même les outils manquants. Pour mes graphiques, avec .NET, il faudrait que j'achète une librairie graphique externe car .NET n'est pas assez puissant. BC++ l'est (et pourtant, dans la catégorie des compilateurs c++ c'est celui qui génére les exécutable les moins rapides, et de loin). Et, pourtant, .NET est un escargot à coté de BC++.

En programmeur avisé, que peut on déduire de tout cela si ce n'est qu'il est urgent de changer. Aujourd'hui, j'affirme que rien n'excuse Microsoft si ce n'est de dire que ses produits sont uniquement destinés à des débutants.

Pour ce qui est de la taille du framework, je suis tout à fait d'accord avec toi, et c'est l'une des principales faiblesses de DOTNET. Cependant on peut-être sur que les prochainne versions de windows intégrerons le framework en natif. DOTNET est jeune, donc pas encore assez implanté

D'ici la, il aura fallu acheter la nouvelle version de .net, acheter le nouveau windows et avoir beaucoups de patience, de tolérance et de persevérance entre les délais, les différents services pack et les arguments pour convaincre les utilisateurs d'une telle mise à jour.

il est fort probable que Le prochain Borland C++ intègre .NET.

Certainement et tant mieux, mais cela devrait se faire sous la forme d'un menu et d'une boite d'options du style : générer un exécutable .net
Je ne pense pas que borland se soumettra plus que cela aux ambition de
Microsoft - quoique, vu que M$ à acheté 10% des actions borland, on peut s'attendre à tout. Mais Borland ne serait plus Borland.

Sache que le framework .NET ne tourne que sous win98 ou plus, or dés win 98 tu as au moins internet explorer 5.01, au moins sur le CD de windows. Aprés si tu veux télécharger la version 6 : no problème, c'est même conseiller mais ne va pas dire que tu es obligé de télécharger une version de IE pour installer le framework .NET parce que c'est FAUX

Sur W98, c'est IE4 qui est installé avec le CD d'install. Etant donné qu'IE5 n'existe plus, il est donc nécessaire d'installer IE6. Avant de traiter les gens de menteurs, on se renseigne, merci. Surtout que je me suis bien embété avec cette installation de .NET sur un W98 !

via ODBC tu peux travailler sur n'importe quelle base de données...

Je parle de base de données gratuite et non de connexion. Si il est un avantage certaine de pouvoir utiliser ODBC, il n'en demeure pas moins que ODBC n'est pas une base de données mais une norme pour les connexions. Je parle de base de données gratuite et que je sache, SQL Server est loin d'être gratuit avec son prix de base et ses licences de connexions. Car il faut acheter une licence pour chaque connexion que l'on veut ajouter à la base de données. Il faut aussi payer les licences pour se connecter à W2000. Une connexion à une base SQL Server recquiert donc 2 achats de licences, si je ne m'abuse.

C'est un peu exagéré il me semble car si l'asp.NET est pour des débutant de la programmation web, je souhaiterais vivementt que tu me conseille un outil professionnel, merci d'avance !

Dans la mesure ou les produits MS sont accessibles au grand public, ils sont par définitions simples et facilement configurables. En cela, ils sont donc des produits à l'usage des débutants. Etant des produits finis, ils possèdent les défauts et les qualités inhérentes à ce type d'outils, à savoir une lourdeur, une lenteur et des limitations physiques en contrepartie de la facilité d'utilisation.

Comme outils pro, ce que j'ai vu de plus puissant jusque maintenant, c'est le langage PERL. Il a des facultés de traitements de chaines 100 fois plus puissantes que tout ce qu'il est possible de faire avec les commandes FORMAT et LIKE d'ASP.NET. Ainsi, il faudrait faire en 7 ou 8 fonctions VB ce que peut faire une seule ligne en PERL. Par exemple, remplacer recursivement dans une chaine les 6 dernières différentes occurences par 3 autres occurences. Et ce n'est qu'un exemple limité de la puissance de PERL concernant la manipulation des chaines.

Merci DevX pour ces précisions.

Tu fais la remarque de la lenteur du GDI+ et du chargement d'un formulaire et cela ne m'étonne pas du tout car dans le sujet "Java versus .NET" ( sujet http://www.developpez.net/forums/viewtopic.php?t=30401) , j'avais indiqué les raisons probables pour lesquelles cette lenteur soit justifiée :
les contrôles sont crées dynamiquement comme avec Java contrairement à un programme fait avec Delphi ,Visual C++ , C++ Builder où ils sont regroupés dans un fichier de ressources.
Je ne vais pas me répéter : j'ai déjà travaillé sur un projet avec 150 formulaires en VB6 , chaque formulaire contenant au moins 20 zones de textes.Donc si tout est chargé dynamiquement...
Le gros avantage est l'aspect architecture distribuable comme avec Java et les Web Services conférant une parfaite homogénéité en vue d'un projet client /serveur .
NET convient très bien à des projets pour des SSII et des clients comme grands comptes , banques quoique comme tu sembles l'indiquer les performances en patissent même sur une machine rapide.
Le problème est que l'utilisateur lambda déteste attendre quand il clique sur un bouton ce que ne semblent pas prendre en compte les gens qui gérent des projets informatiques.

En conclusion, à l'heure actuelle il apparait évident que .NET n'est pas adapté au developpement d'applications windows critiques, rapides, portables entre différentes versions de windows, à des distributions grand public par internet sous forme de sharewares ou freeware, etc

Cela fait écho à ce qui est écrit précedemment.
NET n'est pas fait pour faire des applis génériques rapides ou shareware comme tu le dis.
Tu vas développer une appli avec NET , il va falloir distribuer un gros runtime pour le moment ( puisqu'il sera intégré au futur OS évidemment ).
L'inconvénient est que ce runtime ( comme ce fût le cas avec VB6 ) renferme des fonctions que tu ne sois pas susceptible d'utiliser :
quel intérêt d'avoir des fonctionnalités Internet et de Web Service si je veux faire un programme de dessin comme Paint Shop Pro , contenues dans un runtime de plusieurs mégas ??
Qu'est qu'on en a à foutre d'une fonction ConnectionSurInternet() ou ControleWebService() pour un logiciel de dessin ou un jeu de pendu ???
Le probléme est que ton appli VB.NET fait appel au runtime renfermant ces fonctionnalités -> pas d'optimisation possible

Ensuite, il faut au minimum windows xp pro ou windows 2000 et bien sur IIS version 5 minimum

De même qu'il faille une machine puissante ( à mon avis un pentium IV à 1Ghz et + et 128 Mo de RAM ) pour développer avec Visual Studio.NET.
Imaginez un projet développé avec VS.NET pour un gros compte : conséquence classique : il faut faire évoluer tout le parc utilisateur. Bonjour les coûts !!! Votre Directeur Informatique sera content.

Je ne pense pas que borland se soumettra plus que cela aux ambition de
Microsoft

C'est fortement souhaitable.
La grosse erreur de M$ est de vouloir imposer sa sauce .NET à tout prix .
Mais qu'en est-il des applis temps critiques ou informatique industrielle ???
Après la X BOX et son fiasco relatif nous feraient-ils une deuxième boulette ??

Il faut laisser mûrir NET ???
Soit mais cela coûte cher de faire migrer des applis avec cette nouvelle architecture et pour quel intérêt ?
Messieurs les responsables informatiques quel est votre avis ??

>>Monsieur Leduke

DirectX est effet l'API optimisée pour ce genre ce traitement c'est ce qui a pu être vérifié.

Ben avant comment on faisait ?? Et même comment on fait toujours ? Le GDI semble plus ou moins donner satisfaction avec les produits Borland ou Visual C++ ( win32/MFC ) . Bon ok c'est vrai on peut pas en faire un web service comme avec GDI+

et tu n'as toujours pas répondu à mes questions. meme à partir du fichier de ressources, les controles sont créés dynamiquement pour les outils Delphi et BCB, tu n'as compris comment ils fonctionnent...

oops :
avant la commercialisation et la diffusion de la nouvelle architecture de Visual Studio NET c.a.d. jusqu'à présent , une appli classique véritablement compilée en code natif ,pour afficher les contrôles crées en conception utilise un fichier de ressource , en fait un fichier script comme les fichiers dfm , tpu avec Delphi , Cbuilder , frm avec VB et rc MFC/Win32.

Basiquement avec le SDK win32 un fichier script .rc est compilé en fichier binaire .res lui-même lié avec les fichiers objets .obj issus de la compilation du code source.
Contrairement à la conception dynamique de contrôles , des références ou pointeurs à ces contrôles sont créees au lancement du programme et ces références pointent vers une dll , user.dll je crois .
Pour afficher 3 boutons , le fait d'utiliser un fichier de ressources ou de les créer dynamiquement comme en C#/NET ou Java n'a pas d'importance.

Mais qu'en est-il d'une (i] form [/i] contenant 50 boutons ??

Autre aspect vraiment crétin d'un outil RAD : prenez Visual Basic 6 ou .NET , Delphi ou C++ Builder .
Vous créez une fenêtre vous allez placez un bouton poussoir ou pushbutton .
Regardez tous les événements qui sont rattachés à ce bouton : pas moins de 10 événements...totalement inutiles comme savoir si la souris passe dessus .

En pure win32 ou avec les MFC ( ça y est c'est le conflit diplomatique !) , seulement 2 messages : BN_CLICKED et BN_DOUBLECLICKED

Selon le bon sens , un bouton c'est fait pour être cliqué ou non !
Alors pourquoi rattacher une dizaine d'événements aussi inutiles ?
Un programme Windows est architecturé selon une gestion de messages émis dans une file d'attente.

Vous allez me dire que je raconte n'importe quoi et quelle importance ?
Il y a un an , j'ai travaillé parmi une équipe de développement sur un gros projet client VB6 et serveur As400.
Il y avait 150 forms dans le projet VB ; et chacune contenait pas moins d'une dizaine de EditBox.
Au fur et à mesure du développement du projet , les gens qui développaient le projet se sont aperçus que ces zones de saisie ( EditBox) prenaient énormément de ressources et les ont remplacés ( c'est malin....) par des contrôles statiques ou labels...
Voilà pourquoi avec un outil RAD , on retrouve des imbécilités.
Si vous mettez 10 boutons sur un formulaire avec 10 méthodes chacune , cela fait 100 messages à traiter .
Comment le programme et l'OS traitent-ils tout cela ??

Epictete a écrit :

PS : Comme chacun sait, Microsoft à une position Marketing considérable. De part le fait Microsoft n'à pas besoin de forums tels que celui ci pour faire connaitre ses solutions, d'ailleurs la pub .NET passe à la télé, c'est dire....

Certes mais les sbires de Redmond , état de Washington , ferait mieux de s'inquiéter.

Car il n'ya pas que la pub .NET qui passe à la télé mais aussi celle d'un autre géant de l'informatique IBM.
Vous avez tous vu la pub avec les basketteurs . Et de quoi parle-t-on dans cette pub ?? Je vous le donne dans le 1000 : de Linux.
Il ya pas si longtemps on disait que c'était un outil pour passionné ou étudiant . Mais si IBM investit de la R&D dans cet OS...
Le projet futur de M$ , pour l'instant nommé Palladium , suscite bien des controverses .
Or si tout ce qui est estampillé M$ pose trop de contraintes à l'avenir ( c.a.d. clés d'activation , bridage des logiciels et de l'OS ) , il ya à parier que le marché se tourne vers d'autres systèmes.

la resource décrivant l'interface (.rc, .dfm, etc) est chargé au démarrage et cré dynamiquement les controles....

Absolument d'une manière ou d'une autre elle sera tjs crée dynamiquement car les contrôles ne persistent jamais en mémoire sauf si le programme s'exécute cela va de soit...
Mais à la différence de contrôles décrits dans un fichier de ressources , en considérant une appliquette Java ou un programme C#/VB.NET , le méchanisme est différent : il faut INTERPRETER chaque instruction pour affecter les propriétés et afficher le contrôle avec une instruction Button bouton =new Button(this)...
Quel est le c.. qui a inventé les languages interprétés ???