[Debug] Utiliser le débugger de Visual Studio côté client dans des classes partielles créées sur un proxy WCF

Dans le cadre d’une application utilisant un service WCF, il n’est pas rare de créer des classes partielles (partial class) côté client pour rajouter des propriétés aux objets envoyés par le service. Ces propriétés sont liées à l’application cliente (pour l’interface par exemple) et n’ont aucune raison d’être présentes côté service.

 

Par exemple une classe Produit avec les propriétés Prix, Nom, Stock définies côté service peut avoir une propriété IsVisible côté client permettant d’afficher ou non le produit sur l’interface graphique. Des méthodes peuvent également être créées dans ces classes partielles.

 

Exemple :

MyClass.cs (côté Service WCF) :

 

[DataContract]
public class MyClass
{
    [DataMember]
    public string Label { get; set; }
}

 

Partial_MyClass.cs (côté client) :

 

public partial class MyClass
{
    public bool IsVisible { get; set; }

    public void Display()
    {
        IsVisible = true;
    }
}

 

Dans la configuration par défaut de Visual Studio (Just My Code activé), les points d’arrêt (breakpoint) ne fonctionneront pas dans le code de ces classes. Avec la désactivation du "Just My Code" (Debug -> Options -> Enable Just My Code), les breakpoints fonctionneront mais ils vous sera toujours impossible de faire du StepOver  (F10) ou du StepInto  (F11).

 

