Liste des billets de cette série :
Dans cette première partie nous allons voir ce qu’il faut faire lorsque nous voulons renommer le serveur de base de données db.demo.local en db1.demo.local pour que nos services remarche 
Liste des billets de cette série :
Lors de mon travail je suis tombé sur un problème intéressant : devoir renommer une machine sur laquelle tournait l’ensemble des composants de TFS. Il y a bien de la documentation mais un peu éparpillé partout. J’ai donc décider de faire une série de billet indiquant la marche à suivre lorsque l’on souhaite renommer chacun des composants/serveurs de TFS.
Voici un petit billet sur comment ajouter un paramètre “extensible” à un workflow de build. Ce que j’entend par paramètre extensible est un paramètre à coté duquel s’affiche un petit + permettant de l’ouvrir pour remplir des propriétés, la ligne principale affichant un résumé des valeurs :
Comme promis je vais vous décrire un exemple d’utilisation de l’activité UpdateAssemblyInfo que j’ai publié sur codeplex.
Commençons d’abord par décrire ce que l’on attend :
Avant de mettre à jour notre template de build je vais configurer la solution pour rendre la mise à jour des versions pour l’ensemble des projets plus simple. Pour cela on ajoute un fichier GlobalAssemblyInfo.cs (ou .vb si vous faite du VB.Net) à la solution en tant que solution items :
Après vous avoir montré comment personnaliser l’IntelliTrace, je vais aujourd’hui vous montrer comment créer vos propres analyseurs pour les graphes de dépendance dans les outils d’architecture de VisualStudio 2010.
Avant de commencer encore un petit avertissement (toujours en gras et rouge pour être bien visible ) :
Microsoft ne fournit pas et ne fournira ni documentation ni support sur ce que je vais expliquer car même si cela est possible, ce n’est pas une fonctionnalité supportée.
Maintenant que vous êtes prévenu nous allons voir comment créer un analyseur qui affichera l’ensemble des noeuds commençant par « Qetza. ».
On commence par créer une bibliothèque de classe et par référencer les trois assemblies suivantes :
Ces assemblies se trouve dans le sous-répertoire « Common7\IDE\PrivateAssemblies » de votre répertoire d’installation de VisualStudio 2010 (par défaut « C:\Program Files\Microsoft Visual Studio 10.0″).
Ce billet fait parti d’une série sur TeamBuild 2010 :
Il est temps de reprendre un peu ma présentation des nouveautés de TeamBuild 2010
TeamBuild étant maintenant basé sur Workflow Foundation 4.0, Microsoft propose de base un ensemble d’activités écrites spécifiquement pour TeamBuild. Ces activités correspondent grosso-modo aux tâches qui existaient pour TeamBuild 2008 :
Mon dernier billet date de 3 mois, il est temps de mit remettre
Aujourd’hui je vais vous montrer comment vous pouvez personnaliser l’IntelliTrace de VisualStudio 2010 afin qu’il trace les évènements de vos propres méthodes. Mais avant de commencer il faut que je vous préviennes (en rouge et gras pour que ce soit bien visible ) :
Microsoft ne fournit pas et ne fournira ni documentation ni support sur ce que je vais expliquer. Par ailleurs il n’est pas sur que la personnalisation de l’IntelliTrace ne soit pas modifiée dans le prochain VisualStudio (d’ou la non documentation et le non support).
Maintenant que je vous ai prévenu passons dans le vif du sujet : comment faire pour que je puisse avoir dans l’IntellTrace les appels à mes propres méthodes ! Afin de vous l’expliquer nous allons utiliser la classe suivante :
Ce billet fait parti d’une série sur TeamBuild 2010 :
Qu’est-ce que le « Gated Check-in » ? Il s’agit d’un nouveau type de build se lançant automatiquement lorsqu’un développeur fait un check-in mais à la différence d’un build en intégration continue, le « Gated Check-in » est capable de refuser le check-in si le build est en erreur.
D’un point de vu technique, le « Gated Check-in » utilise les étagères. Lorsqu’un développeur fait un check-in de fichier associé à ce type de build, Visual Studio affiche une fenêtre indiquant que le check-in va faire lancer un « Gate Check-in » et proposera au développeur de sauvegarder son code sur une étagère :
Comme je le disais dans mon précédent billet le moteur du serveur de build de TFS 2010 se base désormais sur Workflow Foundation 4.0. Je vous propose donc de faire une série de billet sur les nouveautés de TeamBuild 2010 en commençant par la création d’un build.
La définition des build a été enrichi en 2010 afin de proposer de nouvelles options et de s’intégrer avec le nouveau moteur. La définition d’un build se fait en 6 étapes :
La partie sur les informations ne change pas et propose toujours de nommer la définition et de fournir une description :
Dans la version 2010 de TFS, TeamBuild a été entièrement revu. Le moteur est passé sous Workflow Foundation 4.0 et l’architecture des services est maintenant distribuée. Dans ce billet je vais vous présenter cette nouvelle architecture qui apporte beaucoup plus de souplesse.
TeamBuild 2010 est composé de deux composants liés aux Team Project Collections :
Le BuildController est lié à une collection (mais une collection peut avoir plusieurs BuildController) et s’occupe de toutes les tâches ne sollicitant pas de manière intensive le processeur ou le disque :