Rendre les adresses mémoire cliquables dans WindDBG

Petite astuce donnée dans l’émission DefragTools rendant l’utilisation de WinDBG un peu plus “clicky clicky” avec la version de SOS pour .NET 4.

Par défaut, lorsqu’on affiche les objets de la stack .NET avec !dso par exemple, les adresses mémoire pointant vers les objets ne sont pas cliquables et il est necessaire de faire un :

0:000> !DumpObj xxxxxxxx

pour accéder au contenu de l’objet :

En tapant la commande :

0:000> .prefer_dml 1

on active les liens pour certaines commandes

[.NET] Linq et type dynamique, attention au piège en .NET

Problème

Le code suivant affiche « Numbers greater than 3 are : 6 7 » au lieu du « Numbers greater than 3 are : 4 5 6 7 » attendu.

Savez-vous pourquoi ?

class Program
{
    static void Main(string[] args)
    {
        List<Int32> allNumbers = new List<Int32>() { 1, 2, 3, 4, 5, 6, 7 };

        List<dynamic> greaterNumbers = new List<dynamic>();
    
        // Finding all numbers from the "allNumbers" list that are greater 
        // than "currentNumber"
        for (Int32 currentNumber = 0; currentNumber < 5; currentNumber++)
        {
            dynamic item = new ExpandoObject();
            item.Number = currentNumber;
            item.GreaterNumbers = allNumbers.Where(e => e > currentNumber);
            greaterNumbers.Add(item);
        }
        // Here greaterNumbers contains 5 items
    
        // We want to display numbers greater than 3
        dynamic greaterThan3 = greaterNumbers
                               .FirstOrDefault(i => i.Number == 3);
    
        if (greaterThan3 != null)
        {
            Console.Write("Numbers greater than 3 are : ");
            foreach (Int32 greaterNumber in greaterThan3.GreaterNumbers)
            {
                Console.Write(greaterNumber);
                Console.Write(' ');
            }
            Console.WriteLine();
        }
    }
}

Explication

Where, est une méthode d’extension proposée par LINQ. Cette méthode s’exécute en différé, c’est-à-dire que le Where ne sera exécuté que lorsqu’on voudra accéder à son résultat. Cette exécution différée est causée par la présence du mot clé « yield » dans l’implémentation de la méthode Where.

WinDBG : charger les bonnes extensions

Pour débugguer vos applications .NET, Microsoft propose un outil nommé WinDBG disponible dans le “Windows SDK”.

WinDBG étant un debugueur natif, il a besoin d’extensions pour fonctionner avec les applications .NET. Ces extensions sont différentes en fonction de la technologie et de la version de .NET que votre application utilise (Silverlight / WPF / .NET 2.0 / .NET 4, etc.).

SOS

SOS.dll (Son Of Strike) est une DLL fournie lors de l’installation du framework .NET qui se trouve dans le répertoire : C:\Windows\Microsoft.NET\Framework\

Mettre un point d'arrêt dans une DLL sur Visual Studio 2010

N’ayant pas accès au code des DLL du framework .NET, il peut être intéressant de mettre un point d’arrêt à l’intérieur de ces DLL afin de savoir quand les methodes contenues dans la DLL sont appelées.

L’objectif de cet article est de “breaker” lorsque l’on appelle la propriété Count et la méthode Clear() d’une liste (List<T>).

• Première étape, désactiver l’option “Enable Just My Code (managed only)” dans les options de debug. Pour y arriver, rendez-vous dans Debug -> Options and Settings -> Enable Just my Code (managed only), puis décochez la case.
• Deuxième étape, afficher la fenêtre “Breakpoints” dans Visual Studio 2010 : raccourci Ctrl+D+B.

Fichiers de styles et erreur "Cannot find a Resource with the Name/Key xxxx" en Silverlight

