Gestion des Releases avec TFS

Depuis maintenant plus de 6 mois j’ai quitté Ucaya pour rejoindre l’éditeur SPI, Septeo Pôle Immobilier. Notre offre est actuellement composée de plusieurs gammes produits couvrant différents métiers de l’immobilier, tous issus de technologies variées (.Net, Cobol, 4D, VB6…). Cette multitude de produits s’explique par les différentes fusions acquisitions à l’origine de SPI.

La gestion des patchs et des versions des produits implique diverses taches de gestion et de suivi :

• Gestion du contenu de la version
• Processus de livraison du produit
• Documentation
• Prise en compte de contraintes métiers (administratives et légales)
• Communications inter-service (Hotline, Formation, Commerce, Direction…)

Au service développement nous sommes organisés en SCRUM et chaque produit possède son product backlog. Le suivi des bugs et des évolutions se fait via les work items de type Bug et Product Backlog Item. Nous avons bien évidemment apporté des customisations à ces éléments afin de répondre à nos contraintes d’organisation. Plus récemment nous avons introduit la notion de Version dans TFS en créant un nouveau type de Work Item, le type Release. Cet élément nous permet de regrouper des Work Items de type Bug ou Product Backlog Item afin de représenter l’ensemble des correctifs ou évolutions d’une version spécifique d’un produit.

Un nouveau Work Item : Release

Ce Work Item possède une date de livraison estimée, un numéro de version, un état, une liste de Bug ou de PBI et des champs qui nous sont spécifiques, comme l’illustre l’image ci-dessous :

 

L’utilisation du Front de TFS à elle seule ne permet pas de satisfaire les besoins en terme d’organisation et de suivi des versions. Il est difficile de mettre en place des indicateurs d’alerte métier (contraintes de dates spécifiques au métier, aux produits, etc…), d’avoir un suivi global des gammes ou encore de partager l’information telle qu’elle sort de TFS.

En effet le partage d’informations provenant du service développement à destination des autres services (formation, hotline, etc…) est nécessaire. Mais ces informations, définies dans le contexte du service développement et issues de TFS, ne sont pas des plus compréhensibles par tous. Nous parlons de Work Item, de backlog, de build, de release, etc… Avec la direction, les services formation, hotline…. un vocabulaire beaucoup moins technique est utilisé. Donner un accès brut et sans artifice à TFS à des personnes extérieures au service développement n’est pas la solution de part la richesse de la plateforme et de son vocabulaire spécifique.

En travaillant sur la présentation de l’information nous pouvons réussir à donner un vrai paradigme métier à la gestion des versions. Tout en nous appuyant sur TFS, nous allons pouvoir gérer nos règles et nos contraintes métiers de planification et avoir un outil de gestion des documentations et/ou des livraisons centralisées.

Un outil de gestion des releases a donc été développé afin de répondre à ces différents besoins. Il s’inscrit entièrement dans l’univers de TFS et de son Team Web Access en reprenant ses couleurs d’accent et certains concepts ergonomiques.

Consultation des versions en liste

L’affichage des versions d’un produit offre une lecture rapide de la prochaine échéance, des suivantes et des anciennes grâce aux regroupements :

Consultation des versions en vue Planning

Une vue planning des versions inter-gamme permet de mieux juger de la chronologie des éléments :

 

Consultation d’une release – Groupé par Etat

La consultation du contenu d’une release, selon différentes dimensions (état, module, type…), s’appuie également sur des regroupements pour une lecture plus naturelle.

Ici la dimension d’état pour le suivi du réalisé, planifié… L’état des work items n’est pas présenté de manière brut, il est interprété. Par exemple, un travail est considéré comme planifié selon sa propriété Iteration Path et donc s’il est planifié dans un sprint :

Consultation d’une release – Groupé par Module

La dimension par module permet de consulter le contenu d’une version d’un point de vue fonctionnel. Un regroupement est effectué sur la propriété Area Path (le Root Path correspondant au nom du Team Project est supprimé de l’Area Path à l’affichage pour une meilleure lisibilité) :

Consultation d’une release – Groupé par Type

La dimension par Type permet de juger du caractère plutôt correctif ou évolutif de la version. Ici encore, le vocabulaire de TFS (Work Item de type Bug ou Product Backlog Item) a été masqué afin de privilégier un vocabulaire plus naturel :

Accès aux informations détaillées

