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!

Je viens de publier un nouvel article sur le développement 32bits et 64bits.

“Avec l’arrivée du Framework 4.0 et de Visual Studio 2010, Microsoft a fait de gros effort sur le développement d’applications 64bits avec Visual Studio 2010. Patrice Lamarche nous livre dans ce billet l’un des changements majeur concernant la politique de compilation de vos projets UI avec Visual Studio 2010.

Au-delà de l’IDE, le Framework 4.0, et plus précisément la classe System.Environment, nous fournit des propriétés permettant de savoir si l’OS est en 32 ou 64bits, ou de récupérer le répertoire Program File (x86) ou encore le répertoire Windows\SYSWOW64…

Quelles sont les différences entre ces OS ? Comment des applications 32 bits et 64 bits cohabitent ? Comment les prendre en compte dans nos développements ?”

Je ne suis pas trop pour ce genre de post, mais mon ami et collègue Sebastien Pertus m’a passé la patate chaude, et je me dois donc de la renvoyer…

1. Mon nom, Laut s'écrit avec un T et se prononce lo, pas Lote! Je suis du nord et dans le nord on ne dit pas moinsse...
2. 95% des gens l'oublis, mais mon prénom, Benoît, s'écrit avec un accent circonflexe sur le i.
3. Ben, BenBen, CorBen (Dallas), PtiBen, $uddenBen, Biniouze, Strogoff, Eole, Tic (de Tic et Tac) et dernièrement Dr House, sont quelques uns des surnoms que l’on pu me donner ces 15 dernières années.
4. Je suis né à Monaco. Entendez par là la clinique Monaco à Valenciennes. Ville célèbre notamment pour son (ancien) maire, JL Borloo qui a fait venir Toyota pour fabriquer la Yaris (seul endroit dans le monde où elle est fabriquée) et qui est notamment à l'origine de la remontée du VAFC en ligue 1 (ancien club USVA).
5. A 1 an je tombe 2 fois de suite de ma chaise haute (je voulais me balancer comme sur une balançoire), à 5ans ma sœur me casse le pouce en me lançant une boule de pétanque sur la main, à 11 ans je me fais renverser sur un passage piéton par une auto école. A 30 ans, à Bewise, accident de travail, je me fais une entorse en descendant les escaliers…
6. Mon premier vrai concert en tant que spectateur : 1996, j'avais 16ans, ACDC pour la tournée Ballbreaker. Mon groupe mythique depuis l'age de 12 ans. Je peux dire que j'ai connu Bon Scott, chanteur mythique d'ACDC, mort le 19 février 1980, puisque je suis né 26 jours avant ce drame. J'aime beaucoup de style de musique : Hard Rock, Blues Rock, Heavy Metal, Death Metal, Power Metal, Trash Metal, Dark Metal Melodyc, Black Metal Symphonic Alcolic... Mais ça ne m'a pas empêché d'aller à des concerts de JJ Goldman, Mano Solo, les ogres de Barback ou encore Marcel et son orchestre.
7. Guitariste aux cheveux longs, j'ai joué 8 ans dans un groupe de Metal. Une dizaine de concerts dans des bars et discothèques, une quinzaine de compos et une corde cassée à chaque début de concert. Je joue sur une guitare Ibanez et un gros Marshal 100W 2 corps!!
8. Un jour, un grand sportif j'ai été. Gymnastique : je faisais tous les grand écarts possible (costal, facial, nasal...). Handball : j'ai participé aux sélections du nord. Cyclisme : à 17ans je faisais ma première traversée de la France, 1100km en 8jours de Valenciennes (Nord) à Pamiers (Ariège). A la même période je gravissais pour la première fois le Mont Ventoux et le Tourmalet. 
9. Si je devais me comparer à une boisson, ça serait la bière : frais, pétillant, du caractère, doux et amer à la fois... Mes préférées : Triple de Bruges et Triple Karmeliet.
10. J’habite Toulouse depuis 5 ans bientôt, mais je reste bien sur très attaché au Nord. Je suis notamment un grand supporter du VAFC que j’ai du voir pour la première fois au stade Nungesser à 10 ans. 8ème de ligue 1 en 2009-2010, pour les personnes qui ne le savent pas, Valenciennes est de retour en ligue 1 depuis 2005.

Je passe maintenant la main à JP.

Avec un collègue nous nous sommes posés quelques questions sur le développement autour d’Office et surtout sur le déploiement des PIA (Primary Interop Assembly).

