Dot.Blog

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

Open XML SDK et PowerTools pour OOXML - Manipuler les documents OOXML

Le format Open XML utilisé par Microsoft pour sa suite Office est une grande avancée en ce sens que le stockage n'est plus propriétaire et que cela permet d'envisager de nombreux traitements automatiques des documents qu'il s'agisse de recherche documentaire, de modification ou même de création de nouveaux documents.

Le format en lui même est aujourd'hui normalisé ISO/IEC et même si on peut regretter la guerre des formats entre Open XML de Microsoft et OpenDocument, il va falloir apprendre à jongler avec ces deux normes ouvertes, aucune n'étant plus "sympathique" ou "meilleure", et chacune affichant ses petites différences. Quoi qu'il en soit, dans les faits la masse de documents produite par la suite Office dans le monde est tellement gigantesque qu'au final le développpeur aura forcément plus souvent affaire à de l'Open XML qu'à du OpenDocument.

Il faut donc saluer Microsoft d'avoir opté pour un nouveau format lisible, public et normalisé. Pour nous, informaticiens, c'est la seule chose qui compte. Laissons les querelles de format à ceux qui ont du temps à perdre...

Open XML SDK 

Même si OOXML est une norme claire, les documents la décrivant sont, comme toute norme, un peu imbuvables, avouons-le... Mais bien heureusement il existe un SDK gratuit "Open XML SDK" qui se compose d'aide et d'une librairie de classes .NET facilitant la manipulation des fichiers de type Word, Excel, PowerPoint...

Vous pouvez télécharger le OOXML SDK en cliquant sur le lien.

Une fois cet assemblage référencé, vos applications peuvent facilement traiter tout document Office.

A titre d'exemple vous trouverez un petit projet console qui permet de lister le contenu d'un fichier OOXML (Word, Excel, PowerPoint). J'ai supprimé du projet les fichiers de test, il vous suffira de modifier le code de la méthode Main pour y placer le chemin d'un fichier OOXML se trouvant sur votre machine (ou une copie si vous être méfiant ! ).

Voici un exemple de sortie sur un fichier Excel très simple :

URI                        Content Type
===                        ============
/xl/workbook.xml           application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml
/xl/worksheets/sheet.xml   application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml
 

Ce n'est qu'une sorte de "hello world", le SDK permettant de vraiment traiter les documents et de faire des choses bien plus sophistiquées, bien entendu !

PowerTools pour OOXML

Les PowerTools pour OOXML sont eux une autre couche s'utilisant d'ailleurs avec PowerShell dont je vous parlais dernièrement. C'est un projet open source sur CodePlex dont le but est d'autoriser le traitement de fichiers OOXML côté serveur. Par exemple produire directement un document Word ou Excel sur un serveur Web pour l'envoyer à l'utilisateur, faire des recherches dans une base documentaire, etc...

Lien : PowerTools OOXML sur CodePlex

On notera ce billet Julien Chable sur l'installation des PowerTools (en français, pour une fois...), ainsi qu'une vidéo de présentation (US) sur MSN Video

L'avantage de la combinaison des PowerTools OOXML au PowerShell et ses scripts est de former un ensemble permettant de traiter automatiquement des documents Offices en dehors de toute application. C'est donc une autre façon de traiter les documents Office que celle proposée par le SDK présenté plus haut.

Un exemple concret d'utilisation parmi des milliers d'autres : ajouter un filigrane avec le nom de la société ou une mention "ne pas diffuser" (ou autre) automatiquement à tous les documents d'un répertoire.  On peut même concevoir un service Windows surveillant un ou plusieurs répertoires et ajoutant systématiquement une mention, un logo, un filigrane, etc, à tout nouveau document qui est déposé. On peut envisager par le même biais d'extraire les propriétés de tout document déposé dans un répertoire et de l'envoyer par mail à un administrateur. Les idées ne manquent pas, à vous de jouer !

Conclusion