La notion de Tooltip a été fortement utilisée afin d’obtenir des informations plus détaillées au survol des Work Items. Et pour un accès complet au formulaire d’un Work Item, il suffit d’un double-clic dessus pour ouvrir Team Web Access sur la page de l’élément :

Gestion de la documentation d’une Release

Nous avons également enrichit nos Work Item avec des champs de documentation; documentation pouvant être à destination des clients ou des services internes :

Ceci nous permet depuis l’outil de gestion de versions, lors de sa livraison, de générer automatiquement la documentation de la version en parcourant la liste des Work Items et en agrégeant le champ Notes. Les fichiers textes ainsi générés sont mis en pièces jointes du Work Item Release. Ainsi toutes les données sont stockées dans TFS :

Gestion du contenu d’une Release

La possibilité de modifier le contenu d’une version en ajoutant ou supprimant des Bugs ou Product Backlog Item :

Et une vue de recherche avancée des éléments à livrer. Par exemple, ci-dessous on recherche les éléments d’un sprint spécifique :

Livraison d’une Release

Et pour terminer, pour l’un de nos produits, entièrement gérer avec TFS et Visual Studio (gestion des sources, des builds, etc…) nous avons également inclus le processus complet de déploiement d’une version :

Conclusion

Cet outil va nous permettre de mieux gérer et de mieux suivre les mises à jour de nos gammes produit tout en gardant TFS comme référentiel, grâce à ses API et ses possibilités d’extensions.

Modification des étapes des Test Cases depuis Visual Studio

Si vous avez testé TFS 2010 Beta 2, alors vous avez peut être remarqué qu’il était possible d’éditer les étapes des work items de type Test Case directement depuis Visual Studio. A l’arrivée de la RTM, cette fonctionnalité a été supprimée. Actuellement la seule façon d’éditer les étapes des Test Cases est de le faire depuis MTM (Microsoft Test Manager). Voici à quoi ressemble l’onglet Steps depuis Visual Studio, remarquez le bouton “Open for edit” qui permet de lancer MTM :

Avec la beta 2, nous avions ceci :

Nous allons voir ci-dessous comment modifier l’interface des Test Case pour pouvoir modifier les steps comme dans la beta 2.

En cherchant un peu on peut voir que le contrôle utilisé pour afficher les étapes est le custom control TestStepBaseControl de l’assembly Microsoft.TeamFoundation.TestManagement.Controls. Pour le retrouver il suffit de regarder à cet endroit : C:\ProgramData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\10.0\TestStepsControl.wicc

Comme tout custom control de work item, TestStepBaseControl implémente l’interface IWorkItemControl. Ce contrôle implémente également l’interface IWorkItemControlFactory. Il doit ainsi implémenter la méthode Create, que l’on peut voir ci-dessous :

Visual Studio et MTM se servent certainement de cette méthode pour obtenir une instance de ce contrôle. Comme nous pouvons le voir dans ce code, si le Host a la possibilité d’afficher un contrôle WPF alors il retourne une instance de type TestStepsCustomControl, sinon il renvoie l’instance courante, à savoir de type TestStepsBaseControl.

Le formulaire des work items de Visual Studio ne supportent que les contrôles WinForm. C’est pour cette raison que TestStepsBaseControl est un UserControl WinForm. Par contrôle, MTM est en WPF, ainsi TestStepsCustomControl est un UserControl WPF.

Pour utiliser le contrôle TestStepsCustomControl depuis Visual Studio, il suffit de créer de l’encapsuler dans un composant ElementHost, lui même encapsuler dans un User Control WinForm (le composant ElementHost permet d’hoster un contrôle WPF dans un contrôle WinForm).

• On crée un projet de type WinForm Custom Control Library.
• On ajoute les références Microsoft.TeamFoundation.TestManagement.Controls.dll et Microsoft.TeamFoundation.WorkItemTracking.Controls.dll.
• On ajoute ensuite un User Control et on lui fait implémenter l’interface IWorkItemControl.
• Dans le designer du user control, on ajoute un composant ElementHost
• Dans le code du designer, on crée un champ de type Microsoft.TeamFoundation.TestManagement.Controls.TestStepsCustomControl
• Puis on modifie le code de la méthode InitializeComponent, afin d’instancier le TestStepsCustomControl et de l’affecter à la propriété Child de l’objet ElementHost :

• Il faut ensuite mapper les méthodes de l’interface IWorkItemControl sur le custom control :

