Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

How Do I ? - Les vidéos Microsoft pour bien se lancer / complément

Pour ceux qui lisent ce blog par flux RSS (et ils sont très nombreux) il a de fortes chances pour que vous ne puissiez voir l'edit que j'ai fait du billet précédent "How Do I ? - Les vidéos Microsoft pour bien se lancer". J'ai fait une mise à jour des liens concernant les vidéos de la série "How Do I". Donc si cela vous intéresse, rafraichissez le message si votre lecteur de flux le permet, sinon tapez sur le lien en début de paragraphe pour ouvrir la dernière version du billet dans votre brower...

How Do I ? - Les vidéos Microsoft pour bien se lancer

Dans la jungle épaisse de MSDN on trouve des milliers de choses passionnantes, souvent par hasard car par définition une jungle est inextricable et MSDN n'échappe pas à la règle... Il est d'ailleurs parfois plus rapide et plus sûr de chercher une info dans Google pour trouver le lien dans MSDN que de chercher directement dans ce dernier ! Et pourtant... Cette jungle cache de nombreux trésors qui ne s'offrent qu'aux intrépides aventuriers osant s'enfoncer dans la moiteur tiède de l'information, sautant de lien-lianne en lien tel un Tarzan numérique...

Bon trève de plaisanterie, j'en reviens à l'essentiel : "Comment je fais ?".

Comment je fais "quoi" ? Allez-vous rétorquer. Tout. Plein de choses. Par exemple, Comment j'utilise l'Entity Framework, Comment je commence avec ADO.NET Data Service, Comment j'utilise le control LinqDataSource, Comment j'utilise le DataSet en multi-tiers ? Etc, etc.

Pour toutes ces questions il existe en réponse une vidéo, claire, expliquant par l'image et la parole ce qu'il faut savoir.

Bien entendu tout cela est en anglais et en concernera donc que les lecteurs capables de suivre une démo dans cette langue sans en perdre les trois quarts.

Si vous faites partie des heureux anglophones à qui ce genre de média ne fait pas peur, rendez vous sur la page des "How Do I?"...

[EDIT]
Le lien que je donne concerne les "How Do I" des données. Sylvain dans son commentaire à ce billet donne un autre lien concernant la série "How Do I" pour ASP.NET.
En fouillant sur MSDN on peut aussi trouver une série pour le "Native Coding" (C++ Win32), une autre pour Visual Studio, ou pour les Devices (Compact Framework), ou encore Office et les XML API, etc.

Toutes les séries "How Do I" ne sont pas forcément dotées de vidéos, en revanche, à la page suivante vous trouverez la liste de toutes les vidéos "How Do I" quel que soit le sujet abordé (à ce jour : ASP.NET, Ajax, Devices, Native Coding, Security, Silverlight, VB, VS, VS tools for Office, VSTS, Windows Forms, WPF).
[/EDIT]

 

Bonne vidéos

et Stay Tuned !

La guerre des clones n'aura pas lieu ! ... Si vous possédez Clone Detective !

Clone Detective pour Visual Studio est un outil de debug un peu particulier puisqu'il ne cherche pas les bugs mais les redondances de code.

La redondance de code est un ennemi sournois... Le code dupliqué est bien souvent la porte ouverte aux inconsistances et aux regressions lors de mises à jour correctives ou évolutives. En effet, si un bug apparaît un jour dans une séquence mais qu'il n'a pas encore été repéré dans une autre fonction qui utilise pourtant un code similaire, la mise à jour ne concernera que la séquence incriminée. Un jour où l'autre la partie codée de façon similaire plantera aussi pour les mêmes raisons. Elle ne sera d'ailleurs peut être pas corrigée de la même façon ni par la même personne... Inconsistance. Coûts de maintenance inutiles. Les défauts de la redondance de code ne manque donc pas.

D'ailleurs un outil capable de retrouver ces fameux clones est un excellent assistant pour un auditeur... La présence des clones trahit non pas celle de Palpatine ou du comte Doku mais bien d'un code for mal refactoré, donc pauvre et qui laissera par force voir d'autres faiblesses !

