Si vous aussi vous rechercher une solution pour effectuer des recherches dans les fichiers de code source de TFS, voici un article qui devrait vous intéresser.

Dans cet article, nous mettons en place une solution d’indexation des source TFS basée sur la recherche Full Text de SQL Server et Team Build.

La problématique est dans le titre : comment peut-on lancer l’exécution d’une build à partir d’une autre ? D’autre part, j’aimerai également que la build maitre, attende la fin de l’exécution de la build enfant, et en fonction de son statut qu’elle s’arrête ou continue.

La première chose à faire est de développer une activité Workflow Foundation qui va permettre de lancer l’exécution d’une build :

• Créer un nouveau projet de type Activity Library
• Ajouter les références suivantes : Microsoft.TeamFoundation.Client, Microsoft.TeamFoundation.Build.Client
• Ajouter une Code Activity. Voici le code de notre activité :

   1:  [BuildActivity(HostEnvironmentOption.All)]

   2:  public sealed class QueueDemoDefinitionBuildActivity : CodeActivity

   3:  {

   4:      private const string TfsCollectionUri = "http://localhost:8080/tfs/defaultcollection";

   5:      private const string BuildDefinitionName = "DemoDefinition";

   6:      private const string TeamProjectName = "Demo";

   7:   

   8:      public OutArgument<IQueuedBuild> Build { get; set; }

   9:   

  10:      protected override void Execute(CodeActivityContext context)

  11:      {

  12:          var collection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri(TfsCollectionUri));

  13:          collection.EnsureAuthenticated();

  14:   

  15:          IBuildServer buildServer = (IBuildServer)collection.GetService(typeof(IBuildServer));

  16:   

  17:   

  18:          var buildDefinition = buildServer.GetBuildDefinition(TeamProjectName, BuildDefinitionName);

  19:   

  20:   

  21:          var buildRequest = buildDefinition.CreateBuildRequest();

  22:   

  23:          var queuedBuild = buildServer.QueueBuild(buildRequest);

  24:          

  25:          Build.Set(context, queuedBuild);

  26:      }

  27:  }

Le principe est simple :

• On récupère le service de build depuis la collection de projets.
• On récupère ensuite la définition de la build.
• Et enfin on met en file la build via la méthode QueueBuild.

Dans notre activité, on remarque le paramètre de sortie Build de type IQueuedBuild que l’on “set” à la fin de l’activité. Nous verrons par la suite à quoi il va servir.

Il ne reste plus qu’à compiler, à déployer notre assembly dans le source control et enfin d’indiquer au contrôleur de Build où se trouvent notre custom assembly.

Pour illustrer cet exemple, j’ai créé un nouveau template de build xaml dans lequel je fais simplement appel à ma nouvelle activité comme ceci :

Pour récupérer le paramètre de sortie de cette activité, il nous faut déclarer une variable au niveau de la séquence :

Ensuite dans les propriétés de l’activité QueueDemoDefinitionBuildActivity on récupére le paramètre de sortie dans notre variable :

Comme je le disais au début de mon post, je veux que ma build maitre attende le résultat de la build enfant.

Nous avons donc besoin d’une boucle While. Sa condition de sortie est que le statut de la build est soit annulé soit terminé :

Dans le Body de cette boucle nous allons ajouter une activité de type Delay, de manière à attendre quelques secondes (ou minutes) avant de revérifier le statut. Nous avons également besoin d’appeler la méthode Refresh sur notre objet IQueuedBuild. En effet les propriétés de notre variable ne se mette pas automatiquement à jour. Un appel à la méthode Refresh est donc nécessaire.

Les 2 activités dont nous avons besoin sont présentes dans la toolbox à cette endroit :

Dans l’activité While, on ajoute une activité de type séquence, puis on ajoute les activités Delay et InvokeMethod comme ceci :

On paramètre l’activité Delay :

