Discussion :

[Bartholivier]

bonjour a tous.

Je ne suis pas informaticien mais électronicien de formation. J'ai évolué dans cette profession plus par passion et par tâtonnement. Je m'interroge sur plusieurs points a propos de .NET et je voulais avoir des conseils de vrais développeurs.

Je connais pour le moment VB6, VC++6, asm, ai fait un peu de MFC,drivers, dll, BDD, etc ..

Un peu dinosaure et dans une société où mes compétences dans les langages ci dessus sont suffisants j'ai voulu me mettre a .NET afin de pas trop passer pour un arriéré et me mettre au gout du jours.

deux barrières déjà. Une gestion voie série trop aléatoire a mon sens en fonction du PC cible( Mais peut-être que mon codage n'est pas bon) et la distribution : on comparais a l'époque le coté managé de VB6 et de sa multitude de DLL à installer a VC++ plus souple et moins gourmand en taille. Mais pour des petites applications simples avec .NET on est tout de même obligé d'installer tout le Framework soit un minimum de 20Mo ... (en fonction de la version)

donc deux questions:

*Existe - t - il un moyen simple de distribuer une application .NET sans pour autant obliger le client a installer le framework (de nombreuse machines ne sont pas en VISTA ou connectée a internet pour les MAJ)

*J'ai lu beaucoup de chose sur la toile et j'y perd mon latin. Le .NET est il managé ou compilé en code natif avant son exécution ? n'y perd on pas en rapidité d'exécution globale de l'application par rapport a un code compilé tel VC++6 ?

J'avoue avoir du mal a quitter VB6 et VC++6 tellement je trouve ces langages faciles à distribuer et a manipuler (ouai enfin manipuler ... j'ai pas fait de grandes choses non plus)

Oh je ne m'attend pas a un tôlée d'applaudissements mais plus à des tomates jetées par les pro .NET qui verront dans mes questions une douce senteur d'amateurisme. Grand bien vous fasse, si je peux trouver dans vos propos un début d'éclaircissement

[tomlev]

Mais pour des petites applications simples avec .NET on est tout de même obligé d'installer tout le Framework soit un minimum de 20Mo ... (en fonction de la version)

Oui, comme pour Java par exemple... les programmes .NET ne ciblent pas directement la machine physique, mais une machine virtuelle, il faut donc que celle-ci soit installée.

*Existe - t - il un moyen simple de distribuer une application .NET sans pour autant obliger le client a installer le framework (de nombreuse machines ne sont pas en VISTA ou connectée a internet pour les MAJ)

Depuis la version 2008 de Visual Studio, je crois que tu peux n'utiliser qu'un "subset" du framework, mais je n'ai pas testé...

*J'ai lu beaucoup de chose sur la toile et j'y perd mon latin. Le .NET est il managé ou compilé en code natif avant son exécution ? n'y perd on pas en rapidité d'exécution globale de l'application par rapport a un code compilé tel VC++6 ?

.NET est un environnement d'exécution managé. Le code est compilé en MSIL (Microsoft Intermediate Language, une sorte d'assembleur pour la machine virtuelle). Lors de la première exécution d'un code MSIL, le runtime le compile "à la volée" en code natif ; ensuite si le code MSIL n'a pas été modifié, c'est le code natif en cache qui est utilisé, si bien que les performances restent très correctes.

J'avoue avoir du mal a quitter VB6 et VC++6 tellement je trouve ces langages faciles à distribuer et a manipuler (ouai enfin manipuler ... j'ai pas fait de grandes choses non plus)

Avec un minimum de pratique, tu verras que .NET est encore beaucoup plus facile... le framework contient énormément de classes qui peuvent faire le gros du boulot à ta place, et Visual Studio est une aide précieuse au développement (snippets, refactorisation de code, assistants, designers...)

[Bartholivier]

Merci pour ta réponse.

Je vais essayer de m'y mettre. c'est vraiment ce problème de distribution qui me gêne. Mais bon, avec le temps cela rentrera dans les meurs de nos client . pour le MSIL je comprend mieux. Au final les performances ne sont pas trop critiques. Au pire je peux fais une Dll pour les routines critiques.

