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

Astuce : recenser rapidement l'utilisation d'une classe dans une grosse solution

Comment recenser toutes les utilisations d'une classe précise dans une grosse solution pleine de projets ?

Certains proposeront d'utiliser la fonction "find usage" de Resharper. Certes mais tout le monde n'a pas cet add-in. Et même si vous l'avez, vous n'êtes pas sûr que là où vous aurez à intervenir il sera toujours là...

D'autres proposeront le Ctrl-F. C'est pas mal mais ça trouvera aussi les bouts de texte qui citent la classe ou qui contiennent le nom de cette dernière. Les plus torturés proposeront alors d'utiliser une expression régulière. Techniquement c'est mieux mais concevoir une belle ER qui fasse bien le boulot, tout le monde ne sait pas forcément faire.

Non, moi je vous parle d'un moyen ultra simple et absolument sûr de trouver toutes les utilisations d'une classe dans des tas projets en quelques secondes sans trop se fatiguer.

... Vous séchez ? Alors voici la réponse : l'attribut Obsolete.

C'est tout bête, c'est une utilisation un peu détournée de la chose il faut l'avouer, mais il suffit d'ajouter devant la définition de la classe en question l'attribut
[Obsolete("blabla")]
public class TheClassARepérer ...
 
et l'affaire est jouée. Faites un Rebuild de la solution et dans les warnings vous aurez la liste de tous les endroits où la classe est utilisée. Un double-clic vous amènera directement dans le code en question.

Quand l'opération est terminée, il suffit de supprimer l'attribut. La manip est ultra légère, peu de chance d'introduire un bug, et si on onblit l'attribut ça se verra tout de suite dans les warnings.

Malin non ?

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

Un générateur de code C#/VB à partir d'un schéma XSD

Générer du code C# depuis un schéma XSD est un besoin de plus en plus fréquent, XML étant désormais omniprésent. On trouve dans le Framework l'outil "xsd.exe" qui permet une telle génération toutefois elle reste assez basique. C'est pour cela qu'on trouve aussi des outils tiers qui tentent, chacun à leur façon, d'améliorer l'ordinaire.

XSD2Code est un de ces outils tiers. Codé par Pascal Cabanel et releasé sur CodePlex, c'est sous la forme d'un add-in Visual Studio que se présente l'outil (le code source contient aussi une version Console).

Son originalité se trouve bien entendu dans les options de génération qui prennent en compte INotifyPropertyChanged ainsi que la création de List<T> ou ObservableCollection<T>. D'autres options comme la possibilité de générer le code pour C# ou VB.NET, le support des types nullable, etc, en font une alternative plutôt séduisante à "xsd.exe". La prise en compte des modifications de propriété (et la génération automatique du code correspondant) autorise par exemple le DataBinding sous WPF ou Silverlight... A ne pas négliger surtout que Silverlight 2 est releasé officiellement depuis hier !

Comme Pascal suit ce blog il pourra certainement m'éclairer sur le pourquoi d'un petit dysfonctionnement (j'ai aussi laissé un message dans le bug tracker du projet): lorsque l'add-in est installé, et après l'avoir activé dans le manager d'add-in je ne vois hélas pas l'entrée de menu apparaître sur le clic-droit dans l'explorateur de solution (sur un fichier xsd bien sûr). Heureusement, le code source étant fourni sur CodePlex et le projet intégrant une version console de l'outil j'ai pu tester la génération de code C# en ligne de commande. Il est vrai que l'intégration de l'outil dans l'IDE est un sacré plus que je suis triste ne n'avoir pu voir en action :-( Peut-être s'agit-il d'un problème lié au fait que ma version de VS est en US alors que mon Windows est en FR ? Cela trouble peut-être la séquence qui insère la commande dans le menu contextuel ?

Un petit détail à régler donc, mais dès que j'ai des nouvelles je vous en ferai part (Pascal tu peux aussi laisser la solution en mettant un commentaire à ce billet si tu veux).

Le projet XSD2Code est fourni en deux versions, code source et setup près à installer. Pascal a même créé une petite vidéo montrant l'add-in en action.

Un outil qui, même en version console, remplace avantageusement "xsd.exe" et qui a donc toutes les raisons de se trouver dans votre boîte à outils !

Bon dev

Et Stay Tuned ! 

XAML Power Toys mis à jour pour WPF .NET 3.5 SP1 et Silverlight 2 !

Les XAML Power Toys sont des petits outils bien pratiques qui s'intègrent à Visual Studio 2008, leur mission : générer du code XAML pour des tas de situations et ainsi simplifier le codage.

Laissons l'auteur des XAML Power Toys dire à quoi ils servent :

"L'objectif principal de XAML Power Toys est de fournir des outils qui permettent aux développeurs de rapidement mettre en page et maintenir des formulaires de type business en utilisant les contrôles d'I.U. livrés avec Visual Studio."
(The primary goal of XAML Power Toys is to deliver tools that enable developers to quickly layout and maintain Line of Business Application forms using the UI controls that ship with Visual Studio.)
Bon, c'est pas forcément plus clair dit comme ça... Alors le mieux, vous savez quoi ? ... et bien c'est d'aller sur le site de ce bon Karl et de regarder les captures d'écran et les exemples qu'il y commente !
XAML Power Toys est en tout cas un add-in à posséder, il rend vraiment service lorsqu'on travaille sous VS. On préfèrera certainement l'aspect visuel de Expression Blend pour modifier du XAML mais lorsqu'on développe une application WPF ou Silverlight on a de toute façon VS et Blend ouverts en même temps, l'un pour le visuel, l'autre pour le code C# et quand on est sous VS, il est parfois plus rapide de modifier le code XAML "à la main" pour certaines choses que de switcher sur Blend. Donc même quand on travaille avec les deux EDI à la fois, ces petits "jouets puissants" (Power Toys !) sont des aides à ne pas négliger !
Bon XAML
... Et 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)