Pour l’activité InvokeMethod, il faut indiquer l’objet sur lequel la méthode doit être appelée, en l’occurrence QueuedBuild et le nom de la méthode, Refresh. La méthode Refresh prend en paramètre d’entrée une valeur de l’énumération QueryOptions. Dans les propriétés de l’activité InvoMethod, il est possible de renseigner les paramètres d’entrée et de sortie :

Une fois que l’on sort de la boucle, cela signifie que la build est terminée. Mais la propriété Status de l’objet QueuedBuild ne nous dis pas si la build est dans l’état Fail ou Success. Pour celà il faut accéder à la propriété suivante : QueuedBuild.Build.Status. Mais encore une fois il faut appeler la méthode Refresh sur la propriété Build :

Et maintenant, on met à jour le statut de la build maitre en fonction du résultat de la build enfant à l’aide d’une activité SetBuildProperties,

que l’on paramètre de cette manière :

Une fois notre workflow de build terminé, on crée une définition de build basée sur ce template :

Avant de lancer l’exécution de la build, il faut vérifier que le service de build à la possibilité d’exécuter plusieurs build simultanément. Si ce n’est pas le cas, lorsque la build maitre va lancer l’exécution de la build enfant, la build enfant va attendre que la première soit terminée pour s’exécuter. Et la première va attendre que la build enfant soit terminée aussi… Donc pour vérifier ça, ouvrir la console d’administration de TFS sur le serveur de Build et vérifier la concurrence des builds au niveau des propriétés du contrôleur :

On peut maintenant tester et lancer la Master Build. Si on regarde le log d’exécution, on peut voir notre boucle d’attente pendant que l’autre build s’exécute :

Depuis la liste des builds en cours d’exécution on aperçoit nos 2 builds :

Et enfin au niveau des résultats, si la build enfant échoue alors la master échoue également :

Brian Harry a annoncé cette semaine la sortie des Service Packs 1 de Visual Studio et de Team Foundation Server 2010 en version Beta. Ils sont actuellement disponibles uniquement pour les abonnés MSDN, mais devraient être téléchargeable par tout le monde dans les jours qui suivent.

Vous pouvez retrouver plus de détails sur le contenu de ces Service Packs directement sur son blog. Il précise notamment que près de 1000 bugs ont été corrigés!! Ca fait rêver ;)

Parmi les nouvelles fonctionnalités nous pouvons noter qu’il sera maintenant possible d’exécuter les tests unitaires en 3.5. Actuellement les tests unitaires s’exécutent obligatoirement en 4.0 et utilisent la compatibilité 3.5 pour tester des applications 3.5.

On peut également noter une grande nouveauté au niveau de l’Intellitrace, c’est le support tant attendu du 64 bits (et de Sharepoint également). Comme je le soulignais dans cet article sur le développement 64 bits, Microsoft continue ses efforts à ce sujet.

Du côté de Silverlight, les tools de la version 4.0 sont inclus dans ce service pack. Au passage, Scott Guthrie nous annonçait la semaine dernière les nouveautés de Silverlight 5 qui devrait être disponible en version béta au printemps 2011 (surement pour le MIX). Et dans Silverlight 5, côté développeur et testeur on notera le support du debug des expressions de binding et le support des tests d’interfaces automatisés (déjà disponible pour Silverlight 4 dans le Feature Pack 2 de Visual Studio 2010).

Et enfin, toujours du côté de Silverlight, ce Service Pack contient un outil d’analyse des performances spécifique à Silverlight.

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

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 :) )

Les congés arrivent à leur fin pour pas mal de monde, il est donc temps de faire le bilan de l’été et de se remettre au travail!

Pour moi l’été a très bien commencé, puisque j’ai été récompensé du titre MVP Visual Studio ALM par Microsoft. Ensuite, à part faire les fêtes de la Madeleine je me suis motivé à passer la certification 70-512 Administration de TFS 2010. Pas de grande surprise, tous les points sont abordés : installation et configuration de TFS, Lab Management, TFS Proxy, Build… Bref, tous les sujets annoncés sur Microsoft Learning sont abordés dans l’exam. Actuellement Microsoft ne fournit aucun cours ni bouquin pour le préparer. Toutefois une bonne connaissance de TFS, du guide d’installation et du guide d’administration suffisent.