Avant d'acheter vStudio j'ai commencé par un système libre pour tester : Sharpdevelop. Est ce discriminant pour la suite ? ou pas. Je veux dire par là que les performances seront différentes avec ce système et risquent de ne pas me montrer les cotés intéressants du .NET par rapport a la distribution de Microsoft qui elle est optimisée dans tous les sens (enfin je suppose) ?

[tomlev]

Avant d'acheter vStudio j'ai commencé par un système libre pour tester : Sharpdevelop. Est ce discriminant pour la suite ? ou pas.

Si tu veux un IDE .NET gratuit, utilise Visual C# Express (ou Visual Basic Express si tu prèfères...), qui a un peu moins de fonctionnalités que la version pro mais est quand même un excellent outil.

Si tu veux absolument du libre, effectivement tu n'as pas trop le choix, tu peux effectivement utiliser SharpDevelop, mais à mon avis tu vas plus galérer qu'avec Visual. D'autant plus que SharpDevelop ne gère probablement pas les fonctionnalités les plus récentes, comme WPF, Linq ou Entity Framework.

Je veux dire par là que les performances seront différentes avec ce système et risquent de ne pas me montrer les cotés intéressants du .NET par rapport a la distribution de Microsoft qui elle est optimisée dans tous les sens (enfin je suppose) ?

En termes de performances, l'IDE que tu utilises ne change rien : SharpDevelop utilise le même compilateur que Visual Studio (fourni avec le SDK), et les programmes s'éxécutent avec le même runtime. SharpDevelop est seulement un environnement de développement, il ne remplace pas le .NET Framework.

[Pol63]

niveau déploiement, moi je trouve ca beaucoup mieux que vb6
vb6 aussi avait son runtime, que le setup généré installait

là il faut en effet le framework, mais tu peux faire un setup aussi ...

c'est surtout niveau mise à jour, avec .net, tu remplaces l'exe, ou meme une seule dll et ca repart
sous vb6 il fallait tout dé-registrer et tout re-registrer, sans parler qu'il fallait tout recompiler, car y avait des liens entre l'exe et telle version de la dll, alors qu'un exe .net, il voit une dll à coté de lui qui a le nom qu'il cherche, il va piocher dedans sans se poser de questions

nos clients, on leur installe des pc neufs, avec vista, on installe le framework et 2 ou 3 conneries, en plus ils sont reliés à internet donc on a pas de soucis
mais ca dépend de ta clientèle


pour ce qui est de tes problème de liaison série, normalement ca fonctionne bien, faudrait qu'on voit ton code pour trouver ce qui cloche ..;

[Sphax]

.NET est un environnement d'exécution managé. Le code est compilé en MSIL (Microsoft Intermediate Language, une sorte d'assembleur pour la machine virtuelle). Lors de la première exécution d'un code MSIL, le runtime le compile "à la volée" en code natif ; ensuite si le code MSIL n'a pas été modifié, c'est le code natif en cache qui est utilisé, si bien que les performances restent très correctes.

hello,

Je suis pas sûr de comprendre ça, tu veux dire que d'une exécution à une autre d'un exe .net l'IL n'est pas recompilé, mais qu'une précédente compilation est chargée? Ou bien que lors d'une même exécution, chaque méthode n'est compilée qu'une fois? Si c'est la première explication alors c'est la première fois que je la vois, es-tu bien sûr de ça? Si c'est la seconde on est d'accord .

[Pol63]

moi je voterais pour la recompilation à chaque fois
avec un simple stopwatch on voit que les temps de la première execution d'une sub de chaque execution de l'exe est longue

[tomlev]

Je suis pas sûr de comprendre ça, tu veux dire que d'une exécution à une autre d'un exe .net l'IL n'est pas recompilé, mais qu'une précédente compilation est chargée? Ou bien que lors d'une même exécution, chaque méthode n'est compilée qu'une fois? Si c'est la première explication alors c'est la première fois que je la vois, es-tu bien sûr de ça? Si c'est la seconde on est d'accord .

Jusqu'ici, il me semblait que c'est la première explication, mais tu m'as fait douter... en creusant un peu la question, je crois que c'est toi qui as raison