Créer des documents XAML directement depuis Word 2007

XAML, le langage de description graphique de WPF et Silverlight, est un format XML offrant une grande souplesse pour représenter aussi bien des graphismes en 3D que des fenêtres Windows et leur contenu en passant par les animations, les sites Web ou les flux vidéo et j'en oublie des tonnes... Tout comme HTML il est possible de taper les balises à la main. C'est formateur mais peu productif !

Je me rappelle d'une époque où un "vrai" développeur Web, "un dur, un tatoué", se devait de développer tout un site en HTML uniquement avec le bloc-notes, se servir de DreamWeaver ou autres logiciels de mise en page dédié était un truc de fillette ("les durs, les tatoués" utilisent bien entendu d'autres mots qui tombent sous le coup de la censure anti homophobie...). On retrouve ce réflexe de geek autiste avec toute nouvelle technologie et certains aujourd'hui mettent un point d'honneur à faire une application Silverlight ou WPF en tapant tout le XAML à la main... Même si l'aspect formateur de la chose que je soulignai plus haut possède un certain attrait, cette démarche est loin d'être la plus productive. Il existe en effet des logiciels comme Expression Blend ou même VS 2008 qui offre une approche visuelle de XAML, ce qui est le minimum pour une technologie justement basée sur le visuel !

De fait, qu'il s'agisse d'une application Silverlight ou d'une application desktop WPF ou XBap, il arrive souvent qu'on ait du texte à présenter. Et quitte à écrire des tartines à l'écran, autant que cela soit gracieux...

C'est là que ça se complique... Car bien entendu ni Blend ni VS 2008 ne sont des traitements de texte...

On se demande alors s'il n'y aurait pas une façon élégante d'utiliser Word puis de récupérer le document en XAML, bout de code qu'il n'y aurait plus qu'à coller dans son application.

Si, c'est possible ! ((c) Hassan Céhef, Les Nuls).

En utilisant Word 2007 et le plugin Word 2007 XAML Generator dont le code binaire et le code source .NET sont téléchargeables ici.

Ce plugin pour Word 2007 est intéressant à plus d'une titre. Outre sa fonction première qui est bien utile, le code source illustre la façon d'écrire des plugins pour Word 2007 ce qui donnera peut-être des envies à certains d'entre vous !

Partons d'un document Word (on voit l'onglet XAML, non affiché sur cette capture, en fin de ligne de la barre d'outils) :

 

Une fois le plugin installé, en appelant le menu "enregistrer sous" nous trouvons une option "XAML" (je vous fait grâce de la copie d'écran de ce menu). Il n'y a plus qu'à donner un nom de fichier et à valider. Nous voici maintenant en possession d'une fichier XAML qui contient notre document Word sous la forme d'un FlowDocument si on a choisi une exportation WPF ou un TextbBlock pour Silverlight.

Pour visualiser le résultat rapidement je vous conseille l'excellent freeware Kaxaml. La capture ci-dessous montre dans sa partie supérieure le FlowDocument contenant notre document Word "xamelisé" et, dans sa partie inférieure, le code XAML créé par le plugin. Une fois ce dernier copié/collé dans votre application vous aurez l'assurance d'un visuel de grande qualité. Tout d'abord le texte sera contrôlé (orthographe et grammaire de Word) limitant les coquilles (pas comme sur ce blog pour lequel je n'ai pas de correcteur!), mais il disposera aussi d'une mise en page riche avec des styles cohérents. Enfin, sa représentation à l'écran sera conforme à l'idée qu'on se fait d'une texte propre et professionnel affiché par une application de type WPF ou Silverlight.  Que des avantages donc.

 

On notera que le plugin affiche aussi une barre d'outil dans Word 2007 permettant de régler certains paramètres et d'effectuer le choix entre une exportation WPF ou Silverlight (qui utilise un TextBlock au lieu d'un FlowDocument). La fonction de preview qui est aussi disponible dans la barre d'outils est particulièrement appréciable.

Voici le FlowDocument intégré dans une fenêtre WPF:

Savoir faire fonctionner tous les outils ensemble pour produire des applications riches est une grande force, disposer de petits logiciels ou plugins tels que Word 2007 XAML Generator permet de combler le gap entre certains de ces outils, de faire un pont. Un pont c'est bête, parfois juste une petite planche posée au-dessus d'une tranchée de chantier. Mais qu'est-ce que ça change la vie !

Bon Dev

... Et Stay Tuned !