L’été continue à être agité pour moi puisque je découvre actuellement XNA et Windows Phone 7. D’ailleurs à ce sujet, je vous conseille d’aller voir cette magnifique vidéo de Nova4Phone qui participe au concours WP7 (si vous aimez, “likez” et faites tourner la vidéo). Nova4Phone est le moteur 3D pour Windows Phone développé par David Catuhe, qui tourne sur un vrai device. La fluidité est époustouflante! Like, like, like!

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.

La semaine dernière j’ai testé la migration d’un serveur TFS 2010 d’une machine A vers une machine B et je vous propose de découvrir ici les différentes étapes pour y arriver.

Cet article aborde la migration des composants suivants :

• le serveur TFS 2010 et ses collections,
• le serveur Reporting Services,
• le site SharePoint

1/ Détacher la collection de projets du serveur A

Lancer Team Foundation Server Administration Console, aller dans Application Tier, puis dans Team Project Collections.

Sélectionner la collection à détacher, puis dans l’onglet général cliquer sur Detach collection :

Le wizard suivant s’ouvre et nous invite à cliquer sur Next et Verify :

Après avoir cliqué sur Verify, si tout ce passe bien, on est invité à cliquer sur Detach :

Le warning m’indique 2 choses :

• tout d’abord un message d’avertissement indiquant que la collection était attachée à une base de données SQL 2008 Enterprise et de prendre cette information en considération lors de la restauration sur un autre serveur SQL.
• ensuite un message d’avertissement concernant les services de Builds. Ce message m’indique que si des builds sont en train de s’exécuter alors elles seront stoppées.

Cliquer ensuite sur Detach afin de détacher la collection. Voici le résultat :

Le message d’avertissement concernant les services de Build m’indique que le contrôleur et l’agent ont été désactivés.

2/ Récupérer les bases de données du serveur A

Pour restaurer le serveur TFS sur une autre machine, nous avons besoin de plusieurs bases de données. Bien évidemment cela dépend de l’installation qui a été faite. Dans mon cas j’ai installé le serveur TFS avec le portail Sharepoint et le serveur de rapports.

Depuis SQL Server Management Studio effectuer un backup des bases de données suivantes :

• TFS_DefaultCollection
• ReportServer
• ReportServerTmpDB
• WSS_Content

3/ Backup de la clé de cryptage de Reporting Services

Certaines informations de reporting services, comme les mots de passe ou les chaines de connexion, sont cryptées en base de données. Lorsque l’on veut migrer un serveur Reporting Services il faut penser à effectuer un backup de la clé de cryptage afin de restaurer cette clé sur l’autre serveur.

Ouvrir Reporting Services Configuration Manager, puis aller dans Encryptions Keys :

Cliquer ensuite sur Backup, sélectionner une destination ainsi qu’un mot de passe :

4/ Restauration de la collection de projet sur le serveur B

Je ne décrirai pas l’installation du serveur TFS sur la machine B, car il suffit de faire une installation (en mode advanced) de TFS 2010.

Une fois TFS 2010 installé sur la machine B, restaurer la base de données Tfs_DefaultCollection sur le serveur SQL sur lequel pointe le nouveau serveur TFS :

5/ Attacher la collection au serveur TFS

Ouvrir la console d’administration de TFS, aller dans Application Tier, puis dans Team Project Collection et cliquer sur Attach Collection :

Sélectionner la base de données précédemment restaurer :

Cliquer ensuite sur Next et Verify :

Cliquer ensuite sur Attach :

Comme on peut le voir sur l’image ci-dessus, la collection a bien été rattachée au nouveau serveur TFS. Il reste à migrer/configurer Reporting Services et Sharepoint.

6/ Restauration de Reporting Services