• Il ne reste plus qu’à compiler
• On copie la sortie dans le répertoire C:\ProgramData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\10.0
• On crée un fichier TestStepsControl2.wicc comme ceci :

Le contrôle est maintenant déployé. La dernière étape consiste à éditer le formulaire du Work Item pour qu’il utilise notre nouveau contrôle. Le plus simple est d’utiliser les power tools. Après avoir installé les power tools de TFS, il suffit d’éditer le type de work item Test Case (Menu Tools>Process Editor>Work Item Type>Open WIT from Server). Dans l’onglet Layout, on retrouve le TabPage Steps, il suffit de modifier la propriété Type du contrôle utilisé pour afficher le champ Microsoft.VSTS.TCM.Steps :

La manip est terminée. Il ne reste plus qu’à ouvrir un Test Case et vérifier que les étapes sont maintenant éditable depuis Visual Studio :

Et comme par magie, on peut maintenant éditer les étapes de nos Test Case depuis Visual Studio!!

TFS Membership Visualizer : Mon 1er addin Visual Studio 2010

Je vous l’ai présenté cette semaine, TFS Membership Visualizer est un petit outil qui permet de visualiser un graphe de dépendances des groupes TFS et de leurs membres.

Je me suis dit qu’il serait sympa de l’intégrer directement dans Visual Studio. J’ai donc développé une extension VS que vous pouvez télécharger directement depuis l’Extension Manager de Visual Studio 2010.

Vous pouvez également le télécharger sur le site des extensions de Visual Studio ou télécharger le code source sur le projet Codeplex associé.

(Vous remarquerez également l’arrivée de BOWIE dans l’extension manager 🙂 )

Affichage des Groupes TFS et de leurs membres

TfsGroupMembershipVisualizer.zip

 

Si vous suivez l’actualité de TFS via le blog de Brian Harry, alors vous remarquerez que je rebondis sur l’un de ses derniers posts, à savoir comment visualiser de manière synthétique les memberships des groupes TFS.

Peut être l’avez vous déjà constaté, la visualisation des membres des groupes de sécurité de TFS n’est pas très pratique. Des groupes sont définis au niveau du serveur TFS, au niveau de la collection ou encore ou niveau des projets. Il n’existe actuellement aucun moyen simple de visualiser les membres de ces groupes de manière synthétique. La seule solution est d’afficher chaque boite de dialogue de gestion des groupes à tous les niveaux (serveur, collection, projets).

Comme le suggère Brian Harry, il est tout à fait possible de développer un outil avec les API de TFS. C’est d’ailleurs ce que j’avais fait pendant mes congés d’été mais je n’avais pas encore eu le temps de poster.

Le code que je vous propose est tout simplement une application Windows qui va vous permettre de sélectionner les projets depuis un serveur TFS et de générer un graphe de dépendances entre les différents groupes et membres :

Une fois les projets sélectionnés il vous suffit de cliquer sur Generate Dependency Graph et Visual Studio s’ouvrira afin de vous présenter le graphe de dépendances :

Le graphe de dépendances est pour moi la meilleure des manières d’avoir une vue synthétique des memberships. Et on bénéficie en plus de tous les avantages de DGML, en terme de visualisation, navigation ou de sélection.

Pour l’instant je génère un DGML en utilisant Linq To XML et donc un XDocument. Cependant il existe également une API qui facilite la génération de DGML. A creuser pour la prochaine fois…

BOWIE 2010 pour TFS 2010 RTM est disponible

Cette semaine j’ai publié une nouvelle version de BOWIE.

La précédente version était une beta qui fonctionnait pour TFS 2010 RC, celle-ci supporte TFS 2010 RTM.

En plus de supporter TFS 2010 RTM, cette nouvelle version corrige les bugs qui avaient été remontés sur la Beta. Au niveau des nouveautés, vous pouvez maintenant gérer vos alertes comme dans Visual Studio :

BOWIE 2010 fonctionne pour TFS 2008/2010 et Outlook 2007. Il est compatible Outlook 2010. Cependant je travaille actuellement sur une nouvelle version qui fonctionnera exclusivement sur Outlook 2010 afin de bien s’intégrer au nouveau Ribbon.

BOWIE 2010 en vidéo

Hier je me suis attaqué à l’upgrade de BOWIE sur la version RC de TFS 2010, qui sera disponible sur Codeplex en fin de semaine.

