Dot.Blog

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

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 ! 

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