Disposer de tels outils ouvre la voie à l'intégration de fonction de GED de haut niveau dans toutes les applications, Web ou Desktop. C'est aussi un moyen simple de produire des documents OOXML loin des bricolages DDE, COM/DCOM, ActiveX ou autres pour faire de l'Automation. De plus les fichiers peuvent être manipulés sans que les applications équivalentes du pak Office ne soient installées, c'est un énorme avantage.

le projet (il faut installer le SDK OOXML of course) : PowerOPX.zip (2,91 kb)

Un éclairage sur les techniques d'accès aux données sous .NET

Depuis la sortie de .NET Microsoft n'arrête plus sa course folle ! La plupart des technologies publiées faisaient partie d'un plan presque totalement connu à l'avance, comme WPF, WCF etc. Il a fallu du temps pour qu'émerge ses "modules" de .NET car même le plus puissant des éditeurs de logiciels du monde ne peut pas releaser la totalité d'une montagne comme .NET en un seul morceau. S'il était clair que WPF serait la nouvelle gestion des interfaces utilisateurs et que Windows Forms n'était qu'un "os à ronger" en attendant, le foisonnement des technologies tournant autour des données n'était pas forcément visible ni prévisible il y a quelques années. Et même aujourd'hui savoir ce qui existe et comment s'en servir avec l'ensemble des autres technologies n'est pas forcément une mince affaire !

Un petit dessin valant tous les discours, voici un diagramme qui tourne sur les blogs américains de Microsoft et que j'ai en partie traduit pour vous, en espérant que cela vous aidera à y voir plus clair !

Quelques précisions pour certains acronymes ou noms de technologies :

[Faite un clic-droit sur l'image et copiez-la pour l'afficher en 100% dans Word ou autre ]

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 !

Blend 2 n'appelle pas VS 2008 mais VS 2005 : la solution [edit]

Voilà un truc agaçant : vous possédez les derniers softs de la dernière technologie de la mort-qui-tue et voila que pour créer le gestionnaire du "click" d'un bouton dans Blend 2 ce dernier vous dit que vous n'avez pas Visual Studio et qu'il a copié le code dans le presse-papiers. Il va falloir lancer à la main VS 2008, ouvrir le fichier cs qui va bien et faire un "coller" à la mimine. Back to the préhistoire ? Non : bug.

En fait ce bug est de type "registry". Lorsque VS s'installe il renseigne une clé de la registry qui indique son CLSID. Ainsi, les autres produits MS peuvent savoir quelle version de VS appeler. C'est simple et c'est bien vu. ... sauf qu'il manque un petit test pour s'assurer qu'on ne "régresse" pas dans les versions par exemple. Et c'est le cas si vous avez installer SQL Server 2005 après VS 2008.

Je parle de la version complète, pas la version Express de SQL Server 2005, la version qui installe... VS 2005 pour BIDS notamment. Et dans ce cas, la dernière version installée de VS est bien 2005 qui joyeusement et sans rien tester colle son CLSID à la place de celui de VS 2008. Moralité, soit Blend 2 appelle VS 2005 (ce qui est dommage pour le support du framework 3.5 !), soit vous avez désinstallé VS 2005 et Blend 2 ne le voyant pas (et ne cherchant pas VS 2008) vous propose de coller vous même le code du gestionnaire d'événement qu'il vient de créer...

C'est un bel exemple qui illuste à quel point tout informaticien doit rester humble même lorsqu'il a créé une application extraordinaire... ça finira toujours par péter à la figure de quelqu'un, un jour, exhibant alors un odieux bug, le vilain petit grain de sable dans la belle mécanique...

