Dot.Blog

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

Article ! Le Binding Xaml, sa syntaxe, éviter ses pièges… (WPF/Silverlight)

imagePromis dans mon dernier billet, le voici enfin ! Ce nouvel article dédié au binding Xaml pèse 77 pages (le record était tenu jusqu’à lors par mon article M-V-VM avec Silverlight avec 70 pages) et se présente sous la forme d’un PDF et de 9 projets exemples.

Le binding cet inconnu … J’en parlais dans mon billet Le retour du spaghetti vengeur, le binding avec sa syntaxe pleine d’accolades et de chaînes de caractères non contrôlées à la compilation est un piège à bugs et la porte ouverte au code spaghetti.

Plutôt que de me lamenter et vous laisser vous embourber dans la sauce de ces spaghetti là, j’ai pris ma plume, et voici le résultat : 77 pages sur le binding Xaml, son fonctionnement, ses différentes syntaxes le tout illustré par des exemples clairs. L’article aborde aussi le débogue du binding assez délicat puisque Xaml échappe au débogueur de Visual Studio, et que le binding n’est que partiellement couvert par Intellisense.

Des conseils, du vécu, beaucoup d’exemples, voilà ce que vous trouverez dans cet article à télécharger en suivant le lien suivant :

Le Binding Xaml – Maîtriser sa syntaxe et éviter ses pièges (WPF/Silverlight)

(Attention, avant de cliquer sur le bouton “télécharger” attendez que la fiche détail de l’article soit bien affichée, sinon le site pensera que vous tentez un accès à une ressource non publique et vous demandera un login… Je reçois tous les jours des demandes d’ouverture de compte provenant de lecteurs trop impatients qui cliquent trop vite sur le bouton ! La prochaine version du site en Silverlight est en préparation et corrigera ce petit problème, mais d’ici là : slow down cowboy !).

Pour vous aider à vous faire une idée du contenu de l’article voici son sommaire :

Sommaire

  • Références    5
  • Code Source    6
  • Préambule    7
  • Le Binding Xaml : Ange ou Démon ?    7
    • Le Binding    8
    • Définition    8
    • Utilisations    9
    • Schéma du principe    9
    • Déclaration    10
      • Par code    10
      • En Xaml    11
  • Les modes de binding    13
    • Le mode OneTime    13
    • Le mode OneWay    13
    • Le mode TwoWay    14
      • Gestion du timing    14
    • Le mode Default    16
    • Le mode OneWayToSource    16
  • Hiérarchie de valeur    18
    • Règles de précédences    19
  • La notion de  DataContext    20
  • Les convertisseurs de valeur    21
    • Définition    21
    • Scénario    21
    • Implémentation    22
    • Utilisation    23
      • Instanciation    23
      • Invocation    23
      • Bonnes pratiques    24
      • Pour résumer    26
  • Les dangers du Binding    27
    • Des chaînes non contrôlées    27
    • Un langage dans le langage    28
  • On fait quoi ?    28
  • Déboguer le Binding    28
    • Vigilance    28
    • Une code Xaml court    29
    • Refactoring sous contrôle    29
    • Utiliser des outils intelligents    29
    • Utiliser Expression Blend    29
    • Vérifier les erreurs de binding dans la fenêtre de sortie    30
    • Créer un fichier des erreurs de Binding    30
    • La feinte du convertisseur inutile    32
    • Quelques outils supplémentaires    33
      • Spy++    33
      • ManagedSpy    33
      • Snoop    34
      • Mole    34
      • Reflector    34
      • Vos neurones    34
  • Les syntaxes du Binding    34
    • Le binding simple    34
      • Binding direct    35
      • Binding sur une propriété    35
      • Binding sur une sous-propriété du contexte    36
      • L’Element Binding    37
      • Convertisseurs de valeur    37
        • Paramètres de conversion    38
      • StringFormat    40
        • Injection de culture    41
        • Le ContentStringFormat    42
        • Gérer les nuls    43
    • Le Binding Multiple    44
      • La classe Personne    44
      • Le code du multi convertisseur    45
      • Le code Xaml    46
    • Le Binding XML    47
      • Binding sur une source Web    47
      • Binding sur une source XML en ressource    48
      • Binding sur une requête Linq To XML    49
    • Le Binding Relatif    52
      • Binding to Self    52
      • Le TemplatedParent Binding    53
      • Le Binding sur recherche d’ancêtre    54
      • Le Binding PreviousData    56
        • La source de données    58
        • La visibilité des flèches : la magie de PreviousData et du Binding Multiple    58
        • Le contenu des textes    61
      • Le Template binding    61
        • Utilité    61
      • Le Collection Binding    67
      • Le Priority Binding    69
  • Les propriétés de tous les bindings    74
  • Conclusion    76

