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.

Suite à la sortie du Kinect Windows SDK, Microsoft France organise demain, mardi 28 juin, un après midi du développement pour vous faire découvrir ce SDK. Alors si vous n’êtes pas encore inscrits, dépêchez-vous, ça se passe par ici.

Je présenterai pour ma part le pilotage d’une scène 3D temps réel avec Kinect.

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 :

Le millésime 2011 de la Bewise Day Conference est annoncé pour le 7 avril et se déroulera au casino Barrière à Toulouse.

Vous pouvez d’ores et déjà vous y inscrire depuis le site BDC2011 et suivre l’évènement depuis sa page facebook.

Cette année j’animerai une session sur Windows Azure et vous me retrouverez également sur l’ATE Windows Azure.

Une petite vidéo de teasing où comme souvent dans les vidéos de Bewise nous apercevons notre ami Guillaume L. :

Avec l’un de mes collègues, nous avons récemment eu un débat autour de cette question, que nous avons fini par élucider. Voici le contexte : nous avons une classe A et une classe B, aucun héritage n’existe entre ces 2 classes, par contre nous redéfinissons l’opérateur de cast explicite de cette manière :

             1: 
            public
            class B

             2: {

             3: }

             4:  

             5: 
            public
            class A

             6: {

             7: 
            public
            static
            explicit
            operator B(A
a)

             8:  {

             9: 
            return
            new B();

             10:  }

             11: }

Une fois que nous avons défini ces 2 classes, il est tout à fait possible d’effectuer un cast entre un objet A et un objet B :

             1: A a = new A();

             2:  

             3: B
b = (B)a;

Maintenant que ce passe-t-il si on instancie une liste d’objets A et que l’on appelle la méthode d’extension Cast<T> comme ceci :

             1: var list = new List<A>()
{ new A(), new A() };

             2: list.Cast<B>().ToList();

Et bien à l’exécution, notre opérateur de cast explicite n’est pas appelé. Par contre une exception InvalidCastException est levée. La première réponse que l’on m’a donné était de dire que la méthode d’extension Cast<T> ne fait pas un cast…

Utilisons notre outil préféré (ou presque puisqu’il va bientôt devenir payant… ;)) Reflector. En reflectant la méthode Cast<T>, on peut voir qu’elle fait appel à la classe CastIterator. Celle-ci est tout simplement un itérateur sur notre collection qui dans la méthode MoveNext affecte à l’objet courant l’objet casté :

Donc oui la méthode Cast<T> fait un cast… d’après le code C#.  Car en fait, plus précisément, elle fait une opération de type unbox.any, comme le montre le code IL suivant :

C’est justement là qu’est notre problème. La classe CastIterator ne connait pas notre type A et elle itère sur une liste de type IEnumerable. Donc pour la classe CastIterator, nos objets sont de type System.Object. A cet endroit, un cast est effectué entre un objet de type System.Object et un type TResult. Du coup il fait un unbox (équivalent à l’opérateur castclass).

Décompilons maintenant le code écrit au tout début de ce post, qui caste notre variable de type A en type B :

Nous voyons bien que le compilateur a trouvé notre opérateur explicite et donc l’appelle pour effectuer la conversion.

Pour reproduire ce qu’il se passe au niveau du CastIterator, il suffit d’écrire ceci :

             1: A a = new A();

             2:  

             3: 
            object o
= a;

             4:  

             5: B
b = (B)o;

Et ici, le compilateur fait appel à l’opérateur castclass et non à notre opérateur de cast explicite :

Pour palier ce problème nous avons 2 solutions. La 1ère consiste à effectuer le cast soit même dans un Select :

             1: var list = new List<A>()
{ new A(), new A() };

             2: var
result = list.Select(a => (B) a);

La seconde solution consiste a utiliser le mécanisme de Reflection pour retrouver l’existence de l’opérateur. On peut ainsi définir la méthode d’extension suivante :

             1: 
            public
            static
            class EnumarableExtensions

             2: {

             3: 
            public
            static MethodInfo
GetMethod(Type toSearch, string methodName, Type returnType,
BindingFlags bindingFlags)

             4:  {

             5: 
            return Array.Find(toSearch.GetMethods(bindingFlags), delegate(MethodInfo
inf) { return ((inf.Name == methodName) && (inf.ReturnType
== returnType)); });

             6:  }

             7:  

             8: 
            public
            static IEnumerable<T>
DynamicCast<T>(this IEnumerable list)

             9:  {

             10: 
            foreach (var
obj in list)

             11:  {

             12:  Type
ot = obj.GetType();

             13:  MethodInfo
meth = GetMethod(ot, "op_Implicit", typeof(T),
BindingFlags.Static | BindingFlags.Public);

             14:  

             15: 
            if (meth
== null)

             16:  {

             17:  meth
= GetMethod(ot, "op_Explicit", typeof(T),
BindingFlags.Static | BindingFlags.Public);

             18:  }

             19:  

             20: 
            if (meth
== null)

             21: 
            yield
            return (T)obj;

             22: 
            else
          

             23: 
            yield
            return (T)meth.Invoke(null, new[]
{ obj });

             24:  }

             25:  

             26:  }

             27: }

Et notre appel se fait ainsi :

             1: var list = new List<A>()
{ new A(), new A() };

             2: var
result = list.DynamicCast<B>();

Et voilà un mystère d’élucidé! :)

Avec Entity Framework, et les outils de mapping objets relationnels de manière générale, les développeurs écrivent facilement des requêtes Linq To Entities sans savoir le SQL qui est réellement exécuté côté serveur.