C'est donc le cas ici, malgré la qualité fantastique de Visual Studio et de Blend, et pour un petit bug dans une séquence mineure (écrite par un stagiaire, allez savoir), c'est tout l'extraordinaire édifice créé par ces deux outils qui s'écroule en partie au moins, faisant régresser "l'expérience utilisateur" (la mienne en l'occurence!) à la préhistoire des OS fenêtrés où bien avant COM ou autre DDE encore plus primitif, la seule façon de faire "communiquer" deux applications était le copier/coller !

On notera que ce petit bug serait sans conséquence si Blend prévoyait dans ses réglages le choix de la version de VS à utiliser. Et ici nous avons une autre démonstration : une mauvaise analyse ou réalisation d'une partie accessoire du logiciel (le paramétrage dans ce cas) met en évidence un bug qui aurait pu être masqué. Leçon à retenir : tout logiciel qui doit en appeler d'autres ou faire référence à des "objets" (au sens le plus large) externes doit absolument posséder dans ses réglages un moyen de dire quels sont ces applications ou ces objets et à quel endroit les trouver. Pan sur le doigts des développeurs de Blend :-)

Un bug dans le setup de VS + Un manquement à cette dernière "best practice" et c'est le mariage entre deux outils complémentaires qui se transforme en un divorce !

En farfouinant, j'ai trouvé la solution. Elle consiste tout simplement à trouver cette fameuse entrée de la registry ou VS indique son CLSID, entrée qui est utilisée par Blend notamment pour savoir comment appeler VS. Ensuite il faut connaître le CLSID de VS 2008 pour le mettre à la place de celui de VS 2005. Une fois qu'on a ces deux informations et qu'on effectue la correction, Blend 2 lance à nouveau VS 2008 automatiquement lorsqu'il créé un gestionnaire d'événement. Ouf !

Et comme je ne suis pas vache, après vous avoir fait la morale sur les bugs et les dialogues de paramétrage des applications, je vais vous donner cette fameuse entrée de registry et ce fameux CLSID... Roulement de tambour... And the winner is.....

changer la valeur de HKEY_CLASSES_ROOT\VisualStudio.DTE\CLSID 
en {1A5AC6AE-7B95-478C-B422-0E994FD727D6}

C'est tout. Bon, sauvegardez votre registry avant de faire la manip, je ne suis pas responsable si ça ne change rien chez vous, et je ne veux rien savoir si après la modif votre ordinateur ne boote plus ou que votre femme part vivre en Alaska avec votre soeur alors même que vous apprenez que votre père est le facteur et toutes ces considérations légales qu'on ajoute généralement dès qu'on donne un conseil qui demande à toucher à la registry. Vous êtes prévenu ! :-)

Et Stay Tuned !

[EDIT 20-9-08]
La solution fonctionnait mais quand j'ai refait la manip le lendemain, un double-click sur un .cs dans un projet sou Blend 2 m'ouvrait le fichier dans le bloc-notes... Et plus de liaison avec VS 2008. Grrrrr.

En (re)farfouillant, j'ai modifié deux autres petites choses qui semblent (en plus de la manip déjà décrite), cette fois-ci, apporter une réponse complète :

  1. Vérifier que les fichiers .cs sont bien associés à "Microsoft Visual Studio Version Selector", le double-click sous Blend semble utiliser les associations de fichier de Windows plutôt que le système de CLSID de la registry.
  2. Dans la clé HKEY_CLASSES_ROOT\VisualStudio.DTE évoquée plus haut, outre l'entrée CLSID il faut aussi mettre l'entré CurVer en conformité, elle doit contenir VisualStudio.DTE.9.0 et non pas la même chose avec 8.0 (VS 2005).

Voici le résultat final (exportation de branche depuis regedit) :

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\VisualStudio.DTE]
@="Microsoft Visual Studio DTE Object"

[HKEY_CLASSES_ROOT\VisualStudio.DTE\CLSID]
@="{1A5AC6AE-7B95-478C-B422-0E994FD727D6}"

[HKEY_CLASSES_ROOT\VisualStudio.DTE\CurVer]
@="VisualStudio.DTE.9.0"

Voilà... En espérant que cela aidera quelques âmes égarées sur la toile en quête d'une réponse à ce problème...
[/EDIT]