Pour cette occasion, voici une interview menée par Patrice Lamarche et qui présente les fonctionnalités de BOWIE 2010.

Si vous ne connaissez pas encore cet addin TFS pour Outlook c’est l’occasion de le
découvrir en images!

BOWIE 2010 BETA est disponible !!!!

Comme l’indique clairement le titre, la version 2010 de mon addin TFS pour Outlook est disponible en version beta. Il fonctionne pour Outlook 2007 et 2010 et TFS 2008 et 2010 beta 2. Quelques uns de mes collègues me servent actuellement de beta testeur (merci Lio et Io).

Vous retrouverez sur la page d’accueil du projet codeplex la liste des fonctionnalités disponibles.

Pour le télécharger, ça se passe par là —> http://bowie.codeplex.com

N’hésitez pas à m’envoyer vos remarques, suggestions, bugs…

Utiliser l’API des Builds du TFS SDK pour les afficher dans un calendrier Outlook

Depuis quelques temps je me suis remis au développement de BOWIE. Voulant absolument découvrir l’API de gestion des Builds du SDK de TFS, je me suis creusé les méninges afin de trouver une fonctionnalités intéressantes pour pouvant s’intégrer de façon originale dans Outlook.

Sachant qu’une Build :

• s’exécute à un temps T1
• se termine à un temps T2
• et possède un certain status (Accepted, Failed…),

une Build peut donc être représentée dans un calendrier Outlook par un rendez-vous avec :

• une date de début
• une date de fin
• une catégorie représentant le status
• une zone permettant d’afficher le détail de la Build, comme dans Visual Studio

On peut également aller plus loin en représentant dans le calendrier les définitions de Build. Dans certain cas, nous créons des définitions de Build récurrentes. Ces définitions de Build récurrentes définissent :

• un pattern de récurrence (journalier, hebdomadaire…)

Ce type de définition de Build peut donc être représentée par un rendez-vous récurrent dans un calendrier Outlook. Nous pourrions par exemple en ouvrant le rendez-vous, proposer une interface permettant d’éditer la définition, ou encore de démarrer une nouvelle Build.

Après avoir mis à plat toutes ces idées, il ne reste plus qu’à trouver les points d’entrées dans le TFS SDK. Tout d’abord nous avons besoin des références suivantes :

• TeamFoundation.Client
• TeamFoundation.Build.Client
• TeamFoundation.Build.Common

La récupération de toutes les Builds d’un projet nécessite une instance de la classe TeamFoundationServer que l’on obtient à l’aide de la classe TeamFoundationFactory.

Ensuite il faut récupérer l’API du serveur de Build via la méthode GetService<IBuildServer>(). Enfin il ne reste qu’à appeler la fonction QueryBuilds(string projectName) en lui spécifiant un nom de Team Project :

            TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer("http://ServerUri");
            IBuildServer bserver = tfs.GetService<IBuildServer>();
            IBuildDetail[] details = bserver.QueryBuilds("TeamProjectName");

Maintenant que nous avons nos Builds, il nous faut les parcourir et créer des rendez-vous dans le calendrier pour chacune d’elle… et ne pas oublier de stocker l’Uri de la Build dans les UserProperties de l’Appointment :

            AppointmentItem appt = folder.Items.Add(OlItemType.olAppointmentItem) as AppointmentItem;
            appt.Start = item.StartTime;
            appt.End = item.FinishTime;
            appt.Subject = item.BuildDefinition.Name + " - " + item.Status.ToString();
            appt.ReminderSet = false;
            appt.UserProperties.Add("BuildUri", OlUserPropertyType.olText);
            appt.UserProperties["BuildUri"].Value = item.Uri.ToString();

Après quelques petits efforts on arrivera facilement à faire un petit formulaire dans ce style :

Pour l’affichage du rapport d’exécution d’une Build on peut utiliser une FormRegion dans le formulaire d’un Appointment.

On récupère l’Uri de la Build dans les UserProperties de l’Appointment. Puis toujours avec l’API du serveur de Build on récupère les détails d’exécution via la méthode GetAllBuildDetails(Uri buildUri) :

            TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer("http://TeamServerUri");
            IBuildServer bserver = tfs.GetService<IBuildServer>();
            IBuildDetail details = bserver.GetAllBuildDetails(new Uri("BuildUri"));

Un objet BuildDetail, comme son nom l’indique, contient toutes les informations d’une Build : l’heure d’exécution, le temps d’exécution, le numéro de build, les étapes de la build, le work item

