Dot.Blog

C#, XAML, Xamarin, WinUI/Android/iOS, MAUI

Powershell ou la ligne de commande objet sous .NET de Windows

Le shell de Windows nous renvoie aux temps préhistoriques où le PC avait un écran vert non graphique. Même les premières versions de Windows se lançaient aussi en ligne de commande. On ne parlait d'ailleurs pas de logiciels en "mode console" puisque c'était le mode normal... Le fameux DOS.

Avec les versions modernes de Windows est venu un autre temps, celui où Windows est devenu le DOS et où la ligne de commande n'est plus qu'une console qu'on appelle parfois et qui, une fois fermée, retourne à Windows, qu'on n'a pas quitté d'ailleurs... Inversion de tendance, mais le côté "rugueux", voire ésotérique de la console est resté.

Bien que le shell soit avec le temps devenu capable de faire des choses plus intelligentes il n'a finalement que peu évolué depuis MS-DOS.

Mais voici PowerShell !

PowerShell n'est pas un utilitaire freeware mais bien une extension Windows produite par Microsoft. Il s'agit de proposer une console (un shell) totalement objet fonctionnant sous .NET. Les commandes ne retournent plus des réponses textuelles mais des listes d'objets.

Certes, quand on tape un "dir" on obtient, grosso-modo, le même type d'affichage qu'avant. Mais cela est fort trompeur ! En réalité le "dir" (comme les autres commandes) retourne une liste d'objets dont on peut obtenir les méthodes, les propriétés. On peut aussi exécuter les méthodes de ces objets, remettre en forme la liste et bien d'autres choses encore !

Un exemple simple en quelques étapes :

  • obtenir la liste des services tournant sur la machine: get-service
  • obtenir cette liste et obtenir la classe des objets retournés ainsi que les membres de cette classe : get-service | get-member
  • obtenir le service de planification des tâches et savoir s'il peut être arrêté : (get-service schedule).CanStop
  • obtenir le service de planification des tâches et l'arrêter : (get-service schedule).stop()

etc...

Comme on le voit ici le "pipe" fonctionne toujours mais il sait passer les objets d'une commande à l'autre. On voit aussi qu'on peut obtenir un objet en particulier et invoquer ses méthodes ou accéder en lecture et en écriture à ses propriétés.

Le PowerShell c'est encore bien d'autres choses, des boucles ForEach par exemple, des Cmdlet (prononcer Command-let) des petites commandes toutes prêtes ou des alias permettant d'écrire moins de code. C'est aussi des scripts bien entendu ou l'accès à tous les drives de la machines même ceux plus abstraits comme Env (l'environnement) ou HKCU (la registry, clé du current user) dans laquelle on peut naviguer comme dans tout drive. Etc.

Le mieux c'est de voir par vous-même n'est-ce pas ? ... En téléchargeant cet outil sur la page du PowerShell Microsoft.

Bon shell

.. et Stay Tuned !

LINQ to {tapez ce que vous voulez ici}. Des providers à foison !

Vous connaissez LINQ to Object, LINQ to Dataset, LINQ to XML, etc... Microsoft livre déjà une large palette de fournisseurs de données (providers) pour LINQ. Dans sa grande sagesse Microsoft a aussi publié les spécifications (et des exemples) permettant à tous de développer des fournisseurs de données pouvant fonctionner avec LINQ. Cette ouverture extraordinaire permet d'interroger avec LINQ des données de toute sorte sans avoir besoin de les transformer au préalable.

Mais savez-vous qu'à ce jour il existe déjà plus d'une trentaine de providers LINQ ? Et que forcément certains vous rendrons des services inestimables, à condition d'en connaître l'existence... Vous pouvez même écrire vos propres providers LINQ ! Je vous conseille d'ailleurs cette page du Wayward blog qui propose une série de billets expliquant comment créer un tel provider.

Un exemple parmi tant d'autres pour illustrer le propos : LINQ To Amazon. Il permet tout simplement d'interroger directement Amazon pour sélectionner des livres selon autant de critères que nécessaire, et sans autre programmation qu'une requête LINQ. Fantastique non ? Un petit exemple pour concrétiser la chose :

var query =
  from book in new Amazon.BookSearch()
  where
    book.Title.Contains("ajax") &&
    (book.Publisher == "Manning") &&
    (book.Price <= 25) &&
    (book.Condition == BookCondition.New)
  select book;

 