Précisons que Clone Detective cherche les "clones", pas seulement le code purement redondant de type copier/coller. Il analyse le code en supprimant les commentaires, les espaces, les noms de variables etc, afin d'obtenir un code de référence le plus générique possible avant d'y chercher les clones. Les clones formes des classes de code équivalent, l'un pourrait remplacer l'autre sans problème, à la présentation et aux noms de variables près.

Il s'agit donc bien d'une recherche intelligente et non simplement d'une recherche de "doublons". Mais la lecture de la documentation de CD vous en dira bien plus que ces quelques lignes.

Donc pour se prémunir des dommages causés par les clones, et si on ne connait pas le numéro de portable de Yoda, le mieux est encore de télécharger Clone Detective. Bonne nouvelle il n'habite pas une galaxie lointaire, il est sur CodePlex et donc gratuit avec le code source pour les curieux ! Mieux, C.D. s'insère dans VS 2008 (voir / autres fenêtres, pour afficher celles de C.D. une fois installé). Vraiment un bel add-in dont il serait bête de se priver !

Pour accéder à la page de chargement, cliquez simplement sur le logo de Clone Detective inséré plus haut dans le corps de ce billet.

Que la force soit avec vous !

(et Stay Tuned !)

Les différentes versions du framework .NET

Depuis sa naissance le framework a bien évolué ! La compatibilité ascendante a toujours été respectée et preuve en est aujourd'hui que le "side-by-side execution" de .NET fonctionne bien puisque toutes les versions peuvent coexister sur la même machine et que de nombreux logiciels les utilisant peuvent tourner ensemble sans aucun mélange, loin du "Dll Hell" de Win32.

Le pari est donc tenu et en général on ne se soucie de la version du framework que pour savoir si on désire supporter telle ou telle nouvelle fonctionnalité mais jamais pour éviter des "incompatibilités" (quel vilain mot ! :-) ).

Toutefois il est parfois important de respecter une implémentation particulière et donc de savoir où trouver le setup correspondant. Au-delà de ces contingences techniques il est intéressant de connaître les diverses versions qui (co)existent et qu'on peut trouver chez les utilisateurs. Un petit récapitulatif n'est donc pas forcément de trop...

Les différentes versions

Les différentes versions du Framework .NET à ce jour
VersionTypen° versionDate 
.NET Framework 1.0
1.0  RTM 1.0.3705.0  02/01/2002
1.0 SP1  Service Pack 1.0.3705.209 19/03/2002 
1.0 SP2  Service Pack  1.0.3705.288  07/08/2002 
1.0 SP3  Service Pack  1.0.3705.6018  31/08/2004
.NET Framework 1.1
1.1 RTM 1.1.4322.573 01/04/2003
1.1 SP1 Service Pack 1.1.4322.2032 30/08/2004 
1.1 incluse avec Win2003 SP1  Win2k3  1.1.4322.2300  30/05/2005 
.NET Framework 2.0
2.0  RTM  2.0.50727.42 07/11/2005 
2.0 Vista  RTM  2.0.50727.312  30/01/2007 
2.0 SP1  Service Pack  2.0.50727.1433   19/11/2007 
MS07-040  Security Patch 2.0.50727.832    

2.0 SP2 
La SP2 n'est pas distribuée seule
Elle est incluse dans .NET 3.5 SP1

Service Pack 2.0.50727.2407   
.NET Framework 3.0 
3.0  RTM 3.0.4506.30 06/11/2006 
3.0 Vista  RTM 3.0.4506.26  30/01/2007
3.0 SP1  Service Pack  3.1.21022  19/11/2007
.NET Framework 3.5 
3.5  RTM 3.5.21022.08 09/11/2007 
3.5 SP1 Service Pack 3.5.30729.1 11/08/2008

Le tableau ci-dessus n'intègre pas toutes les versions beta qui, par essence, ne sont pas installées en production. En revanche, en cliquant sur les liens vous accéderez directement à la page de téléchargement de la version concernée.