éventuellement créé, le status, le chemin du fichier de log, la liste des erreurs, des warnings, la configuration… bref vraiment toutes les infos.

Le code ci-dessous nous montre comment récupérer certaines de ces informations :

            // Numéro de la Build
            lblBuildNumber.Text = details.BuildNumber;

            // Emplacement du Log
            lnkLogPath.Text = details.DropLocation;

            // Dernière Modification
            lblSummary.Text = string.Format("Build last modified by {0} {1:0.0} hours ago rn", details.LastChangedBy, (DateTime.Now - details.LastChangedOn).TotalHours);

            // Plateforme
            lblErros.Text += configuration.Fields[InformationFields.Platform] + " | " + configuration.Fields[InformationFields.Flavor] + "rn";

            // Nombre d'erreurs et de warnings
            lblErros.Text += configuration.Fields[InformationFields.TotalCompilationErrors] + "error(s), " + configuration.Fields[InformationFields.TotalCompilationWarnings] + "warning(s) rn";

            // WorkItem créé
            foreach (IBuildInformationNode node in details.Information.GetNodesByType(InformationTypes.OpenedWorkItem, true))
            {
            lnkBug.Text = string.Format("Bug {0}", node.Fields[InformationFields.WorkItemId]);
            lblState.Text = string.Format("Current state is {0}, currently assigned to {1} rn", node.Fields[InformationFields.Status], node.Fields[InformationFields.AssignedTo]);
            }

            // Le détail des erreurs (fichier, numéro de ligne, message)
            foreach (IBuildInformationNode item in details.Information.GetNodesByType(InformationTypes.BuildError, true))
            {
            lblErros.Text += "    " + item.Fields[InformationFields.File] + " (" + item.Fields[InformationFields.LineNumber] + "): " + item.Fields[InformationFields.Message] + " rnrn";
            }

Le code précédent donne le résultat suivant :

Comment retrouver l’adresse du Team System Web Access avec le TFS SDK 2010 ?

Pour continuer la découverte du TFS SDK, je vous propose de découvrir comment retrouver l’adresse du Team System Web Access (TSWA) d’un serveur Team grâce au TFS SDK. Pour info je n’ai trouvé aucune documentation concernant cette partie du SDK sur la MSDN.

Pourquoi avoir besoin de récupérer les URL ? Tout simplement lorsque l’on étend les fonctionnalités de TFS vers d’autres outils tiers. Par exemple, dans une fonctionnalité de BOWIE 2010 d’envoie de Work Items par mail, je voulais, pour chacun des work items, avoir un lien qui pointe vers la page d’édition du work item comme indiqué ci-dessous :

Pour cela nous avons besoin d’une instance de la classe TeamFoundationServer que l’on trouve dans l’assembly Microsoft.TeamFoundation.Client.dll. Il faut ensuite récupérer une instance de la classe TswaClientHyperlinkService via la méthode GetService de l’objet TeamFoundationServer :

            TeamFoundationServer server = TeamFoundationServerFactory.GetServer("http://localhost:8080/tfs/DefaultCollection");
            TswaClientHyperlinkService tswa = server.GetService<TswaClientHyperlinkService>();

Grâce à cette classe nous allons pouvoir récupérer les url du Team System Web Access. Dans mon cas, pour récupérer l’url d’un work item à partir de son Id, il suffit d’utiliser la méthode GetWorkItemEditorUrl(int id) :

            int wiId = 3;
            Uri wiUri = tswa.GetWorkItemEditorUrl(wiId);

On obtient une URL du style : http://localhost:8080/tfs/web/wi.aspx?pcguid=7e6d1e34-000d-4adb-ad5e-93db70187570&id=3

Cette URL permet d’accéder à la page suivante :

Voici quelques unes des méthodes de la classe TswaClientHyperlinkService permettant de récupérer les url d’objets TFS:

• GetChangesetDetailsUrl(int changeSetId)
• GetHomeUrl(Uri projectUri)
• GetShelvesetDetailsUrl(string shelvesetName, string shelvesetOwner)
• GetSourceExplorerUrl(string serverItemPath)
• GetViewBuildDetailsUrl(Uri buildUri)
• GetWorkItemQueryEditorUrl(Uri projectUri, string queryPath)
• …

La prochaine fois je vous ferai découvrir l’API de Build du TFS SDK, via le type IBuildServer.