On perd la maitrise du SQL exécuté, et ceci peut faire peur à nos chers administrateurs SQL. Dans cette article je vous propose de comparer les plans d’exécution des requêtes générées par Entity Framework et des requêtes que nous aurions écrit à la main.

Labs est un site dédié aux technologies Microsoft dont le but est de partager nos connaissances et notre passion.

Vous y retrouverez tous les articles, projets, KB, études de cas ainsi que les blogs des consultants de Bewise.

N’hésitez pas à nous envoyer vos retours.

J-7 avant l’édition 2011 des Techdays. Je serai au rendez-vous et j’animerai avec Alain Marty la session TFS Basic sur le parcours ALM.

Vous pourrez également me croiser du côté des exposants et des partenaires Inner Circle et Azure Circle toute la journée du 8 février.

Pour retrouver tous les speakers Bewise c’est pas là.

Depuis bientôt 3 mois que Kinect est sorti, on peut voir sur le web beaucoup d’initiatives de R&D utilisant ce périphérique. Vertice, la petite soeur de Bewise a elle aussi investit un peu de son temps sur Kinect. Il est maintenant possible de se déplacer dans une scène 3D temps réel Nova grâce à Kinect. Ajoutez à ça l’écran et les lunettes 3D... :)

Un petit aperçu ci-dessous :

Vertice présentera cette nouveauté au salon Imagina 2011 qui se déroulera du 1er au 3 février prochain. Retrouvez également toute l’actualité Vertice sur son blog.

L’accès au bureau distant d’une instance Azure est une autre nouveauté de la plateforme. L’activation peut se configurer depuis Visual Studio au moment du déploiement ou depuis le portail Azure.

Depuis Visual Studio, lorsque l’on déploie nos services Azure la fenêtre suivante s’ouvre :

Depuis ce wizard, il suffit de cliquer sur le lien “Configure Remote Desktop connections…”, puis de renseigner le formulaire :

Le premier champ correspond au certificat qui va permettre de crypter le mot de passe. On peut soit en choisir un dans la liste, soit en créer un. Il suffit ensuite de remplir les informations de connexion. Une fois ce formulaire rempli, Visual Studio stocke ces informations dans le fichier ServiceConfiguration.cscg de notre projet Azure :

Pour qu’Azure puisse de son côté décrypter le mot de passe, il faut déployer le certificat sur notre “Hosted Service”.

Dans un premier temps, nous allons exporter le certificat. Depuis le wizard de configuration de l’accès distant, il suffit de cliquer sur le bouton View afin d’afficher le certificat :

Dans l’onglet Details, cliquer sur “Copy to File…” pour l’exporter.

Au moment de l’export du certificat ne pas oublier de sélectionner l’option d’export de la clé privé :

Une fois le certificat exporté, il ne reste plus qu’à se connecter au portail Azure, accéder à notre Hosted Service, puis d’y télécharger le certificat :

Après avoir déployé nos rôles sur Azure, il est également possible d’activer/désactiver et configurer le bureau distant depuis le portail pour chacun des rôles :

Lorsque nos instances sont démarrées, nous pouvons nous connecter en remote :

Si vous avez suivi l’actualité d’Azure, vous avez pu voir que Microsoft avait annoncé que les fonctionnalités d’IIS seraient disponible au niveau des Web Role. Nous pouvons donc configurer notre Web Role afin d’y définir les sites, répertoires virtuels ou encore les applications comme nous le souhaitons.

A l’ajout d’un projet Azure à notre solution Visual Studio, nous allons choisir de déployer un Web Role.

Nous allons ajouter 2 sites web supplémentaires à notre solution.

Examinons maintenant le fichier ServiceDefinition.csdef de notre projet Azure :

            <
            ServiceDefinition 
            name
            ="AzureProject" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="WebRoleSample">
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
</Endpoints>
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
</WebRole>
</ServiceDefinition> 

Dans ce fichier, on peut voir la définition de notre Web Role.

Il contient un site nommé “Web” disponible en http sur le port 80. Nous pouvons observer que l’élément xml Site possède comme élément parent “Sites”. Nous allons définir nos autres sites de cette manière :

          <
          ServiceDefinition 
          name
          ="AzureProject" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="WebRoleSample">
<Sites>
<Site name="Web">
<VirtualDirectory name="Images" physicalDirectory="../PremierSiteWeb/Img">
</VirtualDirectory>
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
</Bindings>
</Site>
<Site name="PremierSite" physicalDirectory="../PremierSiteWeb">
<VirtualApplication name="SecondSite" physicalDirectory="../SecondSiteWeb">
</VirtualApplication>
<Bindings>
<Binding name="Endpoint2" endpointName="Endpoint2"/>
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
<InputEndpoint name="Endpoint2" protocol="http" port="81" />
</Endpoints>
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
</WebRole>
</ServiceDefinition> 

Dans le premier, nous avons ajouté un répertoire virtuel “Images” qui pointe sur le répertoire “../PremierSiteWeb/Img”. Nous avons ensuite déployé le site PremierSiteWeb en http sur le port 81. Puis dans ce site, nous avons défini une application virtuelle qui pointe sur le projet SecondSiteWeb. Lorsque nous déployons localement notre web role (F5), 2 navigateurs s’ouvrent sur les 2 sites. Si nous ouvrons la console d’administration d’IIS, nous retrouvons les 2 sites, le répertoire virtuel, ainsi que l’application :

Ici mon IIS local possède déjà un site sur le port 80. Pour le déploiement local, Visual Studio a publié mes sites sur les ports 81 et 82.

Après avoir déployé notre Web Role sur Azure, nous pouvons nous connecter en remote desktop à notre VM Azure, accéder au serveur IIS et vérifier que nos 2 sites ont bien été déployés :