Savoir quelles versions sont installées

Cela est tout bête, mais disposer d'un joli tableau des versions est une chose, mais comment savoir quelles versions sont installées sur une machine ?

C'est une bonne question et j'attendais que vous me la posiez ! :-)

La version simple : ouvrez une commande (menu démarrer, exécuter puis tapez "cmd"), puis tapez la ligne suivante :

cd %systemroot%\Microsoft.NET\Framework

Tapez ensuite la commande "dir" et regardez la liste des répertoires... Chaque version est installée dans le sien propre dont le nom est tout simplement le numéro de la version précédé de la lettre "v", "v2.0.50727" par exemple.

La version plus complète : utilisez l'explorateur de fichiers, tapez dans la barre d'adresse  %systemroot%\Microsoft.NET\Framework, entrez dans l'un des répertoires en question et localisez le fichier Mscorlib.dll. Clic droit puis Propriétés, et dans l'onglet Version vous obtiendrez le numéro de version complet de l'installation du framework considérée.

Il faut préciser que vous obtiendrez peut-être des numéros de version qui ne sont pas dans le tableau de ce billet, comme je l'ai précisé je n'ai pas pris en compte les beta ni les hotfixes éventuels. Par exemple, sur ma machine pour le répetoire "v2.0.50727", le fichier Mscorlib.dll me donne 2.0.50727.3053 qui est vraisemblablement la version du SP2 de .NET 2.0 installée par .NET 3.5 SP1.

Pour conclure

Bientôt 7 ans, l'âge de raison si on en croit la sagesse populaire... l'âge où l'on perd ses dents. Je ne sais pas si la métaphore peut s'appliquer jusqu'à ce point, j'ai un doute... Il faut au contraire admettre que le framework commence a avoir une machoire bien gardie ! Et quand on sait tout ce qui est à venir, comme les extensions parallèles (PFX) et bien d'autres choses, on se dit qu'on a bien eu raison de s'y prendre dès le départ, car l'ère .NET ne fait que commencer...

Bon Dev et .. Stay Tuned !

Mondes Parallèles [Webcasts sur le parallélisme + article ]

Comme je vous en parlais dans mon billet "La bombe Parallèle ! PLINQ, et PCP Parallel Computing Platform", Microsoft prépare une série d'extensions à .NET pour le calcul parallèle, dont PLINQ la version parallèle de LINQ. Il y a quelques mois, Keith Yedlin and Steve Teixeira du PCP (Parallel Computing Platform) sont venus en France pour présenter les extensions parallèles. A cette occasion des Webcasts ont été enregistrés et ils sont aujourd'hui disponibles en ligne.

Ces Webcasts portent des titres français mais leur contenu est en anglais. Il existe toutefois un article en français écrit par Eric Vernié que je vous conseille : Introduction aux extensions Parallèles à .NET (PFX).

La liste des webcasts :

Programmation impérative avec F#, parallèlisme avec PFX, Microsoft développe en ce moment de nombreuses technologies qui deviendront de plus en plus incontournables dans l'avenir, autant se tenir informé !

Bon webcasts et Stay Tuned !

Le réflecteur change de miroir...

Un peu message de la BBC durant la dernière guerre le titre de ce billet non ? Je parle de l'excellent outil "Reflector" qu'il faudra désormais télécharger depuis un autre site...

En effet, Reflector de Lutz Roeder a changé de main. Les cairotes sont cuites comme dirait une amie égyptienne ? Est-ce la fin de cet outil que tout développeur .NET possède dans sa trousse ? Seul l'avenir le dira. Pour l'instant, RedGate, la société ayant fait l'acquisition du logiciel le propose toujours en téléchargement gratuit et ne semble pas vouloir changer cette stratégie. Qui vivra verra... En tout cas notez la nouvelle adresse de Reflector : http://www.red-gate.com/products/reflector/index.htm

Bon dev et Stay Tuned !

Déboguer plusieurs projets simultanément sous VS 2008