Cool non ? LINQ to Amazon est présenté dans le livre LINQ in Action (que je vous conseille au passage) et vous pouvez accéder au blog de Fabrice qui le présente.

Mais cela n'est qu'un exemple, et il existe bien d'autres fournisseurs de données LINQ, en voici une liste (avec liens - shift clic pour les ouvrir dans une nouvelle fenêtre) :

Charlie Calvert, que les delphistes connaissent bien, et qui comme bon nombre des meilleurs a depuis longtemps choisi la voie .NET avec Microsoft, met à jour régulièrement cette liste qui est issue de son blog. Si vous lisez l'anglais, bookmarquez la page Links to LINQ de son blog qui, en plus de la liste des providers, fournit de nombreux liens en rapport avec cette technologie.

Conclusion

LINQ est une technologie fantastique dont je ne cesse de dire du bien (et d'utiliser avec bonheur dans la totalité des applications que j'écris), je ne peux imaginer utiliser demain ou dans 10 ans un langage qui n'implémentera pas une feature de même type. LINQ to "n'importe quoi" est la preuve que cette technologie est en plus ouverte et que seule notre imagination est la limite. Borland utilisait le slogan "the sky is the limit" durant ses grandes années de gloire. Microsoft ne le dit pas, mais la firme de Redmond rend ce rêve possible aujourd'hui...

 

Astuce du jour : déboguer du code sans écrire de code de test

Il arrive souvent (ou il devrait souvent arriver...) qu'on veuille tester rapidement du code. Par exemple vérifier qu'une méthode retourne bien le bon résultat selon deux ou trois variantes des paramètres d'entrée. Mais écrire du code de test à chaque fois, même si "on devrait" le faire tout le temps, n'est pas totalement conforme à la réalité. On a plus souvent la pression que la bride sur le collier et cela impose de travailler bien, mais vite ! Plus...

Un outil gratuit pour tester les requêtes LINQ

Qu'il s'agisse de LINQ to Object ou LINQ to SQL il serait bien agréable de pouvoir disposer d'une sorte de bloc-note pour tester ou mettre au point des requêtes, voire pour s'entraîner tout simplement. Pouvoir gérer les connexions aux bases de données, éventuellement envoyer et tester du SQL "de base" sur celles-ci serait la cerise sur la gâteau. Et bien cet outil existe, et en plus il est gratuit !

 

LINQPad, puisque c'est de lui qu'il s'agit, n'est pas vraiment une nouveauté absolue mais il y a fort à parier que nombre d'entre vous n'en ont jamais entendu parlé.

Cet outil a été développé conjointement à l'excellent ouvrage "C# 3.0 in a nutshell" de Joseph Albahari, un australien, qui par la diffusion gratuite de LINQPad tente une promo plutôt positive de son livre et de ses services de consulting (si on habite au pays des kangourous, of course).

J'aime personnellement cette idée de "pub positive" qui consiste à offrir de son temps et de son travail pour faire sa pub plutôt que de gaver les gens de bandeaux agaçants. C'est de la pub dans un esprit totalement anti-google (de la pub pour de la pub, partout, sans rien apporter à ceux qui la subissent), et il faut encourager ceux qui adoptent cette façon respectueuse de faire leur promotion. Achetez le livre de Joseph ! Fin de la paranthèse :-)

LINQPad est ainsi un super utilitaire. Il interprète du code C# ou VB et les requêtes LINQ to Object ou LINQ to SQL. Il autorise la connexion à des bases de données, offre un éditeur purement SQL en supplément, bien pratique, et il permet même d'ajouter ses propres DLL et ses propres espaces de noms pour qu'ils soient reconnus dans le code C# qu'on tape !

On peut dès lors utiliser LINQPad pour requêter des objets métiers complexes, un framework maison, un modèle LINQ to SQL, etc.. Il suffit d'ajouter les références.

Pour terminer, LINQPad est fourni avec de nombreux exemples qui sont autant de moyens de tester ses connaissances et d'apprendre les subtilités de LINQ. Utilisé conjointement à ma version des "101 exemples LINQ" de Microsoft, LINQPad devient un fantastique outil d'auto-formation.

Pour télécharger le produit et avoir accès aussi aux forums, aux vidéos de démo, et plein d'autres choses, aller sur la page de LINQPad !

Bon Dev...