Déboguer simplement : les points d'arrêt par code

Voici une astuce toute simple comme je les aime mais qui rend bien des services !

Lorsqu'on débogue une application on utilise fréquemment les points d'arrêt notamment lorsqu'on soupçonne un problème dans une partie de code précise. Tous les développeurs connaissent les points d'arrêt et savent s'en servir. Il est déjà plus rare de voir un développeur se servir des points d'arrêt conditionnels, pourtant un simple clic-droit sur le rond rouge dans la marge (symbolisant le point d'arrêt) permet de fixer une condition liée au code ou au nombre de passages par exemple. Il existe d'autres possibilités d'une grande richesse et si vous ne les connaissez pas, au moins une fois pour voir, faites un clic droit sur un point d'arrêt et jouez un peu avec les options, vous comprendrez alors comment vous auriez pu gagner des minutes ou des heures précieuses si vous aviez connu cette astuce plus tôt !

Mais ce n'est pas des points d'arrêt conditionnels que je voulais vous parler aujourd'hui mais d'une autre astuce encore moins connue / utilisée : les points d'arrêt par code.

En effet, le debugger de Visual Studio peut, en partie, être contrôlé par le code lui-même en utilisant la classe Debugger de l'espace de noms System.Diagnostics.

Les méthodes statiques de cette classe permettent par exemple de savoir si le debugger est lancé ou non, voire de lancer s'il n'est pas actif. La méthode Break() quant à elle permet simplement de faire un point d'arrêt et c'est elle qui nous intéresse ici.

Plutôt que d'attendre qu'une exception soit levée, de revenir dans le code, de placer un point d'arrêt et de relancer l'application en espérant que "ça plante" de la même façon, il est plus facile de prévoir d'emblée le point d'arrêt là où il existe un risque d'y avoir un problème, notamment en phase de mise au point d'un code. Un simple Debugger.Break(), dès qu'il sera rencontré lors de l'exécution, aura le même effet qu'un point d'arrêt inconditionnel placé dans Visual Studio. Bien entendu, le break peut être programmer selon un test (valeur non valide d'une propriété par exemple). Dans un tel cas dès que l'application rencontrera le break elle déclenchera le passage en mode debug sur le "point d'arrêt" ainsi défini. Le développeur peut se dégager l'esprit pour d'autres tâches de test, dès que le break sera rencontré VS passera en debug immédiatement sans risque de "louper" le problème ou de le voir trop tard et de ne plus avoir accès à certaines variables.

un petit exemple :

class Program
{
   static void Main(string[] args)
   { 
       var list = new List<Book>
       {   new Book {Title = "Livre 1", Year = 1981},
           new Book {Title = "Livre 2", Year = 2007},
           new Book {Title = "Livre 3", Year = 2040} };

foreach (var book in list) { Console.WriteLine(book.Title+" "+book.Year); }
}

class Book
{
   private int year;

   public string Title { get; set; }
   public int Year
  { get { return year; }
     set {
              if (value > 1980 && value < DateTime.Now.Year) year = value;
              else Debugger.Break();
                   // throw new Exception("L'année " + value + " n'est pas autorisée");
           }
   }
}

Lors de l'initialisation de la collection "list" dans le Main(), l'année du troisième livre (2040) déclenchera le break. On pourra alors directement inspecter le code et savoir pourquoi ce "logiciel" plante dès son lancement...  On voit qu'ici j'ai mis en commentaire l'exception qui sera lancée par la version "finale" du code. A sa place j'ai introduit l'appel à Break(). Rien à surveiller. Si le problème vient de là (ce qui est le cas ici) VS passera tout seul en debug...

C'est pas chouette ça ?

Alors 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...

 

Des outils simples et gratuits pour faire du XAML

Xaml est le langage de description utilisé par WPF et Silverlight. On peut créer du code Xaml en utilisant Expression Blend, Expression Design ou même Adobe Illustrator (à l'aide d'un petit plugin gratuit XamlExport). Bien entendu le code Xaml peut aussi être manipulé sous VS 2008 mais de façon sommaire.

Pour tester du code Xaml il s'avère souvent nécessaire, qu'on soit en phase d'apprentissage ou qu'on soit un expert, de pouvoir saisir ou modifier quelques lignes pour visualiser le résultat.

Pour cela il existe des "notepad" (bloc-notes).

XamlPad.exe

C'est le plus simple. Rudimentaire même. Il est fourni avec le SDK Windows. Pour info sur ma machine il se trouve dans "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin". Il dispose d'une page sur MSDN expliquant comment s'en servir. Il ne fait pas grand chose et il est préférable de se tourner vers des versions améliorées. 

XamlPadX

Cet outil est déjà plus évolué. On peut le télécharger sur le blog de Lester. La version actuelle est la 4.0 qui sait gérer les add-ins et possède quelques exemples "hard codés" qui permettent de rapidement tester l'outil. Le setup peut être téléchargé depuis le billet du blog de Lester.
Un petit détail : Avast détecte un Trojan générique lors du téléchargement et refuse d'enregistrer le fichier... Pour l'installer il faut couper Avast, télécharger l'exe, le lancer (c'est un setup) et un fois l'install terminée rétablir Avast. L'exécutable lui-même ne pose aucun problème, je suppose que c'est Avast qui doit prendre pour un Trojan une séquence du module d'installation.

 

Kaxaml

Cet autre outil offre des services similaires mais avec une philosophie légèrement différente. Difficile de dire s'il est meilleur que le précédent c'est à chacun de voir celui qui est le mieux adapté à ses besoins et à sa façon de travailler. Kaxaml dispose de sa propre page web d'où l'on peut télécharger soit la version 1.0 soit la bêta qui supporte Silverlight 2 b2.

 

Conclusion

Ces petits outils n'ont pas la sophistication d'un Blend ou d'un Expression Design, ils ne remplacent pas non plus la partie code-behind de VS 2008. En revanche ils permettent de tester rapidement des idées ou des snippets récupérés ici ou là. Ils ne remplacent donc rien mais viennent compléter agréablement la boîte à outil du développeur WPF qu'il soit expert ou en phase d'apprentissage.

Bon Dev

Et Stay Tuned !

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 !

Alors une petite astuce rapide pour aujourd'hui. La fenêtre Immediate de VS 2008 offre un moyen simple d'invoquer du code et de tester rapidement une méthode. Peut-être connaissez-vous cette fonction de VS dans ce cas j'espère juste vous avoir rafraichi la mémoire pour vous en servir plus souvent !

Je ne connais pas le nom en français de cette fenêtre car j'utilise un VS en US. Mais vous trouverez facilement.

Une des façons rapides de l'appeler est d'utiliser le raccourci vers la fenêtre Command et de taper "immed" ce qui ouvre la fenêtre Immediate. La fenêtre Command s'appelle par Ctrl-Alt-A (vérifiez si en français le raccourci est le même).

Bien entendu pour invoquer du code il faut être en debug. Soit vous avez un point d'arrêt quelque part et vous attendez d'y être arrivé, soit vous pouvez lancer l'application par F10 (step over) au lieu de F5, cela s'arrêtera tout de suite sur le Main. Là, tapez Ctrl-Alt-A puis "immed" si la fenêtre Immediate n'est pas déjà affichée. Et il ne reste plus qu'à taper votre code de test... Vous disposez de Intellisence et de toute l'aide, c'est pas merveilleux ? !

En image pour voir de quoi il s'agit (la qualité de la capture est mauvaise en raison de la réduction à 80% et de la compression jpeg, j'essaye de ne pas trop grossir les flux RSS des abonnés au blog...) :

La fenêtre Immediate, c'est facile, rapide, puissant. Autant s'en servir !

Bon Dev

...Et Stay Tuned !

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)