Lorsqu'on travaille sur une solution comportant plusieurs projets il s'avère souvent utile de pouvoir lancer plusieurs projets en même temps, par exemple s'ils communiquent ensemble ou bien si les résultats de l'un peuvent influencer ceux de l'autre.
Il est certes toujours possible de lancer "à la main" depuis l'explorateur les projets "de fond" puis de lancer en mode debug le projet à déboguer. Mais cela n'est ni pratique ni totalement satisfaisant, en cas de bug dans l'un des projets "secondaires", aucun moyen de savoir ce qu'il se passe.

Il existe pourtant une solution simple...

Voici comment procéder :

  1. Clic droit dans l'explorateur de solution, sur la solution.
  2. Choisir Propriétés
  3. Aller à la page "startup project page" (désolé j'ai un VS en US. Mais c'est la 1ere page du dialogue normalement)

Vous allez voir trois boutons radio :

  • Current Selection (sélection courante)
  • Single startup projet (mode habituel, 1 seul projet lancé au debug)
  • Multiple startup projects (mode multi projets)

Pour chaque projet de la solution, une fois le mode multi projets activé, vous pouvez choisir ce que VS doit faire lorsque le debug est lancé (F5). Un projet peut ne pas être exécuté (par défaut), démarré ou démarré sans debug. La figure ci-dessous montre ces diverses options.

 

Une fois le dialogue validé, en tapant F5 tous les projets sélectionnés sont exécutés dans le mode que vous avez choisi... Les projets démarrés en mode debug peuvent tous être inspecté, avoir des points d'arrêts, etc.

C'est pas fantastique ça ?

Alors pour d'autres nouvelles, Stay Tuned !

Le Mythe du StringBuilder

Sur l'excellent blog du non moins excellent Mitsu, dans l'une de mes interventions sur l'un de ses (excellents aussi) petits quizz LINQ, j'aurai parlé du "Mythe du StringBuilder". Cela semble avoir choqué certains lecteurs qui m'en ont fait part directement. Le sujet est très intéressant et loin de toute polémique j'en profiterais donc ici pour préciser le fond de cet avis sur le StringBuilder et aussi corriger ce qui semble être une erreur de lecture (trop rapide?) de la part de ces lecteurs. J'ai même reçu un petit topo sur les avantages de StringBuilder (un bench intéressant par ailleurs).

D'abord, plantons le décor

Le billet de Mitsu dans lequel je suis intervenu se trouve ici. Dans cet échange nous parlions en fait de la gestion des Exceptions que l'un des intervenants disait ne pas apprécier en raison de leur impact négatif en terme de performance. Et c'est là que j'ai répondu :

"...Dans la réalité je n'ai jamais vu une application (java, delphi ou C#) "ramer" à cause d'une gestion d'exception, c'est un mythe à mon sens du même ordre que celui qui veut que sous .NET il faut systématiquement utiliser un StringBuilder pour faire une concaténation de chaînes."

Comme on le voit ici, seule une lecture un peu trop rapide a pu faire croire à certains lecteurs que je taxe les bénéfices du StringBuilder de "mythe". Je pensais que la phrase était assez claire et qu'il était évident que si mythe il y a, c'est dans le bénéfice systématique du StringBuilder... Nuance. Grosse nuance.

Mythe ou pas ?

La gestion des exceptions est un outil fantastique "légèrement" plus sophistiqué que le "ON ERROR GOTO" de mon premier Basic Microsoft interprété sous CP/M il y a bien longtemps, mais le principe est le même. Et si en 25 ans d'évolution, la sélection darwinienne a conservé le principe malgré le bond technologique c'est que c'est utile...

Est-ce coûteux ?

Je répondrais que la question n'a pas de sens... Car quel est le référenciel ?