La faute à l’attribut DebuggerStepTroughAttribute présent dans le fichier Reference.cs afin d’éviter au débugger de passer dans le fichier Reference.cs (proxy WCF côté client (généré par Visual Studio ou svcutil/slsvcutil),  lors des StepOver (F10) et StepInto (F11) .

 

[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute(
    "System.Runtime.Serialization", 
    "4.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(
    Name = "MyClass", 
    Namespace = "http://schemas.datacontract.org/2004/07/MyApp.Client.Web")]
public partial class MyClass : 
    object, System.ComponentModel.INotifyPropertyChanged
{

    private string LabelField;

    [System.Runtime.Serialization.DataMemberAttribute()]
    public string Label
    {
        get
        {
            return this.LabelField;
        }
        set
        {
            if ((object.ReferenceEquals(this.LabelField, value) != true))
            {
                this.LabelField = value;
                this.RaisePropertyChanged("Label");
            }
        }
    }

    public event System.ComponentModel.PropertyChangedEventHandler PropertyChanged;

    protected void RaisePropertyChanged(string propertyName)
    {
        System.ComponentModel.PropertyChangedEventHandler propertyChanged = 
            this.PropertyChanged;
        if ((propertyChanged != null))
        {
            propertyChanged(this, 
                new System.ComponentModel.PropertyChangedEventArgs(propertyName));
        }
    }
}

 

Afin de débugguer simplement, éditer le fichier Reference.cs (généré par Visual Studio) et retirer l’attribut [System.Diagnostics.DebuggerStepThroughAttribute()] des classes qui vous intéressent.

 

 

Note : Demandez à Visual Studio d’afficher "Tous les fichiers" dans l’explorateur de solution et n’oubliez pas de répéter cette opération à chaque mise à jour de la service référence.

Merci à Gaël Covain  pour son aide

[VS 2010] Mettre un point d’arrêt dans une DLL

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.
  • Cliquez ensuite sur "New" puis "Break at Function".
  • Dans la fenêtre de création, renseignez le chemin vers la méthode que vous souhaitez "breaker"
 
Pour la propriété Count, indiquez : System.Collections.Generic.List.Count qui sera automatiquement remplacé par System.Collections.Generic.List.get_Count.
Désormais, chaque fois que cette méthode et le getter de cette propriété seront appelés, Visual Studio "breakera" dessus et nous indiquera la callstack afin de retrouver d’où vient l’appel.
 

[Silverlight] Ouvrir vos fichiers XAML en mode code

Visual Studio 2010 ouvre par défaut les fichiers XAML en mode "splitté", c’est-à-dire en affichant d’une part le designer et d’autre par le code XAML. Avec l’habitude on se rend compte que la partie designer augmente le temps d’ouverture du fichier et nous fait perdre du temps. D’autant plus que la partie designer est souvent inutile.

 

Heureusement il est possible de forcer l’ouverture des fichiers .xaml en mode code (sans designer). Pour activer cette option, rendez-vous dans Tools -> Options.

 

Dans les options, dépliez Text Editor -> XAML et séléctionnez Miscellanous. Cochez ensuite la case "Always open document in full XAML view".

 

 

Le designer est toujours disponible grâce aux icônes situées en bas de page :

 

 

Lorsque vous ouvrez un fichier XAML, vous n’êtes maintenant plus ralenti par le chargement du designer.

[VS 2010] Créer des snippets pour augmenter votre productivité

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.

 

il est existe un grand nombre de snippets déjà définies dans Visual Studio (if, while, prop, propf, etc.). Pour en voir la liste, faites un clic droit dans le code -> Insert Snippet ou plus rapidement en faisant un Ctrl + K, X. Les snippets de Visual Studio sont en fait des fichiers XML disponibles dans le dossier : C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC#\Snippets\1033\Visual C# pour les snippets relatives au C#.

 

Création d’une snippet

 

Il est également possible de créer vos propres snippets directement dans Visual Studio en créant un fichier XML ayant pour extension .snippet. La structure du fichier est définie comme ceci :

 

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>MyTitle</Title>
      <Shortcut>MyShortcut</Shortcut>
      <Description>My description</Description>
      <Author>MyName</Author>
      <SnippetTypes>
        <!-- snippet types -->
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>MyField</ID>
          <ToolTip>My field tooltip</ToolTip>
          <Default>MyDefaultValue</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[string $MyField$;]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

 

En détail :

  •  
  • Title : nom de votre snippet
  • Shortcut : raccourci à taper avant de presser la touche TAB 2 fois pour afficher le contenu de la snippet
  • Description : description de la snippet
  • Author : nom du créateur de la snippet
  • SnippetTypes : type de snippet
  •  

Les snippets peuvent être de 3 types :

  1. SurroundsWith : indique vous pouvez encapsuler votre code à l’intérieur de la snippet (ex : if)
  2. Expansion : indique que le code sera insérer au niveau du curseur de la souris (ex : prop)
  3. Refactoring : indique que la snippet est utilisée pour le refactoring (ex : implementation d’une interface et insertion du throw new NotImplementedException(); dans le corps des méthodes). Il n’est pas possible de créer ce type de snippet.

 

Dans la balise Declarations, chaque balise Literal représente un champ que l’on va pouvoir modifier lors de l’utilisation de la snippet. Dans l’exemple ci-dessus, par défaut la valeur de MyField sera MyDefaultValue, mais il sera possible de la modifier très facilement. Une fois la snippet créée, le curseur se placera au début du mot MyDefaultValue et le surlignera pour faciliter sa modification. Une fois la création de la snippet terminée, pressez la touche ENTRER.

Vous l’aurez compris cette snippet permet de créer une variable de type string.

 

Installation d’une snippet

 

Maintenant que la snippet est créée, il faut l’ajouter à Visual Studio. Pour cela rendez-vous dans le menu Tools -> Code Snippet Manager ou plus rapidement avec le raccourci Ctrk + K, B.

 

 

Cliquez ensuite sur Import… et choisissez le fichier .snippet que vous venez de créer. Visual Studio va alors ajouter votre snippet au dossier C:\Users\<Name>\Documents\Visual Studio 2010\Code Snippets\Visual C#\My Code Snippets. La snippet est maintenant disponible dans Visual Studio et ce pour tous vos projets.

[WP7] Connecting to Windows Phone 7 Emulator… interminable

Si vous développez pour Windows Phone 7 sur un OS virtualisé (VMWare, Hyper-V, etc…) ou si vous utilisez un Mac avec Bootcamp, il se peut que vous rencontriez quelques problèmes lors du déploiement de fichiers .xap via Visual Studio 2010 ou directement via l’outils de déploiement.

Lors du déploiement de l’application, l’émulateur se lance est reste sur l’écran d’accueil du téléphone. Dans le coin inférieur gauche de Visual Studio 2010, la phrase "Connecting to Windows Phone 7 Emulator…".

 

 

Dans l’onglet Output :

 

 

Le déploiement bloque à cette étape…

Si on quitte l’émulateur, une erreur apparait :

 

The object invoked has disconnected from its clients.
 
Ce problème survient quasiment à chaque fois sauf généralement lors du 1er déploiement après le lancement de Visual Studio 2010. L’astuce pour éviter ce désagrément, déployer votre application au lancement de Visual Studio 2010 et ne quittait plus l’émulateur pour la suite du développement.
Cette astuce ne gène en rien le debug ou le déploiement de l’application sur l’émulateur.