StoredQueryCollection vs QueryHierarchy

Après les collections de projets, une autre évolution de TFS 2010 c’est la possibilité d’organiser les requêtes d’un projet dans un arbre de répertoires.

SDK TFS 2008 et la classe StoredQueryCollection

Avec TFS 2008, nous avons juste la possibilité de ranger les requêtes par “Team Queries” et My Queries”. Il est donc assez facile de créer une combobox présentant la liste des requêtes d’un projet afin d’en sélectionner une et d’en afficher le résultat :

La récupération des requêtes se fait depuis la classe Project par la propriété StoredQueries qui nous retourne une instance de StoredQueryCollection :

            WorkItemStore store = new WorkItemStore("serverName");
            Project project = store.Projects["projectName"];
            StoredQueryCollection storedQueries = project.StoredQueries;

Pour remplir notre combobox il suffit de parcourir une première fois la liste StoredQueryCollection afin de récupérer les requêtes publique (Team Queries) puis une seconde fois pour récupérer les requêtes privées (My Queries) :

        this.comboBox1.Items.Add(new QueryItem("  ----- Team Queries -----"));
        foreach (StoredQuery query in storedQueries)
        {
            if (query.QueryScope == QueryScope.Public)
            {
                this.comboBox1.Items.Add(new QueryItem(query));
            }
        }

        this.comboBox1.Items.Add(new QueryItem("  ----- Private Queries -----"));
        foreach (StoredQuery query2 in storedQueries)
        {
            if (query2.QueryScope != QueryScope.Public)
            {
                this.comboBox1.Items.Add(new QueryItem(query2));
            }
        }

SDK TFS 2010 et la classe QueryHierarchy

Aujourd’hui avec TFS 2010 nous avons la possibilité de mieux ordonner les requêtes d’un projet. Le treeview du TeamExplorer illustre bien la nouvelle organisation des requêtes :

Dans cet exemple nous allons recréer ce treeview. Mais tout d’abord, intéressons-nous au modèle objets du TFS SDK 2010.

Le diagramme ci-dessous montre que le modèle objets des requêtes est basé sur le pattern Composite. En effet, on retrouve une classe abstraite QueryItem, une classe spécialisée QueryFolder, héritant de QueryItem et possédant une liste de QueryItem et une classe QueryDefinition, qui est la feuille de l’arbre, c’est à dire une requête. Il ne reste plus qu’à parcourir ce graphe d’objets afin de se créer son Treeview.

Première chose, récupérer la hiérarchie de requêtes. De la même façon que l’on récupérait la liste des StoredQueries avec le TFS SDK 2008, on va récupérer l’objet QueryHierarchy depuis une instance de Project, puis parcourir cette hiérarchie :

            WorkItemStore store = new WorkItemStore(@"serverNamecollectionName");
            Project project = store.Projects["projectName"];
            QueryHierarchy queryHierarchy = project.QueryHierarchy;
            LoadQueries(queryHierarchy, null);

La méthode LoadQueries crée d’abord un noeud représentant le répertoire courant puis parcours les sous-éléments. On retrouve ici un appel récursif dans le cas où l’on itère sur un objet de type QueryFolder :

        public void LoadQueries(QueryFolder queryFolder, TreeNode parentNode)
        {
            TreeNode folderNode = CreateQueryItemNode(queryFoldern parentNode);
            foreach (var item in queryFolder)
            {
                if (item is QueryFolder)
                    LoadQueries((QueryFolder)item, folderNode);
                else
                    CreateQueryItemNode(item, folderNode);
            }
        }

La méthode CreateQueryItemNode est assez simple. Il suffit juste de créer un noeud dans le treeview :

        private void CreateQueryItemNode(QueryItem query, TreeNode parentNode)
        {
            TreeNode queryNode = new TreeNode(query.Name);
            if (parentNode != null)
                parentNode.Nodes.Add(queryNode);
            else
                this.treeview1.Nodes.Add(queryNode);

            return queryNode;
        }

On obtient un treeview semblable à celui du TeamExplorer. Il ne reste plus qu’à ajouter les icônes et à modifier les ImageIndex de chaque noeud. Pour l’améliorer on préférera également un chargement asynchrone et des objets TreeNode spécialisé tel que FolderNode et QueryNode :

Tout ceci sera bien sûr disponible dans mon addin Outlook WorkItems Extension en version 2010 prévu (normalement) pour fin novembre.