Avril est froid et pluvieux mais les soirées rallongent, c’est le printemps même si cela n’y ressemble pas encore beaucoup, grâce à moi vous savez maintenant comment occuper vos soirées et vos weekend au lieu de faire l’idiot dans les embouteillages des vacances : Lisez cet article !

Et Stay Tuned !

Fichiers PFX de signature de projet Visual Studio / objet déjà existant après migration Windows 7

Vous l'avez compris, l'entrée de blog d'aujourd'hui ne parle pas de Silverlight ni d'autres sujets technologiques passionnants mais d'un problème très ennuyeux intervenant après la migration sous Windows 7. Cela concerne les projets signés numériquement sous Visual Studio, ceux possédant un fichier PFX donc.

Une fois cette migration effectuée, tout semble tellement bien marcher que vous lancer fièrement Visual Studio sans vous douter du complot sournois qui se trame contre vous et qui se révèlera au moment où vous tenterez d'ouvrir une solution contenant des projets signés... Vous allez me dire, l'attente est courte. En effet, il est rare d'ouvrir VS juste pour le plaisir de le regarder, assez rapidement, même pour les plus lents d'entre nous, on finit par faire Fichier / Ouvrir (les plus créatifs préférant Fichier / Nouveau, mais ce n'est pas le sujet du jour).

A ce moment là, tous les projets signés déclenchent une importation du fichier PFX (même si vous êtes toujours sur la même machine et que rien n'a changé, n'oubliez pas que cette machine vient de migrer de Vista à 7 !). Comme vous êtes un développeur honnête, vous connaissez bien entendu les mots de passe des fichiers PFX de vos projets. Donc pas de problème vous tapez le mot de passe. Bang ! Erreur "l'objet existe déjà" (Object already exists). Et pour peu que votre solution contienne des dizaines de projets, ce qui est mon cas assez fréquemment, vous allez boucler sur cette séquence pour tous les fichiers PFX. A la fin vous pourrez travailler sur votre solution, mais à toute tentative de compilation vous vous reprendrez la même séquence : importation de la clé, demande de mot de passe, échec pour cause d'objet existant, etc pour chaque projet signé.

C'est un peu gênant... Mais il existe une raison et une solution !

La raison, en tout cas pour ce que j'en ai vu, c'est que la migration vers W7 modifie les droits du répertoire dans lequel sont cachés les clés importées. Pourquoi ? Je n'en sais rien et pour l'instant je n'ai rien trouvé sur le Web à ce sujet.

En tout cas, le problème étant identifié, il existe une solution : changer les droits et s'approprier le dit répertoire. Ca peut être plus compliqué que prévu, en tout cas j'ai galéré un peu (j'avoue franchement ne pas avoir un niveau d'expert en matière de gestion de sécurité sous Windows). En effet il faut déjà trouver le répertoire en question. (roulements de tambours) c'est... c'est... C:\Users\All Users\Microsoft\Crypto\RSA

Maintenant que faire... Clic droit sur le répertoire (dont l'image possède un petit verrou d'ailleurs, verrou qui disparaitra en fin de manip), onglet sécurité et on essaye de s'approprier tout ça. Ca plantouille car Windows répond qu'on n'a pas les droits sur xxxx (à remplacer par le nom imbuvable de chaque fichier de ce répertoire, justement ceux posant problème).

Bref, il faut y aller à la main. On entre dans le répetoire et on fait un clic droit / sécurité sur chaque fichier. Certains laissent voir la page Sécurité immédiatement. Laissez tomber. Mais un certain nombre d'autres fichiers affichent un message vous indiquant que vous n'avez pas le droit de voir l'onglet Sécurité ! Heureusement Windows vous permet de vous les approprier, donc d'en devenir le propriétaire (au passage je vois mal l'intérêt d'interdire un truc en proposant de l'autoriser, je vous l'ai dit, je ne suis pas un expert en Sécurité Windows !). C'est ce que j'ai fait pour chaque fichier. En fin de manip j'ai recommencé la modification des droits sur le répertoire lui-même, et là c'est passé. Plus de petit verrou affiché dans le symbole dossier.

Et immédiatement, Visual Studio ne redemande plus l'importation des clés. Ca remarche. Ouf !

Je suis convaincu que je m'y suis pris comme un pied pour régler le problème (il doit y avoir plus simple et plus propre que de devenir propriétaire de chaque fichier un par un), en tout cas ça règle bien le problème qui avait été bien identifié : problème de droits sur le répertoire des clés.

Pour l'instant c'est la seule surprise que j'ai eu en migrant cette machine de Vista à Windows 7. Le reste marche très bien et on ne perd rien ce qui est très appréciable (comme j'aurai aimé que cette option de migration sans douleur existe sur les anciennes versions de Windows !).

