Another .NET Blog

Voici deux astuces qui je l'espère vous feront gagner du temps lorsque vous aurez à debugger vos applications.

Ne pas s'arrêter dans une propriété / fonction

La première astuce permet de gagner du temps lorsque vous suivez l'exécution d'un programme pas à pas, et que vous ne voulez pas, même en utilisant la commande Step Into (F11) aller dans le corps de propriétés / fonctions qui ne vous intéressent pas. L'exemple le plus flagrant étant les getters des propriétés, surtout quand il n'y a aucune logique dedans.

Par exemple, en utilisant le bout de code suivant:

using System;
using System.Diagnostics;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Employee emp = new Employee("Mike", 28);

            Console.WriteLine(emp.Name);
            Console.WriteLine(emp.Age);
            Console.ReadKey();
        }

        public class Employee
        {
            private string name;
            private int age;

            public Employee(string name, int age)
            {
                this.name = name;
                this.age = age;
            }

            public string Name
            {
                [DebuggerStepThrough]
                get { return name; }
            }

            public int Age
            {
                get { return age; }
            }
        }
    }
}

Si vous mettez un point d'arrêt à la ligne : Console.WriteLine(emp.Name);, et que vous appuyez sur F11, vous allez directement à la ligne suivante, sans passer par le corps du getter de Name. Si vous ré-appuyez sur F11, vous allez cette fois-ci vous retrouver à la ligne get { return age; }.

Très pratique donc pour éviter de se retrouver dans des fonctions sans-intérêt particulier. A noter également que même si vous mettez un point d'arrêt dans le corps d'une fonction marquée par cet attribut, le debugger ne s'y arrêtera pas.

Affichage personnalisé d'une variable

Voici une petite astuce qui peut se révéler très très pratique lorsque vous êtes en plein session de deboguage dans VS, et qui peut surtout vous faire gagner du temps, dès lors que vous devez inspecter souvent les même valeurs d'une instance d'un type.

Si l'on garde le morceau de code précédent, que l'on garde le point d'arrêt au même endroit, et que l'on passe la souris au dessus de la variable emp, voici ce qu'on obtient:

Le debugger affiche le nom du type de la variable au dessous de laquelle se trouve le curseur de la souris. Si vous voulez accéder aux membres de cette variable, vous devez cliquer sur le petit +.

Si vous êtes intéressés uniquement par quelques membres de cette variable, ou si le type de la variable contient un petit nombre de membres et que vous voulez y avoir accès directement sans cliquer sur le +, voici une astuce qui vous sera certainement utile: il vous suffit d'ajouter un attribut à la déclaration de votre classe, comme suit:

[DebuggerDisplay("Employee : {Name} - {Age}")]
public class Employee
{
    //...
}

Et maintenant, lorsque vous passez la souris au dessus de la variable emp, comme précédemment, voici ce que vous deviez obtenir:

Il est bon également de savoir que cette astuce fonctionne également avec les classes dérivant de Employee. Si l'attribut DebuggerDisplay n'est pas ajouté aux classes dérivées, c'est l'affichage personnalisé de Employee qui sera utilisé. Mais si vous définissez cet attribut pour les classes dérivées de Employee, vous pourrez bien sûr faire référence aux propriétés de la classe Employee dans le constructeur de l'attribut:

[DebuggerDisplay("Boss : {Department} - {Name} - {Age}")]
public class Boss : Employee
{
    private readonly string department;

    public Boss(string department, string name, int age) : base(name, age)
    {
        this.department = department;
    }

    public string Department
    {
        [DebuggerStepThrough]
        get { return department; }
    }
}

En espérant que cela vous évitera quelques prises de tête lors de vos séances de debugging futures ;)

Surprise!

Je lance Visual Studio 2010, et alors que tout fonctionnait parfaitement bien vendredi dernier, aujourd'hui monsieur me fait un caprice et ne veut plus s'ouvrir, et me donne un message d'erreur assez laconique: "The application cannot start"

Après une petite recherche sur le web, il s'avère que cette erreur peut être due à un fichier de préférences corrompu, ou bien à une tentative d'import de police non TrueType créée avec une version de VS inférieure. Comme je n'ai jamais approché de près ou de loin ce deuxième point, je me suis donc douté que ça devait bien être le fichier des préférences (Elémentaire mon cher watson).

La solution proposée, qui a très bien fonctionné pour moi: lancer VS via la ligne de commande en utilisant le flag resetuserdata:

devenv /resetuserdata

Pour info, l'exécutable de VS2010 se trouve dans ce dossier : ''C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE''

Bien évidemment, attendez vous à perdre toutes vos customisations. Pensez donc à les sauvegarder en copiant le fichier CurrentSettings.vssettings qui se trouve ici : “%USERPROFILE%\Documents\Visual Studio 2010\Settings !

Bonne nouvelle!

Cela faisait un moment que je tentais désespérément de lancer des tests unitaires sous VS2010 avec xUnit et Resharper 5, sans succès, comme vous vous en doutez. La seule solution avait été de recompiler le GUI de xUnit en .NET 4 et de l'utiliser pour les tests. Ce que je ne trouve pas très pratique, dans la mesure où ça oblige à jongler entre plusieurs applications. C'est toujours plus simple de rester dans son environnement de travail.

Eh bien c'est désormais possible. C'est extrêmement simple, en voici la procédure:

1. Télécharger et installer la nouvelle version de Resharper 5.0, qui est désormais en Beta.
2. Télécharger la dernière version de xUnit Contrib
3. Installer xUnitContrib

Une fois ces 3 étapes faites, lancez VS2010 et ô surprise:

En voilà une bonne nouvelle pour une rentrée de Vacances :)

Par défaut, Visual Studio 2008 crée les classes sans le mot-clé public.

Voici une manière très simple de modifier ce comportement par défaut.