Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

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 débogage 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).Plus...

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

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