En fait, je confondais 2 choses :
- le compilateur JIT (Just-In-Time) qui est utilisé habituellement : la première fois qu'une méthode est appelée, elle est compilée en natif, et pendant la même exécution du programme ce code natif est réutilisé à chaque appel de la méthode. Mais ce code natif n'est pas conservé au-delà de l'exécution du programme.
- l'outil Ngen.exe (native image generator), qui compile en natif tout l'assembly, et stocke sur disque l'image native de l'assembly, qui est réutilisée à chaque exécution. Certains programmes (Paint.NET par exemple) exécutent Ngen.exe lors de l'installation, pour rendre l'exécution plus rapide.

http://msdn.microsoft.com/en-us/library/ht8ecch6.aspx

[buggen25]

Salut

*J'ai lu beaucoup de chose sur la toile et j'y perd mon latin. Le .NET est il managé ou compilé en code natif avant son exécution ? n'y perd on pas en rapidité d'exécution globale de l'application par rapport a un code compilé tel VC++6 ?

in n y a pas de concurrence entre les langages. C++, VB, C# c'est la meme chose a l'execution. c'est le Common Language Runtime si je m'en souviens bien CLR
Ensuite on peut installer des applicatif sur Unix/Linux sans aucun problème. ie le projet mono
http://www.mono-project.com
ocordialement

[tomlev]

Salut

in n y a pas de concurrence entre les langages. C++, VB, C# c'est la meme chose a l'execution. c'est le Common Language Runtime si je m'en souviens bien CLR
Ensuite on peut installer des applicatif sur Unix/Linux sans aucun problème. ie le projet mono
http://www.mono-project.com
ocordialement

C'est pas tout à fait pareil ... en C++ tu peux faire du code managé (exécuté par le CLR), ou du code natif.

[buggen25]

C'est pas tout à fait pareil ... en C++ tu peux faire du code managé (exécuté par le CLR), ou du code natif.

tout a fait d'accord ! Avec Win32? ou MFC ou faire du DotNet avec C++ natif?

[Bartholivier]

Merci pour ces informations. Je vais m'y mettre plus en avant.

Pour la distribution ca reste toujours un probleme. Enfin il faudra bien que ca rentre.

Pour mes clients, se sont principalement des établissements de l'éducation Nationale, donc souvent des systèmes vétustes (98 / Me (Arggg!!)/ XP/ NT2000) et dépourvus de connexion internet. Enfin c'est comme tout, il faudra qu'ils s'y mettent.

Pour la distribution, personnellement je n'utiliser plus le déploiement de VB6 depuis très longtemps, je préfère innosetup qui permet bien plus de souplesse. Mais ceci est un autre débat.

pour mon problème de liaison série, je vais créer un nouveau post afin de ne pas polluer celui ci.

Merci a tous pour ces réponses. Par contre pour en revenir a ces problèmes de vitesses d'exécution j'ai effectivement rencontré des différences de vitesses entre VB6 et VC++6 sur des calculs et des manipulations de tableaux. Ainsi que sur les fonctions graphiques du GDI. Des sites "d'initiation" a VB.NET évoquent certaines différences de vitesse avec VB6, et "diraient" que sur certains calculs récursifs, .NET serait plus lent. D'où mon interrogation sur cette lenteur. Du au framework ? le MIL ?

[Pol63]

pour le déploiement, on dit qu'il suffit que le framework soit installé sur la machine, mais ca peut etre plus compliqué que ca sur des vieilles machines
car si ton appli a besoin que le framework soit installé, le framework lui a aussi certains prérequis
deja sous windows xp, il arrive qu'il manque windows installer 3.1
mais sous 98 la liste des conneries à installer peut etre longue !


pour ce qui est des perfs, je pense que .net est plus rapide
il m'est arrivé de demander un tri multicolonne de 10000 lignes sur 15 colonnes dans un tableau en ram, ca prends entre 1 et 3s
et le tout avec 3 ou 4 lignes de codes. le gros avantage de .net, c'est qu'il y a plein de choses qui sont dejà codées
pour ce qui est des perfs graphiques, si tu n'utilises pas de transparence, il n'y a aucun soucis, sinon c'est lamentable