J'espère que le récit de cette mésaventure (et surtout sa solution) évitera à certains de perdre quelques heures... Si oui, n'hésitez pas à me le dire, ça fait toujours plaisir de savoir qu'un billet a été utile !

Et sir parmi vous il y en a qui sont plus doués que moi niveau sécurité Windows, qu'ils n'hésitent pas à indiquer la "bonne" manip pour arriver au résultat je modifierai en conséquence le présent billet...

Dans tous les cas, Stay Tuned !

Les propriétés de dépendance et les propriétés jointes sous WPF (article à télécharger)

En voilà un beau sujet ! Vous allez me dire qui irait investir deux jours à taper 25 pages sur ce sujet, il faut être totalement givré ! Et bien vous en avez un devant vous (par blog interposé) ... donc pas de remarques désobligeantes sur ma santé mentale, hein !

Certes les propriétés de dépendance et les propriétés jointes de WPF et Silverlight ne semblent pas être un sujet aussi exitant que quelques astuces LINQ ou la meilleure façon d'intégrer de la 3D dans Silverlight 3 (miam!)... Je vous le concède. Mais en revanche c'est un sujet capital car derrière ces propriétés bien particulières se cache l'un des piliers de la puissance de WPF, un mécanisme qui autorise la gestion des styles, des animations, du Data Binding et de bien d'autres choses sans lesquelles WPF ne serait pas ce qu'il est.

Savoir ce qu'est une propriété de dépendance ou une propriété jointe, savoir en déclarer et savoir les utiliser représente une base impossible à zapper.

Alors, pour tout savoir sur le sujet, téléchargez mon dernier article "Propriétés de dépendance et propriétés jointes (WPF/Silverlight)" !

L'article est fourni en PDF avec les sources du projet exemple (utilisable sous VS 2008 ou Blend 2).

NB: Pour mieux comprendre cet article si vous n'êtes pas encore un expert de WPF, je vous conseille la lecture de mon précédent article "10 bonnes raisons de préférer WPF".

Bonne lecture,

... Et Stay Tuned !

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)

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 !

 

 

 

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 !

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 !)

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 !