La problématique est la suivante : sur nos postes nous avons Office 2010 d’installé. Nous avons donc référencé, dans notre projet de manipulation de documents Office, les PIA d’Office 2010. Ces assemblies permettent aux applications .Net d’utiliser les fonctionnalités Office. Ceci signifie que lors du déploiement de l’application, il faut qu’Office et les PIA soient installés sur le poste client (ou sur le serveur si c’est une application web par exemple). Pour information, avec Office 2010, les PIA sont forcément installées, ce qui n’était pas le cas avec les anciennes versions. Elles ne sont d’ailleurs pas encore “redistribuable” en version 2010.

Nous venons de découvrir que sur le serveur c’est Office 2007 qui est installé, or le projet doit à terme fonctionner avec Office 2010…

Doit-on changer nos références? [Edit] Non. Lorsque l’on instancie une classe Application (pour Word par exemple), celle-ci est instanciée (en interne) en utilisant le ProgID “Word.Application” et non “Word.Application.14”. Ce ProgID est indépendant de la version d’Office installée et donc si les PIA 2007 sont installées, notre application fonctionnera.

La version installée sur le serveur est Office 2007 (version 12.0). Si nous avions référencé les PIA 12.0, après installation d’Office 2010 la redirection se ferait automatiquement. Office installe des assemblies de redirection de version dans le GAC (Policy.12.0.Microsoft.Office.Interop.XXX). Chaque assembly est accompagnée d’un fichier de configuration qui indique à la CLR que lorsque notre application lui demandera de charger une PIA 12.0, elle devra lui fournir la version 14.0.

Pour s’en assurer, il suffit d’ouvrir un Command Prompt et de se rendre dans le répertoire du GAC de l’assembly Policy comme indiqué ci-dessous :

Dans le répertoire Policy.12.0.Microsoft.Office.Interop.Word se trouvent une assembly et un fichier de config. Pour éditer le fichier de configuration il suffit depuis le command prompt de taper le nom de fichier. Ceci aura pour effet de l’ouvrir dans Visual Studio. Nous pouvons ainsi visualiser le fameux BindingRedirect de la version 12.0 vers la version 14.0 :

Les redirections d’Office 2003 vers 2010 sont également présentes dans le GAC.

Parmi les nombreuses nouveautés du développement d’addin VSTO, nous retrouvons bien évidemment le Ribbon, qui est maintenant disponible depuis l’Explorer d’Outlook 2010. A l’ombre de cette grande nouveauté, d’autres font leur apparition mais passent un peu inaperçu.  

Dans le développement d’addin VSTO pour Outlook 2010, il est aujourd’hui possible de définir des icones personnalisées pour certains répertoires.  Comme vous pouvez le voir sur l’image ci-contre, j’ai défini une icône custom pour 2 de mes répertoires. La classe MAPIFolder possède maintenant une méthode SetCustomIcon qui prend en paramètre une instance de la classe StdPicture :

Afin d’obtenir une instance de type StdPicture à partir d’un objet de type Bitmap (ou Image), il faut créer une classe qui hérite de AxHost. Cette classe est un wrapper de contrôle ActiveX et possède une méthode statique (et protected) qui se nomme GetIPictureDispFromPicture :

Le tour est joué, il n’y a plus qu’à faire appel à la méthode SetCustomIcon :

Comme je vous le disais dans mon dernier post, CodePlex propose d’utiliser les nouveaux outils de DotFuscator 4.0 pour analyser son application. Qui utilise l’application, quelles sont les fonctionnalités utilisées… DotFuscator nous propose d’injecter du code dans nos assemblies afin d’obtenir ses éléments de mesure.

Ce weekend j’ai donc creusé l’utilisation de ces outils et je vous propose de les découvrir à travers cet article.

Bonne lecture !

Jusqu’ici pour un projet Codeplex nous avions du reporting sur le nombre de téléchargements ou encore le nombre de visites par période. Cependant ces indicateurs ne permettent pas de savoir l’utilisation que font les utilisateurs de l’application ou des différentes fonctionnalités.

Depuis aujourd’hui Codeplex offre la possibilité de suivre l’utilisation de son application.

En instrumentant son application avec les nouveaux outils de DotFuscator fournis avec Visual Studio 2010, il est possible de connaitre combien de fois l’application a été démarrée ou encore de connaitre la fréquence d’utilisation d’une fonctionnalité, en décorant simplement les méthodes par des attributs.

Nous connaissons déjà DotFuscator pour les outils d’obfuscation de code qui sont inclus dans les versions précédentes de Visual Studio. Dans Visual Studio 2010, PreEmptive nous propose avec la version Community Edition 4.0 de DotFuscator d’autres fonctionnalités intéressantes, simples à mettre en place et gratuites pour certaines ;)

Pour plus d’information sur DotFuscator voici la liste détaillées des fonctionnalités de DotFuscator 4.0 par édition.

La société PreEmptive é écrit un tutoriel expliquant comment instrumenter son application et la brancher sur son projet codeplex.

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…