Lorsque votre application grossit (son style aussi), il est intéressant de séparer vos styles dans différents fichiers pour gagner en clareté. Il vous suffit ainsi de déclarer vos fichiers dans le fichier App.xaml comme ceci :

<Application.Resources>
  <ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
      <ResourceDictionary Source="Color.xaml" />
      <ResourceDictionary Source="Control.xaml" />
    </ResourceDictionary.MergedDictionaries>
  </ResourceDictionary>
</Application.Resources>

Ceci ne fonctionne que si le fichier Control.xaml n’utilise pas de ressources déclarées dans Color.xaml et inversement. Contrairement à WPF qui tient compte de l’ordre de déclaration (Color.xaml est avant Control.xaml), Silverlight charge les ressources de manière indépendante interdisant ainsi les références entre les diffèrents dictionnaires.

Utiliser la molette de la souris en Silverlight avec le Windowless activé sous Firefox et Chrome

En Silverlight, la molette de la souris fonctionne très bien sous tous les principaux navigateurs (Internet Explorer, Firefox, Chrome, etc.) lorsque le Windowless n’est pas activé. Lorsque ce dernier est activé, la tâche se complique puisque les navigateurs qui se basent sur NAPI (Firefox et Chrome) ne permettent plus à Silverlight de gérer la molette de la souris. Cet article permet grâce au DOM de récupérer l’événement lié à la molette auprès du navigateur.

Créer des snippets pour augmenter votre productivité sur Visual Studio 2010

Visual Studio 2010 utilise comme beaucoup d’IDE, un système de snippet permettant d’augmenter la vitesse de frappe du code.

Utilisation d’une snippet

Par exemple, si vous entrez propf puis tapez 2 fois sur la touche TAB du clavier, l’IDE va générer pour vous une propriété privée ainsi qu’un get, set :

Les zones oranges sont les zones éditables lors de la création. Il est possible de passer d’un de ces champs à un autre en pressant la touche TAB du clavier.

Comment débugger vos bindings en Silverlight 5

La version béta de Silverlight 5 béta est sortie cette semaine au MIX de Las Vegas. Une des nouveautés apportée par cette version est la possibilité de mettre des points d’arrêts (breakpoint) dans le XAML afin de débugger les bindings.

Qui n’a jamais perdu de temps à chercher pourquoi un binding ne fonctionnait pas correctement dans son application Silverlight ?

Pour illustrer cette article nous allons utiliser le code suivant (disponible en téléchargement à la fin de l’article) :

Parcours d'une liste (List<T>) et performances en Silverlight

Dans le cadre du développement d’un contrôle Silverlight devant faire un grand nombre de parcours sur une liste (List), je me suis posé la question des performances.

Que faut-il utiliser ? foreach, for, while ou ForEach contenu dans System.Linq ?

Mes tests se sont portés sur une application Silverlight classique ainsi que sur Windows Phone 7 (tests sur un vrai device).

Le test consiste à parcourir une liste d’objets de type Test (la classe Test contenant une propriété Id de type int et une propriété Name de type string). Chaque type d’itération doit mettre en majuscule la propriété Name et ajouter 1 à la propriété Id.

Session sur l'optimisation des performances Windows Phone 7

Voici mes notes sur la session de Luc Vo Van (Microsoft) et Simon Ferquel (Access IT) sur la performance et l’optimisation des applications Windows Phone 7 donnée aux techdays 2011. En attendant d’avoir la présentation Powerpoint ainsi que le webcast, voici ce que j’ai retenu de cette conférence très intéressante.

Les différents threads

Une application Windows Phone 7 dispose de 2 threads :

• le thread UI (CPU) qui s’occupe du code créé par l’utilisateur, des événements, des converters, etc…
• le thread de composition (GPU) qui s’occupe lui des animations simples, du clipping rectangulaire, de l’opacité, des render transform et perspective transform.

Le but étant de décharger au maximum le thread UI pour garder une application fluide et agréable à utiliser.