Les développeurs ont toujours tendance à se focaliser sur le code, voire à s'enfermer dans les comparaisons en millisecondes et en octets oubliant que leur code s'exprime dans un ensemble plus vaste qui est une application complète et que celle-ci, pour être professionnelle a des impératifs très éloignés de ce genre de débat très techniques. Notamment, une application professionnelle se doit avant tout de répondre à 3 critères : Répondre au cachier des charges, avoir un code lisible, être maintenable. De fait, si les performances ne doivent pas être négligées pour autant, le "coût" d'une syntaxe, de l'emploi d'un code ou d'un autre, doit être "pesé" à l'aulne d'un ensemble de critères où celui de la pure performance ne joue qu'un rôle accessoire dans la grande majorité des applications. Non pas que les performances ne comptent pas, mais plutôt que face à certaines "optimisations" plus ou moins obscures, on préfèrera toujours un code moins optimisé s'il est plus maintenable et plus lisible.

Dès lors, le "coût" de l'utilisation des exceptions doit être évalué au regard de l'ensemble de ces critères où les millisecondes ne sont pas l'argument essentiel.

De la bonne mesure

Tout est affaire de bonne mesure dans la vie et cela reste vrai en informatique.

Si une portion de code effectue une boucle de plusieurs milliers de passages, et si ce traitement doit absolument être optimisé à la milliseconde près, alors, en effet, il sera préférable d'éviter une gestion d'exception au profit d'un ou deux tests supplémentaires (tester une valeur à zéro avant de s'en servir pour diviser au lieu de mettre la division dans un bloc Try/Catch par exemple).

Mais comme on le voit ici, il y plusieurs "si" à tout cela. Et comment juger dans l'absolu si on se trouve dans le "bon cas" ou le "mauvais cas" ? Loin de la zone frontière, aux extrèmes, il est toujours facile de décider : une boucle de dix millions de passages avec une division ira plus vite avec un test sur le diviseur qu'avec un Try/Catch (si l'exception est souvent lancée, encore un gros "si" !). De même, un Try/Catch pontuel sur un chargement de document sur lequel l'utilisateur va ensuite travailler de longues minutes n'aura absolument aucun impact sur les performances globales du logiciel.

Mais lorsqu'on approche de la "frontière", c'est là que commence la polémique, chacun pouvant argumenter en se plaçant du point de vue performance ou du point de vue qualité globale du logiciel. Et souvent chacun aura raison sans arriver à le faire admettre à l'autre, bien entendu (un informaticien ne change pas d'avis comme ça :-) ) !

Où est alors la "bonne mesure" ? ... La meilleure mesure dans l'existence c'est vous et votre intelligence. Votre libre arbitre. Il n'y a donc aucun "dogme" qui puisse tenir ni aucune "pensée unique" à laquelle vous devez vous plier. A vous de juger, selon chaque cas particulier si une gestion d'exception est "coûteuse" ou non. N'écoutez pas ceux qui voudraient que vous en mettiez partout, mais n'écoutez pas non plus ceux qui les diabolisent !

Et le StringBuilder dans tout ça ?

Si dans mon intervention sur le blog de Mitsu j'associais gestion des exceptions et StringBuilder c'est parce qu'on peut en dire exactement les mêmes choses !

Dans les cas extrêmes de grosses boucles il est fort simple de voir que le StringBuilder est bien plus performant qu'une concaténation de chaînes avec "+". Cela ne se discute même pas.

Mais, comme pour la gestion des exceptions, c'est lorsqu'on arrive aux "frontières" que la polémique pointe son nez. Pour concaténer quelques chaînes le "+" est toujours une solution acceptable car le StringBuilder a un coût, celui de son instanciation et du code qu'il faut écrire pour le gérer. Il s'agit là des cas les plus fréquents. On concatène bien plus souvent quelques chaines de caractères dans un soft qu'on écrit des boucles pour en concaténer 1 million le tout dans un traitement time critical... (encore des tas de "si" !).

Même du point de vue de la mémoire les choses ne sont pas si simple. Le StringBuilder utilise un buffer qu'il double quand sa capacité est dépassée. Dans certains cas courants (petites boucles dans lesquelles il y a quelques concaténation), le stress mémoire infligé par le StringBuilder peut être très supérieur à celui de l'utilisation de "+" ou de String.Concat.