Depuis SQL Server Management Studio, restaurer les bases de données Reporting Services (ReportServer et ReportServerTempDB).

Attention : lors de restauration de la base de données ReportServerTempDB, il faut lui donner le même nom que celui qu’elle avait sur l’autre serveur SQL. En effet le nom de cette base de données est écrit en dur dans les procédures stockées de la base ReportServer.

Ouvrir ensuite Reporting Services Configuration Manager, puis aller dans Encryption Keys et cliquer sur Restore :

Dans location, rechercher le fichier .snk précédemment récupérer sur l’autre serveur de rapport, rentrer le mot de passe puis cliquer sur OK.

7/ Suppression de la base de contenu Sharepoint existante sur le serveur B

Dans les outils d’administration, lancer l’outil SharePoint 3.0 Central Administration :

Cliquer ensuite sur Application Management, puis dans le menu Sharepoint Web Application Management cliquer sur Content databases :

Cliquer sur la base WSS_Content, dans les paramétrages de la base, cocher la case Remove content database puis cliquer sur OK :

8/ Restauration de la base de contenu

Sur le serveur B ouvrir SQL Server Management Studio, puis restaurer la base de données WSS_Content précédemment “backupée” depuis le serveur A.

Une fois la base de données restaurée, ouvrir SharePoint 3.0 Central Administration. Aller dans Application Management, puis dans le menu Sharepoint Web Application Management cliquer sur Content databases.

Cliquer ensuite sur Add Content Database :

Remplir les champs de connexion à la base de données précédemment restaurée puis cliquer sur OK.

9/ Configuration des Team Projects

Il reste à reconfigurer les portails des Team Project.

Ouvrir Visual Studio, ouvrir Team Explorer et se connecter au serveur TFS. Clic droit sur le Team Project, puis dans Team Project Settings, cliquer sur Portal Settings…

Dans le wizard qui s’affiche, cocher la case Enable Team Project Portal, puis cliquer sur Configure URL…

Sélectionner l’application Sharepoint puis indiquer le chemin d’accès au portail du projet :

Cocher la case Reports and dashboards refer to data for this team project, puis cliquer sur OK :

10/ Réparation de la connexion à Sharepoint

Cliquer sur Repair Connection, puis dans le wizard cliquer sur Repair :

11/Reconstruction du cube

Dans la console d’administration de TFS, aller dans Reporting puis cliquer sur Start Rebuild :

12/ Vérification de la migration

Depuis Team Explorer, vérifier que vous pouvez vous connecter à votre nouveau serveur TFS, que vous récupérer la collection ainsi que les Team Project.

Vérifier que le portail est accessible : clic droit sur un Team Project puis cliquer sur Show Team Portal…

