Dot.Blog

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

Vous et le framework .NET

Dans la jungle des technologies .NET il est intéressant de savoir ce que vous utilisez déjà en production et ce que vous prévoyez d'utiliser dans ce contexte. Je parle bien de production, pas des essais que nous faisons tous et qui remplissent nos machines, non, uniquement ce qui est installé chez des clients (ou utilisateurs) ou en cours de développement.

Comme je ne vais pas vous demander de laisser un message à ce billet et puis faire le tri après, pour faire plus simple j'ai mis en place un petit sondage. D'ici quelques temps je "relèverai les compteurs" et je les publierai ici. Répondre à ce sondage est ainsi un moyen simple pour que nous sachions les uns les autres ce qui est utilisé (ou en prévision d'utilisation). 

Merci d'avance de prendre une minute pour réponse au sondage qui se trouve ici :

Cliquez ici pour lancer le sondage.

Stay Tuned pour les résultats (et pour bien d'autres news entre temps...) !

Debug ou Cracking ? Des outils .NET à la frange des deux mondes...

Un debugger comme celui de Visual Studio n'est que rarement comparé à un outil de cracking pour la bonne raison que son utilisation s'effectue systématiquement (ou presque) sur des applications en cours de développement / maintenance, impliquant que l'opérateur du debug a le droit d'accéder aux sources. Mais comment catégoriser les outils qui suivent ?

Les trois outils dont je vais vous parler aujourd'hui se situent tous à la limite entre debugging et cracking, non pas forcément par la volonté de leur concepteur mais bien par leur nature. Il s'agit en fait d'applications autonomes capable de percer les secrets d'applications .NET en cours de fonctionnement (2 outils sur les 3 pour être précis, l'un est un visualisateur pour VS).

Outils de debug très intéressants ne nécessitant pas forcément l'installation de VS sur la machine, ces applications sont des compagnons à mettre dans votre boîte à outils. Utilitaires autonomes pouvant être utilisés par n'importe qui, l'existence même de ces outils ouvre la voie à un cracking autrement plus simple que l'utilisation d'outils comparables pour Win32. La haute cohérence de .NET et sa "lisibilité" rendant l'opération moins ardue.

Anges ou Démons ?

Les objets n'ont pas d'âme (si tant est que les êtres vivants en aient une) mais surtout ils n'ont pas de conscience. De tels outils ne peuvent donc être taxés en eux-mêmes d'être "diaboliques". C'est l'Homme qui appuie sur la gâchette que l'on juge et condamne, non les particules de poudre et l'amorce ayant permis à la balle de sortir de l'arme... A vous d'en faire bonne usage donc. Le plus important étant même de savoir que de tels outils existent pour éventuellement réfléchir, pour des applications sensibles, à comment rendre inopérantes des attaques qui utiliseraient cette approche.

Les outils

Crack.NET

Ecrit par Josh Smith, cet outil est un "logiciel de débogage et de scripting qui vous donne accès à l'intérieur de toute application .NET desktop" (d'après la traduction de la présentation de l'auteur). Une fois lancé l'utilitaire permet de choisir l'application .NET à cracker (selon les termes mêmes du bouton de lancement). Visualiser la mémoire, traverser les grappes d'objets, il est ainsi possible de tracer l'état de l'application "victime". Imaginons un mot de passe de connexion à une base de données ou à un Service Web, même si l'exécutable est obfusqué, même si les valeurs sont cryptées sur disque, il devient possible de lire ces dernières en clair une fois en mémoire de l'application.

On flirte avec la limite cracking / debugging, mais encore une fois l'intention coupable ou non est du ressort de la conscience de l'utilisateur de l'outil.

Un outil à posséder donc.

http://joshsmithonwpf.wordpress.com/cracknet/

Mole

Mole est un outil un peu différent, c'est un visualisateur pour Visual Studio qui permet de plonger dans les arborescences d'objets, de visualiser les valeurs mais aussi de les modifier.

En tant qu'outil pour VS la frontière du cracking s'éloigne, celle du debugging étant plus clairement visible.

"Mole a été conçu pour permettre au développeur non seulement d'afficher des objets ou des données, mais aussi de percer et visualiser les propriétés de ces objets, puis de les modifier. Mole permet un nombre illimité d'objets et de sous-objets en cours d'inspection. Quand Mole trouve un objet IEnumerable, les données peuvent être visualisées dans une DataGridView ou dans une grille de propriétés. Mole gère facilement les collections qui contiennent plusieurs types de données. Mole permet aussi au développeur de voir les champs non publics de tous les objets. Vous pouvez apprendre beaucoup sur le framework. NET en inspectant ainsi les données de vos applications."

http://karlshifflett.wordpress.com/mole-for-visual-studio/

Snoop

"Snoop est un utilitaire conçu pour simplifier le débogage visuel des applications WPF à l'exécution."

Un peu comme Crack.NET il s'agit ici d'un utilitaire autonome permettant d'inspecter une application WPF lors de son exécution. Cela peut s'avérer très utile en debug, mais peu présenter certains risques entre de mauvaises mains...

 

En tout cas, si vous développez des applications WPF, il faut avoir Snoop, il peut fournir une aide appréciable en plus du debug sous VS.

http://blois.us/Snoop/

Conclusion

Objets inanimés avez-vous une âme ? Questionnait Lamartine. Les objets numériques qu'il n'a pas connus n'en ont ni plus ni moins que les objets physiques en tout cas. Cracker ou debugger, c'est à vous de voir avec votre conscience, mais dans tous les cas, il est important de connaître l'existence de tels outils qui peuvent s'avérer bien pratiques dans certaines circonstances.

Stay Tuned !

Améliorer le debug sous VS avec les proxy de classes

Visual Studio est certainelement l'IDE le plus complet qu'on puisse rêver et au-delà de tout ce qu'il offre "out of the box" il est possible de lui ajouter de nombreux add-ins (gratuits ou payants) permettant de l'adapter encore plus à ses propres besoins. Ainsi vous connaissez certainement les "gros" add-ins comme Resharper dont j'ai parlé ici quelque fois ou GhostDoc qui écrit tout seul la doc des classes. Vous connaissez peut-être les add-ins de debogage permettant d'ajouter vos propres visualisateurs personnalisés pour le debug. Mais vous êtes certainement moins nombreux à connaître les proxy de classes pour le debug (Debugger Type Proxy).

A quoi cela sert-il ?

Tout d'abord cela n'a d'intérêt qu'en mode debug. Vous savez que lorsque vous placez un point d'arrêt dans votre code le debugger de VS vous permet d'inspecter le contenu des variables. C'est la base même d'un bon debugger.

La classe à deboguer 

Supposons la classe Company suivante décrivant une société stockée dans notre application. On y trouve trois propriétés, le nom de la société Company, l'ID de la société dans la base de données et la date de dernière facturation LastInvoice :

public class Customer
        {
            private string company;
            public string Company
            {
                get { return company; }
                set { company = value; }
            }
 
            private int id;
            public int ID
            {
                get { return id; }
                set { id = value; }
            }
 
            private DateTime lastInvoice;
            public DateTime LastInvoice
            {
                get { return lastInvoice; }
                set { lastInvoice = value; }
            }
        }

 

Le debug "de base" 

Supposons maintenant que nous placions un point d'arrêt dans notre application pour examiner le contenu d'une variable de type Customer, voici que nous verrons :

Le debugger affiche toutes les valeurs connues pour cette classe, les propriétés publiques comme les champs privés. Il n'y a que 3 propriétés et 3 champs dans notre classe, imaginez le fatras lorsqu'on affiche le contenu d'une instance créée depuis une classe plus riche ! Surtout qu'ici, pour tester notre application, ce dont nous avons besoin immédiatement ce sont juste deux informations claires : le nom et l'ID de la société et surtout le nombre de jours écoulés depuis la dernière facture. Retrouver l'info parmi toutes celles affichées, voire faire un calcul à la main pour celle qui nous manque, c'est transformer une session de debug qui s'annonçait plutôt bien en un véritable parcours du combattant chez les forces spéciales !

Hélas, dans la classe Customer ces informations sont soit éparpillées (nom de société et ID) soit inexistantes (ancienneté en jours de la dernière facture).

Il existe bien entendu la possibilité de créer un visualisateur personnalisé pour la classe Customer et de l'installer dans les plug-ins de Visual Studio. C'est une démarche simple mais elle réclame de créer une DLL et de la déployer sur la machine. Cette solution est parfaite en de nombreuses occasions et elle possède de gros avantages (réutilisation, facilement distribuable à plusieurs développeurs, possibilité de créer un "fiche" complète pour afficher l'information etc).

Mais il existe une autre voie, encore plus simple et plus directe : les proxy de types pour le debugger.

Un proxy de type pour simplifier

A ce stade du debug de notre application nous avons vraiment besoin du nombre de jours écoulés depuis la dernière facture et d'un moyen simple de voir immédiatement l'identification de la société. Nous ne voulons pas créer un visualisateur personnaliser, mais nous voulons tout de même une visualisation personnalisée...

Regardons le code de la classe suivante :

public class CustomerProxy
        {
            private Customer cust;
 
            public CustomerProxy(Customer cust)
            {
                this.cust = cust;
            }
 
            public string FullID
            {
                get { return cust.Company + " (" + cust.ID + ")"; }
            }
 
            public int DaysSinceLastInvoice
            {
                get { return (int) (DateTime.Now - cust.LastInvoice).TotalDays; }
            }
        }

 

la classe CustomerProxy est très (très) simple : elle possède un constructeur prenant en paramètre une instance de la classe Customer puis elle expose deux propriétés en read only : FullID qui retourne le nom de la société suivi de son ID entre parenthèses, et le nombre de jours écoulés depuis la dernière facture.

Nota: Ce code de démo ne contient aucun test... dans la réalité vous y ajouterez des tests sur null pour éviter les exceptions si l'instance passée est nulle, bien entendu.

Vous allez me dire, c'est très joli, ça fait une classe de plus dans mon code, et comment je m'en sers ? je ne vais pas modifier tout mon code pour créer des instances de cette classe cela serait délirant !

Vous avez parfaitement raison, nous n'allons pas créer d'instance de cette classe, nous n'allons pas même modifier le code de l'application en cours de debug (ce qui serait une grave erreur... modifier ce qu'on test fait perdre tout intérêt au test). Non, nous allons simplement indiquer au framework .NET qu'il utilise notre proxy lorsque VS passe en debug... Un attribut à ajouter à la classe originale Customer, c'est tout :

#if (DEBUG)
        [System.Diagnostics.DebuggerTypeProxy(typeof(CustomerProxy))]
#endif
        public class Customer
        {
            //...
        }

Vous remarquerez que pour faire plus "propre" j'ai entouré la déclaration de l'attribut dans un #if DEBUG, cela n'est absolument pas obligatoire, j'ai fait la même chose autour du code de la classe proxy. De ce fait ce code ne sera pas introduit dans l'application en mode Release. Je vous conseille cette approche malgré tout.

Et c'est fini !

Le proxy en marche

Désormais, lorsque nous sommes en debug que nous voulons voir le contenu d'une instance de la classe Customer voici ce que Visual Studio nous affiche :

 

Vous remarquez immédiatement que le contenu de l'instance de la classe Customer n'est plus affiché directement mais en place et lieu nous voyons les deux seules propriétés "artificielles" qui nous intéressent : le nom de société avec son ID, et le nombre de jours écoulés depuis la dernière facture. Fantastique non ? !

"Et si je veux voir le contenu de Customer malgré tout ?" ... Je m'attendais à cette question... Regardez sur l'image ci-dessus, oui, là, le petit "plus" dans un carré, "Raw View"... Cliquez sur le plus et vous aurez accès au même affichage de l'instance de Customer qu'en début d'article (sans le proxy) :

 

Conclusion

Si ça c'est pas de la productivité et de la customisation aux petits oignons alors je suis à court d'arguments ! :-)

Bon debug !

... Et Stay Tuned !

le projet de test : DebugProxy.zip (5,55 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 !

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 !

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 !

Traiter un flux RSS en 2 lignes ou "les trésors cachés de .NET 3.5"

.NET 3.5 apporte beaucoup de classes nouvelles et d'améliorations à l'existant. Certains ajouts sont plus médiatisés que d'autres. Mais il serait injuste de limiter cette mouture à LINQ ou aux arbres d'expressions, aussi géniales et puissantes soient ces avancées.

.NET 3.5 apporte réellement une foule de nouveautés parmi lesquelles il faut noter :

  • L'apport de WCF et de LINQ au compact framework
  • De nouvelles facilités pour contrôler le Garbarge Collector comme le LatencyMode de la classe GCSettings
  • L'ajout de l'assemblage System.NetPeerToPeer.Collaboration qui permet d'utiliser les infrastructures de peer-to-peer
  • Des améliorations importantes de WCF, l'intégration WCF-WF
  • etc...

Pour une liste complète des nouveautés il est intéressant de jeter un oeil à cette page MSDN.

Un exemple qui illustre les avancées plus ou moins méconnues de .NET 3.5, l'espace de noms System.ServiceModel.Syndication dans la dll System.ServiceModel.Web apporte de nouvelles facilités pour gérer des flux RSS. Et pour s'en convaincre quelques lignes de codes :

SyndicationFeed feed;
using (var r = XmlReader.Create(https://www.e-naxos.com/Blog/syndication.axd))
{ feed = SyndicationFeed.Load(r); }

C'est tout ! Dans la variable "feed" on a tout ce qu'il faut pour travailler sur le flux RSS.

Vous pensez que je triche et que "travailler sur le flux RSS" c'est certainement pas si simple que ça ?. Bon, allez, c'est parce que c'est vous : compliquons même la chose et, à partir de ce flux, affichons le titre de tous les billets qui parlent de LINQ dans leur corps. Voici le code complet près à compiler :

using System;
using System.Linq;
using System.ServiceModel.Syndication;
using System.Xml;

namespace NET35RSS
{ class Program
  {
     static void Main()
     {
        SyndicationFeed feed;
        using (var r = XmlReader.Create(
https://www.e-naxos.com/Blog/syndication.axd))
        { feed = SyndicationFeed.Load(r); }
           if (feed==null) { Console.WriteLine("Flux vide."); return; }
           Console.WriteLine(feed.Title.Text);
           Console.WriteLine(feed.Description.Text+"\n");
           var q = from item in feed.Items
           where item.Summary.Text.ToUpper().Contains("LINQ") select item;
           foreach (var item in q) Console.WriteLine(item.Title.Text);
       }
    }
}

Ajoutez une petite saisie pour le mot à chercher au lieu d'un codage en dur ("LINQ" dans cet exemple) et un petit fichier paramètre pour y stocker la liste des blogs que vous connaissez, et en deux minutes vous aurez un puissant outil de recherche capable de vous lister toutes les billets de vos blogs préférés qui parlent de tel ou tel sujet...

C'est pas génial ça ?

Si, ça l'est, bien sûr ! Alors Stay Tuned !

pour les paresseux du clavier, le projet VS 2008 : NET35RSS.zip (5,36 kb)

Un livre à avoir : "Framework Design Guidelines"

J'achète assez peu de livres en général, en effet dès qu'on s'intéresse à ce qui est nouveau tous les livres potentiellement intéressants sont "à paraître", et quand ils paraissent l'info est déjà réchauffée par rapport à ce qu'on peut trouver des mois avant sur Internet. Bien entendu cela implique d'aller chercher l'information brute, éparpillée et en anglais. C'est pour cela que les ouvrages techniques en français trouvent toute leur utilité en offrant une information structurée, vérifiée et traduite pour tous ceux qui ne lisent pas l'anglais.

Toutefois il m'arrive d'acheter certains livres lorsqu'ils traitent de sujet plus "intemporels" comme la méthodologie ou ici le framework .NET.

Oui, ce livre est en anglais, et à votre prochaine question la réponse est non, je n'en connais pas de traduction en français ce qui est de toute façon rare dans ce domaine. L'exemple récent de la fermeture de l'antenne française de O'Reilly illustre la difficulté globale de vendre du livre technique en France malgré un catalogue attrayant. Quant à traduire un ouvrage et donc réengager des frais importants pour un public très restreint, fort peu s'y sont risqués ou s'y risquent. Dans mes propres "development guidlines", en position 1 je mettrais "faites du C#", en 2 "faites du LINQ", mais en position 0 "faites de l'anglais" !.

Framework Design Guidelines

Ce livre traite des bonnes méthodes à mettre en oeuvre pour développer des applications respectueuses du framework .NET. Ecrit par deux membres de l'équipe de développement de .NET il a aussi été relu et corrigé par d'autres personnes de cette équipe qui, chose originale, font apparaître ici et là des petits encadrés où ils apportent leur point de vue sur ce que les auteurs viennent d'écrire. C'est une approche intéressante qui rend le contenu plus vivant. L'avant propos est d'ailleurs signé par Anders Hejlsberg, difficle de trouver mieux...

Ce n'est pas un livre très récent, il a du paraître en 2006 la première fois, mais son contenu est "intemporel" dans le sens où il dépasse les modes ou les dernières options du framework pour parler de son coeur, ses API, sa structure et la façon de bien coder dans cet environnement.

Le contenu

Le sous titre est finalement clair "Conventions, Idioms and Patterns for Reusable .NET Libraries". Conventions, idiomes et patterns pour des bibliothèque de codes réutilisables.

La première partie traite des "qualités d'un framework bien conçu" et on entre un peu dans les coulisses de .NET, comment et pourquoi certains choix ont été arretés. Une façon agréable, au delà du côté anecdotique, d'aborder les qualités générales que se doit posséder toute bonne bibliothèque de code, comme celles que nous sommes amenées parfois à écrire.

Les fondamentaux du framework sont ensuite abordés puis on trouve les guidelines proprement dites. Stratégie de nommage, le choix entre classe ou structure, entre classe abstraite ou interface, la conception des membres d'une classe (propriétés, méthodes, champs...) tout cela est traité avec intelligence, à propos, et permet d'affiner ses propres vues sur ces questions ou parfois même de s'interroger sur des sujets dont on pensait avoir fait le tour.

Les exceptions sont traitées en détail, toujours sous l'angle de la meilleure mise en oeuvre possible plus que sur le code ou la syntaxe. Ce livre est un moyen terme entre théorie, design pattern, expérience de développeurs ayant écrit l'un des plus gros framework existant, sagesse et doutes que tout informaticien conscient de l'importante de ses choix se doit d'avoir.

Un final sur l'utilisation de FxCop, son évolution, comment il marche et comment en tirer le meilleur est tout à fait appréciable. Je parlais justement dans un dernier billet de la "sous utilisation" de cet outil fanstastique par la majorité des développeurs que je rencontre ou que je forme. Ce chapitre permettra peut-être aux lecteurs de ce livre de faire plus souvent usage de FxCop.

Le CD

Le livre est accompagné d'un CD contenant des exemples de code et plusieurs vidéo de conférences (en anglais aussi, ne rêvez pas :-) ), toutes particulièrement intéressantes et portant sur des sujets aussi variés que le garbage collector (et tout ce qui tourne autour de la libération de la mémoire et des ressources), les performances ou le packaging et le déploiement. Une vraie mine d'information, pas forcément récentes, comme le livre lui-même, mais qui abordent des fondamentaux parfois négligés.

Conclusion

Comme je le disais, ce livre est intemporel, en tout cas tant que vivra le framework .NET sous la forme que nous connaissons depuis plusieurs années maintenant. Il permet d'entrer un peu dans l'équipe de développement de cette plateforme, de comprendre les choix qui ont présidé à sa mise en oeuvre et surtout il permet, par cette vision "de l'intérieur" et les nombreux conseils qu'il contient de mieux concevoir son propre code, de mieux trancher entre certaines options parfois trop nébuleuses (classe ou interface, classe ou structure, par exemple) en sachant avec précision pourquoi on fera ou non tel ou tel choix.

C'est un livre plaisant à lire, qu'on peut "consommer" en piochant les chapitres, pas forcément dans l'ordre du livre. Un "must have" pour qui développe sous .NET, c'est une évidence.

Références

Framework Design Guidelines

Krzysztof Cwalina (au scrabble si vous le placez vous mettez à genou vos adversaires !)
Brad abrams

0-321-24675-6

Edité par Addison-Wesley

Une bonne librarie technique en ligne

Vous pouvez acheter ce livre dans toutes les bonnes librairies, toutefois si vous voulez le payer le moins cher possible, je vous conseille de le commander directement à "The Book Depository Ltd", une librairies anglaise qui livre vite et bien qui affiche des prix en général très bas. Leur site Internet : http://www.bookdepository.co.uk/WEBSITE/WWW/WEBPAGES/homepage.php

C'est un vendeur qu'utilise Amazon, mais si vous passez en direct c'est généralement moins cher...

Bonne lecture et Stay Tuned !