C'est dans ces cas les plus fréquents que l'utilisation du StringBuilder comme panacée apparaît n'être qu'un mythe.

Conclusion 

Vous et moi écrivons du code, ce code se destine à un client / utilisateur. La première exigence de ce dernier est que le logiciel réponde au cahier des charges et qu'il fonctionne sans bug gênant. Cela impose de votre côté que vous utilisiez une "stylistique" rendant le code lisible et facilement maintenable car un code sans bug n'existe pas et qu'il faudra tôt ou tard intervenir ici ou là. Dans un tel contexte réaliste, ce ne sont pas les millisecondes qui comptent ni les octets, mais bien la qualité globale de l'application. Et c'est alors que les dogmes techniques tombent. Car ils n'ont d'existence que dans un idéal purement technique qui fait abstraction de la réalité. Un Try/Catch ou un StringBuilder ne peuvent pas être étudiés en tant que tels en oubliant les conditions plus vastes de l'application où ils apparaissent. Leur impact n'a de sens que compris comme l'une des milliers d'autres lignes de code d'une application qui doit répondre à un autre critère, celui de la qualité et de la maintenabilité.

Un seul juge existe pour trancher car chaque cas est particulier : vous.

Pour ceux qui veulent jouer un peu avec les StringBuilder, voici un mini projet que vous n'aurez qu'à modifier pour changer les conditions de tests : ConsoleApplication2.zip (6,10 kb)

Deboguer avec le code source de .NET sous VS 2008 !

Comme vous le savez peut-être, Microsoft a décidé d'ouvrir le code source de .NET, au moins en partie, pour aider les développeurs à mieux comprendre la plateforme mais aussi pour permettre un débogage en profondeur des applications.

La chose se sait (et encore, beaucoup semblent l'ignorer) mais fort peu de développeurs utilisent cette possibilité. Certainement faute de savoir comment trouver ce fameux code source et comment configurer VS 2008 pour y accéder automatiquement.

Il existe pourtant un site pour la "Share source initiative" (l'initiative de partage de source), site sur lequel vous trouverez toutes les explications pour configurer VS 2008 et télécharger le code source de .NET. Le lien suivant pointe la page d'explication pour configurer VS.

Pouvoir lire le code des classes qu'on utilise tous les jours (comme string par exemple), pouvoir déboguer en descendant au niveau d'un WriteLine et passer sa souris sur une valeur pour la vérifier, tout cela confère un avantage certain et, au bout du compte, une meilleure maîtrise du framework. Ne vous privez pas de ce privilège de pouvoir regarder derrière le rideau de scène et d'avoir accès au backstage comme un VIP !

Bon Debug !

pptPlex : rendre ses slides plus vivants un peu comme avec DeepZoom !

DeepZoom, vous connaissez ? non ? C'est ce fabuleux système de composition d'images qui permet de zoomer presque à l'infini dans une image géante (lire mon billet sur DeepZoom pour plus d'infos). Cette fonctionnalité est conçue pour le Web et n'a rien à voir avec Office PowerPoint bien entendu, c'est de l'effet visuel dont je parle ici. Et il est possible de retrouver dans l'esprit le même genre de chose pour une présentation PowerPoint !

Au début, dit comme ça, on ne voit pas tout de suite l'intérêt, mais une fois les petites vidéos de présentationo visionnées, on en comprend tout l'intérêt qui permet d'ajouter une valeur pédagogique non négligeabe à un slide : vue d'ensemble, zoom automatique sur une diapo, zoom dans une diapo sur un graphique, une capture écran un peu petite à lire sinon, retour au plan général, ruban permettant d'organiser le flot des diapo afin que la vu d'ensemble se rapproche de celle du processus évoqué, etc.

Il s'agit d'une production Microsoft Office Labs, accédez à la page de pptPlex, visionnez les vidéos et téléchargez l'add-in depuis ce site...

Bon slides !

Et Stay Tuned !