Si comme moi vous avez encore une erreur lors de l’exécution des rapports, aller sur le web service du datawarehouse (http://localhost:8080/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx) :

Exécuter la méthode ProcessWarehouse sans paramètre, puis ProcessAnalysisDatabase avec en paramètre Full.

Vérifier que les rapports s’exécutent correctement. Si aucun work item n’existe pour le Team Project, vous risquez d’avoir une erreur lors de l’exécution des rapports. Vous aurez une exception du style : Default value or value provided for the report parameter 'WorkItemTypeParam' is not a valid value. (rsInvalidReportParameter). Ceci est un bug connu (bug remonté sur connect : http://connect.microsoft.com/VisualStudio/feedback/details/499387/reporting-services-error-on-dashboard-of-sharepoint)

Pour ne pas avoir cette exception, il faut que le Team Project contienne au moins 1 work item. Créer un work item (de type tache par exemple) sur le Team Project puis attendez environ 10min, ou pour aller plus vite faire un iisreset.

La migration est maintenant terminée!!

13/ Conclusion

La migration d’un serveur TFS 2010 sur une autre machine n’est pas bien compliquée. De plus la nouvelle console d’administration de TFS est très pratique et permet de gagner pas mal de temps comparer à TFS 2008 et à ces outils en ligne de commande… La console d’administration de TFS 2010 permet de restaurer une collection simplement et rapidement. Après, quelques connaissances de Sharepoint et de Reporting sont nécessaires pour ne pas perdre trop de temps.

TFS Power !

Ce weekend je me suis attelé à l’un de mes projets perso que j’avais, il y a quelques temps, migré vers un TFS 2010 Beta 2. Depuis mon passage sur la RC je n’avais pas encore remis le nez dedans et ce weekend je me suis aperçu qu’une erreur survenait lors de l’exécution des builds.

Voici le détail de l’erreur : File not found: C:\Windows\Microsoft.NET\Framework\v4.0.21006\MSBuild.exe

L’erreur est assez parlante et facile à vérifier. J’ouvre un windows explorer et effectivement le répertoire v4.0.21006 n’existe plus, puisqu’il correspond au numéro de version du framework .Net 4.0 Beta 2. La version RC quant à elle a le numéro v4.0.30128.

Il suffit donc de modifier ce numéro de version quelque part dans la définition des Builds… Après quelques recherches sur le web, je tombe sur le blog de Tomas Scott qui indique qu’il suffit de recréer une nouvelle collection et un nouveau projet. Cette nouvelle collection se basera sur les templates de Build de la version RC, qui eux pointerons vers le bon chemin du framework. Vous pouvez ensuite récupérer ces templates et les remplacer par vos anciens.

C’est en effet une solution simple et pratique… Sauf que moi je suis encore plus fainéant que ça, il me fallait donc une autre solution. Si ce sont les templates qui merde, alors autant chercher dans ces templates le chemin de MSBuild.exe et le remplacer par le nouveau. Ou se trouve ce fameux template ? Dans le source control du Team Project, à la racine, il y a un répertoire BuildProcess Template dans lequel on trouve le template DefaultTemplate.xaml.

2 possibilités pour le modifier : en mode notepad ou en mode designer de workflow. Si vous le faites en mode je suis un killer je le fais avec notepad, rien de plus simple : faites une recherche de la chaine v4.0.21006 puis remplacer la par v4.0.30128. Vous devriez normalement trouver 2 occurrences.

Nous allons ici ouvrir le fichier dans le designer de workflow. Après double clic sur le fichier, un joli designer s’ouvre et vous permet d’éditer le template du workflow des builds. Si vous l’étudiez un peu, vous retrouverez les étapes que vous voyez passer lorsque vous lancer une build. Il vous faut rechercher l’activité de type MSBuild, Run MSBuild for Project, comme indiqué ci-dessous :

Une fois trouvé, il suffit de la sélectionner et d’afficher les propriétés. Dans les propriétés rechercher la propriété ToolPath :

Editer la propriété afin de pointer sur la bonne version du framework, à savoir la v4.0.30128 :

Recommencer cette opération en recherchant la 2ème activité de type MSBuild et mettre à jour la propriété ToolPath.

Et voilà le tour est joué! Un petit checkin sur le fichier DefaultTemplate.xaml et c’est fini. Pour le vérifier, il suffit de relancer la Build et de constater que l’erreur a disparu.

Si seulement tout pouvait être aussi simple dans la vie…

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!

Si vous avez suivi l’actualité de la semaine, vous savez certainement que VS 2010 et TFS 2010 sont disponibles en version Release Candidate pour les abonnés MSDN. L’information a été annoncée par plusieurs Microsoftees, dont notamment Cameron Skinner et Brian Harry.

A la suite de cette annonce, plusieurs informations importantes sont à noter. Tout d’abord concernant le support de la RC, qui comme la Beta 2, est une version “go live”.

Martin Hinshelwood fourni un témoignage intéressant sur la migration (ou plutôt sur la désinstallation) de TFS 2010 Beta 2 vers la RC.

Une autre annonce très importante de Brian Harry sur la sortie des Power Tools de TFS pour la version RC. Ces Power Tools étaient disponibles en version Beta 2 et devraient normalement être disponibles d’ici le 19 février, c’est à dire dans une semaine.

Concernant l’installation de Visual Studio 2010 RC, si vous avez installé la version Beta 2 ainsi que les Power Tools Beta 2, sachez qu’ils vous faudra les désinstaller pour installer la RC.

Petite nouveauté sur l’installation de Visual Studio 2010 : Team Explorer et VS 2010 ne font qu’un. Plus besoin d’installer VS 2010 puis Team Explorer. Team Explorer est directement inclus à VS 2010. Cependant une version standalone de Team Explorer existe toujours, pour les personnes qui n’ont pas besoin des fonctionnalités de Visual Studio.

Attention aux projets de modélisation. Si vous avez utilisé les projets de modélisations dans la Beta 2, sachez qu’ils ne sont pas supportés tel quel dans la RC. Cameron Skinner nous propose un outil en ligne de commande permettant de migrer les projets de modélisation ainsi que les diagrammes UML développé en Beta 2 vers la RC.

Le Visual Studio Visualization and Modeling SDK RC est également disponible en téléchargement et pas seulement pour les abonnés MSDN. Ce SDK, en plus du DSL SDK, permet notamment d’étendre les fonctionnalités des diagrammes UML.

Enfin quelques changements (non exhaustifs) dans le TFS SDK comme nous l’indique Buck Hodges. Dans ces changements, à noter que la classe TeamFoundationServer devient obsolète et est remplacée par la classe TfsTeamProjectCollection.

Bons téléchargements !!

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…

Dans la nouvelle version de TFS, c’est à dire 2010, plusieurs nouveautés sont apparues. Ces nouveautés ont forcément engendré quelques modifications au niveau du SDK de TFS et on peut voir notamment que certaines classes du SDK 2008 sont maintenant obsolètes.

Comme je le disais dans un précédent post, je suis en train de réécrire une nouvelle version de mon addin TFS pour Outlook, Outlook Work Items Extension, pour 2 raisons : ajouter des nouvelles fonctionnalités, mais surtout faire en sorte qu’il fonctionne pour TFS 2010 et TFS 2008. Eh oui, j’ai essayé de l’utiliser en me connectant sur un serveur 2010 et là j’ai eu quelques soucis… Je vais donc essayer de vous expliquer quels sont les points bloquants et comment je migre mon code.

1ère étape : Mise à jour des références

Dans les projets référençant le SDK, supprimer les références du TFS SDK 2008 (version 9.0) par les assembly du SDK 2010 (version 10.0). Après installation de VS 2010 vous trouverez les assemblies dans le GAC, dans \Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies et dans \Program Files\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0.

Dans mon cas, j’utilise les assemblies suivantes :

• Microsoft.TeamFoundation.dll
• Microsoft.TeamFoundation.Client.dll
• Microsoft.TeamFoundation.WorkItemTracking.Clients.dll
• Microsoft.TeamFoundation.WorkItemTracking.Controls.dll

Remarque intéressante : les applications utilisant le SDK 2010 vont pouvoir s’exécuter en 64bits puisque contrairement aux SDK 2008, les assemblies de 2010 sont disponible en 32bits mais aussi en 64bits.

2ème étape : Compiler et parcourir les warnings

Cette étape consiste à retrouver tous les warnings concernant l’utilisation de types ou de méthodes obsolètes.

3ème étape : Mettre les mains dans le camboui !

Pour ma part j’utilisais le controle DomainProjectPicker, qui permet d’afficher la boite de dialogue de sélection de Team Projects. Dans la version 2010, cette classe est obsolète. En effet, maintenant dans TFS 2010 il y a la notion de collections de projets, qui n’existait pas dans 2008. Le contrôle de sélection d’un Team Project a donc changé et il faut maintenant utiliser le TeamProjectPicker.

Avec le SDK 2008 j’avais écrit le code suivant :

List<FavoriteTeamProject> favorites = FavoritesTeamProjectManager.GetFavoritesProjects();
using (DomainProjectPicker picker = new DomainProjectPicker(DomainProjectPickerMode.AllowMultiSelect | DomainProjectPickerMode.AllowProjectSelect))
{
	picker.SelectedServer = new TeamFoundationServer("serverName");
    WorkItemStore wis = new WorkItemStore(s);
    ArrayList list = new ArrayList();
    foreach (var project in item)
    {
    	list.Add(wis.Projects["projectName"].Uri.ToString());
	}
    picker.DefaultSelectedProjects = new SortedList();
    picker.DefaultSelectedProjects.Add(s.Uri.ToString(), list);
	
	if (picker.ShowDialog() == DialogResult.OK)
    {
    	var selectedProjects = picker.SelectedProjects;
	}
}

• L’initialisation du serveur TFS sélectionné par défaut se fait via la propriété SelectedTeamProjectCollection, en lui fournissant le nom du serveur et la collection: serverName\collectionName.
• L’initialisation des projets sélectionnés via une simple liste de ProjectInfo que l’on affecte à la propriété SelectedProjects du picker

using (TeamProjectPicker picker = new TeamProjectPicker(TeamProjectPickerMode.MultiProject, false))
{
	picker.SelectedTeamProjectCollection = new TeamFoundationServer(@"serverName\collectionName");
	List<ProjectInfo> list = new List<ProjectInfo>();
    ProjectInfo pi = new ProjectInfo("projectUri", "projectName", ProjectState.WellFormed);
    list.Add(pi);
	picker.SelectedProjects = list.ToArray();
    
	if (picker.ShowDialog() == DialogResult.OK)
    {
    	var selectedProjects = picker.SelectedProjects;
	}
}

Dans le prochain post nous verrons comment migrer l’utilisation des requêtes qui se faisait avec la classe StoredQuery avec le SDK 2008 et qui se fait maintenant avec les classes QueryHierarchy, QueryFolder et QueryDefinition pour le SDK 2010.

Quoi de mieux pour démarrer mon blog que de présenter mon addin TFS pour Outlook ?

Cet outil, disponible sur Codeplex à cette adresse http://bowie.codeplex.com, permet d’intégrer TFS à Outlook.

Pour l’instant l’outil fonctionne avec Outlook 2007 et 2010 et TFS 2008. Je travaille actuellement sur une nouvelle version afin d’intégrer de nouvelles fonctionnalités et d’être compatible avec TFS 2010. Cette nouvelle version devrait être disponible fin Novembre et fonctionnera donc sur la Beta 2 de TFS 2010. N’hésitez pas à me contacter si vous avez des idées d’évolutions !

Voici la liste des fonctionnalités disponible actuellement :

Dans le Ribbon d’un email reçu :

• Créer un nouveau Work Item depuis l’email
• Attacher l’email à un Work Item existant (formats html, txt, msg…)
• Télécharger les pièces jointes de l’email vers une librairie de documents d’un Team Project
• Retrouver les Work Items attachés à ce mail

Dans le Ribbon d’un email que vous rédigez :

• Ajouter en pièces jointes des documents depuis les librairies de documents d’un Team Project
• Ajouter en pièces jointes des reports d’un Team Project (formats pdf, excel, tiff…)
• Ajouter les infos de Work Items dans le corps du mail

Dans le menu principal d’Outlook:

• Menu Team –> Gérer mes favoris : permet d’ajouter les Team Projects avec lesquels vous voulez travailler et de définir un Team Project par défaut

Depuis le menu contextuel d’un répertoire de mails:

• Définissez un lien entre un répertoire de mail et un Team Project. Ce lien permet de créer automatiquement des Work Items lorsque l’on déplace un mail dans ce répertoire. Vous pouvez définir le type de Work Item à créer, le mapping des champs, et d’autres paramètres comme par exemple attacher le mail ou ses pièces jointes au work item. L’image ci-dessous présente la fenêtre de paramétrage. L’onglet “WSS Portal” est une nouvelle fonctionnalité qui ne sera présente que pour la prochaine version.