Et Stay Tuned !

 

Simplifier les gestionnaires d'événement grâce aux expressions Lambda

Les expressions Lambda ont été introduites dans C# 3.0. Utilisées correctement, tout comme LINQ to Object, elles permettent une grande simplification du code entraînant dans un cercle vertueux une meilleure lisibilité de ce dernier favorisant maintenabilité et fiabilité de ce même code. Il n'y a donc aucune raison de rester "frileux" vis à vis de cette nouveauté syntaxique comme encore trop de développeurs que je rencontre dans mes formations ou ailleurs.

Pour démontrer cette souplesse, voici un petit exemple qui valide un document XML en fonction d'un schéma.

La méthode Validate() de la classe XDocument attend en paramètre un delegate de type ValidationEventHandler. Dans un code très court il n'est pas forcément judicieux de déclarer une méthode juste pour passer son nom en paramètre à Validate(). Les "sous procédures" ou procédures imbriquées de Pascal n'existent pas en C# et l'obligation de déclarer à chaque fois des méthodes private pour décomposer la moindre action est une lourdeur syntaxique de ce langage dont on aimerait se passer parfois (une méthode même private est visible par toutes les autres méthodes de la classe ce qui n'est pas toujours souhaitable. Seules les méthodes imbriquées de Pascal sont des "méthodes privées de méthodes").

En fin de billet vous trouverez d'ailleurs le lien vers un autre billet dans lequel j'explique comment utiliser les expressions Lambda en les nommant pour retrouver la souplesse des procédures imbriquées. Même si "l'astuce" présentée ici peut y ressembler dans l'esprit, dans la pratique les choses sont assez différentes puisque nous n'utiliserons pas une expression nommée.

Revenons à l'exemple, il s'agit de valider un document XML à partir d'un schéma. Et de le faire de la façon la plus simple possible, c'est à dire en évitant l'écriture d'un delegate, donc en utilisant directement une expression Lambda en paramètre de Validate().

Supposons que nous ayons déjà le schéma (variable schema) et le document XML (variable doc), l'appel à Validate pourra donc s'écrire :

doc.Validate(schema,(obj, e) => errors += e.Message + Environment.NewLine);

"errors" est déclarée comme une chaîne de caractères. A chaque éventuelle erreur détectée par la validation l'expression concatène le message d'erreur à cette dernière. En fin de validation il suffit d'afficher errors pour avoir la liste des erreurs. Mais cela n'est qu'un exemple d'utilisation de l'expression Lambda. Ce qui compte c'est bien entendu de comprendre l'utilisation de cette dernière en place et lieu d'un delegate de tout type, ici ValidationEventHandler d'où les paramètres (obj,e) puisque ce delegate est déclaré de cette façon (un objet et un argument spécifique à cet handler).

C'est simple, nul besoin de déclarer un gestionnaire d'événement donc une méthode avec un nom et une visibilité. On évite que cette méthode soit réutilisée dans le code de la classe considérée (si elle existe on est tenté de la réutiliser mais sa stratégie d'écriture n'est pas forcément adaptée à une telle utilisation d'où possible bug), etc. Que des avantages donc.

Pour plus d'information vous pouvez lire mon article sur les nouveautés syntaxiques de C# 3.0 ainsi que mon billet montrant comment retrouver en C# le bénéfice des procédures imbriquées de Pascal grâce aux expressions Lambda.

Si vous voulez jouez avec l'exemple, vous pouvez télécharger le projet VS 2008 qui montre tout cela : lambda.zip (21,71 kb)

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 !

UPDATE : Non en fait comme tous les autres ce sont des xxxxxx (mettez ce que vous voulez qui ne soit pas très flatteur), ils achètent un produit gratuit, puis ils le laissent gratuit un certain temps pour bien enregistrer votre mail et pouvoir vous envoyer de la pub et quand le plein est fait ça devient payant. Ce genre d'approche qui prend le client pour un crétin me donne la gerbe. A fuir donc. D'autres outils font le même boulot aujourd'hui. Tant pis j'ai bien aimé le travail de Roeder, mais je n'aime pas la récup commerciale de RedGate pour placer en payant ce qui était gratuit (et pas développé par eux donc 0 R&D à rentabiliser), c'est déloyal et ça ne me donne pas envie d'acheter ! Je vous conseille de voir ailleurs. Quitte à payer, il y a bien maintenant.