Michel Perfetti [Miiitch]

J’ai publié une version silverlight du contrôle WPF. Il fonctionne exactement de la même façon, mais cette fois ci il cible l’interface web de TFS:

Dans le même template de work items il est maintenant possible d’afficher le workflow à la fois dans Team Explorer et dans les clients web.

Le contrôle pour le Team Explorer est ici, et le nouveau contrôle web est là.

Bon téléchargement.

@+

Daniel Wertheim viens de publier un condensé sous forme de PDF de tout son travail sur EF 4, que  ce soit au niveau des entités elle-même comme la publication en service. Le billet est ici: http://daniel.wertheim.se/2009/12/14/putting-entity-framework-4-to-use-in-a-business-architechture/ Ici un lien vers le PDF ainsi que l’archive contenant le code. On peut considérer son travail comme un workshop bien pratique pour s’initier à EF 4.

@+

Ce billet est un peu la suite de celui sur la sauvegarde, car la procédure est presque la même. L’idée est la suivante: à partir d’une collection, je veux créer une copie de celle-ci sur le même serveur ou un autre serveur mais dans dans tous les cas avec un nom différent. Il y a plusieurs raisons pour cela, par exemple:

• créer une copie pour un serveur pour tester une nouvelle configuration matérielle par exemple
• pour fusionner plusieurs serveurs en 1: le renommage permet de palier l’utilisation du nom par défaut qui a du être utilisé sur tous les serveurs.

Une fois la collection détachée de TFS, il faut en faire une copie dans Sql Server sur le même serveur SQL Server ou un autre. Une fois la copie effectuée on effectue l’attachement avec la ligne de commande suivante:

TfsConfig collection /attach /collectionDb:.\sqlexpress;Tfs_MaCollectionBis /collectionName:MaCollectionBis /clone

Et si j’avais voulu le faire à partir de l’interface de TFS, cela se passe comme n’importe quelle attachement:

A l’étape suivante, on nous informe qu’il s’agit d’un clonage de collection (car j’essaye l’attachement sur le même serveur) et qu’il faut donc en donner un nouveau:

Et il suffit ensuite d’effectuer l’attachement tout simplement!

@+

Brian Harry vient de l'annoncer sur son blog: http://blogs.msdn.com/bharry/archive/2009/12/01/tfs-2010-power-tools-are-available.aspx.

Pas mal de choses ont changé car certaines fonctionnalités ont été intégrées dans le produit lui-même. Tous les détails sont ici: http://blogs.msdn.com/bharry/archive/2009/11/18/tfs-2010-power-tools-coming-soon.aspx.

On se retrouve à présent avec les mêmes outils sur la beta 2 de TFS 2010, qu'avec TFS 2008.

Bon téléchargement!

@+

Si vous voulez backuper toutes vos bases de TFS y compris celles des collections de projets, il y a une application procédure pour ça :) Mais si vous voulez seulement demander à vos DBAs de sauvegarder que vos collections vous allez avoir un problème: on peut peux pas sauvegarder une collection sans la détacher au préalable via la console TFS car la collection sera alors  inutilisable. Il faut donc passer par la procédure suivante:

1. Détacher dans TFS
2. Backup
3. Re-attacher dans TFS.

Il ne faut pas confondre cette procédure d’attachement/détachement à celle de SQL Server concernant la base de données de la collection de projet. Dans notre cas la collection reste toujours connectée au serveur SQL. Cette procédure est obligatoire car la procédure de détachement copie des données dans la base de la collection pour la rendre transportable.

Alors comment faire pour automatiser tout ça? La réponse en 4 lettres: SSIS ou Sql Server Integration Services. On va donc créer un package pour réaliser ces 3 opérations.

On commence déjà par créer le package. L’ensemble de ces opérations ont été effectuées sur un TFS Basic. Ensuite on crée la tâche pour détachement de la collection: on va utiliser la ligne de commande via TfsConfig dans une tâche “Execute Process”:

Ensuite on sauvegarde la base via la simple tâche de backup:

Et pour finir on copie notre tâche de détachement et on la modifie pour en faire une tâche d’attachement:

Voici l’enchainement dans SSIS:

On peut aussi ajouter la tâche d’attachement dans le handler d’erreur pour être sur qu’en cas d’erreur dans le script:  la collection est toujours attachée au final.

@+

Lorsqu’un projet WPF devient complexe, on commence à surcharger les espaces de noms pour pouvoir utiliser nos contrôles. Voici un simple projet de contrôles:

Rien que pour ces 2 contrôles qui sont dans des espaces de noms différents je suis obligé de déclarer ceux-ci dans toute fenêtre ou contrôle qui en ont besoin:

C’est franchement pas pratique: avec cette méthode, si je veux avoir une bibliothèque organisé par espace de nom et facilement utilisable, je suis obligé d’avoir un espace de nom xaml pour chaque espace de nom .Net.

La solution à ce problème est l’utilisation de l’attribut XmlnsDefinitionAttribute: on va pouvoir définir une url comme espace de nom, exactement comme les contrôles natifs de Microsoft:

[assembly: XmlnsDefinition("http://blogs.developpeur.org/miiitch/wpf","MyControlLibrary")]
[assembly: XmlnsDefinition("http://blogs.developpeur.org/miiitch/wpf", "MyControlLibrary.Admin")]

Comme on peut le voir, je peux définir la même url pour plusieurs espaces de nom .Net. Ainsi le xaml est simplifié, et il n’y a plus de référence à l’espace de nom de l’assembly d’origine:

Comme l’espace de nom de la bibliothèque d’origine a disparu, cela signifie aussi que le refactoring sur les contrôles est possible sans avoir à modifier le xaml.

@+

J.D. Meier vient de l’annoncer sur son blog: http://blogs.msdn.com/jmeier/archive/2009/11/24/now-available-final-pdf-of-the-microsoft-application-architecture-guide-second-edition.aspx

On peut soit télécharger soit la version PDF, consulter l’ouvrage en ligne, ou même l’acheter.

@+

Dans VS 2005 et VS 2008 l’affichage de l’historique d’un fichier n’est pas “la plus puissante” fonctionnalité du Team Explorer:

L’historique est présent en barre d’outil par défaut et il ne peut y avoir qu’un historique à la fois. C’est bien… mais pas suffisant :)

En 2010 c’est tout autre chose:

• On peut avoir plusieurs historiques simultanément : un onglet par historique
• Les données sont beaucoup plus complètes. C’est ce que l’on va voir.

Voici le nouvel écran d’historique:

Jusque là, rien de spécia coté donnéesl. On a par contre une barre d’outil qui nous proposent plusieurs options. On peut aussi voir les historiques en fonction des labels posés:

Prenons un autre fichier, dans une branche par exemple. Avec TFS 2008, l’historique commençait au moment de la création de la branche. Maintenant on a beaucoup plus d’informations:

On a non seulement l’historique habituel, mais aussi l’historique des versions des branches annexes. Par exemple tout en bas, sélectionné, on peut voir l’historique du fichier sur la branche principale.

A ce niveau nous travaillons sur les fichiers, mais il est aussi possible d’analyser les opérations réalisées sur un changeset pour identifier les sources des modifications lors des merges:

Ceci est l’affichage en mode historique du changeset 24. On identifie clairement que les données viennent des changeset 22 et 23 de la “Main”.

Pourquoi tout ceci en 2010 et pas en 2008 ? Parce que le controleur de source a été radicalement modifié au niveau du référencement des éléments. Ce billet donne un aperçu de ces changements et de la nouvelle philosophie qui se cache derière le terme de “slot mode”: http://blogs.msdn.com/mitrik/archive/2009/05/28/changing-to-slot-mode-in-tfs-2010-version-control.aspx.

@+

C’est sorti en 1.0 il y a 2 jours. Pour le téléchargement c’est ici: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=beb29d27-6f0c-494f-b028-1e0e3187e830

Il y a aussi un SDK interactif: http://www.microsoft.com/maps/isdk/silverlight/

@+

Ce qui me gênait avec VS 2008 ou 2005 est la visualisation des conflits dans le Source Control Explorer. TFS nous a toujours laissé la possibilité de fusionner les conflits comme on le souhaite (en gardant la version locale, la version serveur, ou une fusion manuelle des deux). Mais si l’on ne réalisait pas l’opération au moment du “get latest”, les conflits étaient difficiles à retrouver, et souvent, on devait les résoudre en simulant un check-in. Dans la prochaine version du Source Control Explorer, un nouvel onglet apparaît: les conflits. Il suffit maintenant de résoudre directement les conflits par ce panneau pour finaliser le check-in.

J’ai juste un petit regret: il n’est pas possible de voir qu’un fichier est en conflit directement dans l’arbre de source et la liste des fichiers, à la TortoiseSVN.

2 nouveautés bien pratiques de TFS 2010 autour de la gestion des workspaces. Tout d’abord dans la fenêtre de gestion des workspaces:

Cette case permet d’afficher les workspaces placés sur d’autres ordinateurs.

Autre nouveauté, la possibilité de partager les workspaces:

Il y a maintenant 3 possibilités lors de la création d’un workspace:

• private: comme on a l’habitude avec VS2005/2008: le workspace est uniquement utilisable par le propriétaire
• public: le workspace est à tout le monde
• public (limited): le workspace est à tout le monde mais que le propriétaire a le droit d’archiver à partir de ce workspace.

Voyons ce qu’il se passe avec un workspace public mais “limited” vu d’un autre utilisateur. Le workspace apparaît dans la liste, avec le nom du propriétaire:

Si j’essaye d’éditer le workspace, tout est en lecture seule:

J’aurais pu éditer le workspace si l’utilisateur courant avait la permission “Administer workspaces”.

Si j’essaie d’archiver j’obtiens le message suivant:

Il y a beaucoup de possibilités avec ces workspaces comme la possibilité d’avoir un workspace que l’on partage avec un collègue pour travailler en alternance  sur un projet avant d’archiver sans avoir besoin de shelve. C’est, en tout cas une meilleure option que l’archivage comme option de partage de code!!

@+

L’une des fonctionnalités les plus attendues de TFS 2010 est la possibilité de gérer des collections de projets. Voici comment cela se présente dans la console de TFS 2010 beta 2:

Ceci est la console de TFS 2010 Basic beta 2 que j’ai installé dans une VPC. Chaque collection de projets regroupe l’ensemble des éléments que l’on avait dans un seul serveur en 2008 et 2005. L’intérêt est que l’on peut maintenant sur un seul serveur isoler des collections de projets entre elles et surtout on va pouvoir les migrer sur un autre serveur!

Voici à quoi ressemble une collection dans le serveur de base de donnée. Ici comme c’est une version “Basic”, j’ai pu installer TFS 2010 sur SQL Express:

Il y a donc une base de donnée par collection. Contrairement aux version antérieures de TFS où le contrôleur de source, la gestion des work items et des builds par exemples étaient séparées.

Ajoutons une nouvelle collection:

Et à la fin:

Coté Visual Studio on retrouve nos 2 collections ainsi:

On ne travaille que sur une collection à la fois. C’est donc notre nouvelle granularité entre le serveur et les projets:

On remarque bien la séparation entre les 2 collections. Voici la vue coté base:

Chaque collection est bien une base de donnée.

Puisque ce tout est embarqué dans une base de donnée, on peut imaginé beaucoup de scénarii basés sur ce mécanisme. Entre autre:

• Archivage simplifié
• Reprise panne du serveur simplifiée aussi: il suffit de reattacher la collection sur un nouveau serveur
• En tant que consultant en SSII, cela nous arrive de travailler sur un projet pour un client et devoir ensuite livrer les sources. Avec ce mécanisme, on peut livrer l’historique complèt du projet.
• Isolation: un seul serveur, plusieurs équipes avec chacune sa collection. Tout ce petit monde est isolé des uns des autres.

@+

Je ne l’avais pas vu passé avant aujourd’hui, mais je viens de voir que la RTM de Windows Virtual PC et Windows XP Mode sont disponibles sur MSDN depuis le 7 octobre. Cela tombe bien il y a plein de bonne chose à installer en VPC!

Faîtes chauffer vos modem :)

@+

Michel

Cela ne vous ait jamais arrivé d’être sur un projet qui n’avance pas en vous demandant qu’est ce qu’il fait que rien ne bouge ? En bien, ne cherchez plus, ce qui bloque tout cela, c’est le « Plouf ». Guillaume Duquesnay d’Octo nous présente cet adversaire avec beaucoup d’humour et de justesse et surtout nous donne des armes pour le battre.

La video est ici. Bon visionnage!

@+

Depuis les premières version de TFS, lorsqu’on supprime une build, on supprime également le label associé. Cela peut être génant lorsque l’on veut garder une revenir sur le code d’une build bien après qu’elle ait été supprimée (soit à la main soit parce que les “retention policies” ont fait le nettoyage).

Avec le SP1 de VS 2008 on peut modifier cela de façon globale en ajouter un élément de paramétrage dans le fichier de configuration du tiers applicatif:

<appSettings>

  <add key="PreserveLabelsOnBuildDeletion" value="true" />

</appSettings>

Merci au post de Buck qui m’a fait découvrir cela:

http://blogs.msdn.com/buckh/archive/2008/10/20/tfs-2008-sp1-new-setting-to-delete-a-build-without-deleting-the-build-label.aspx

On y apprend aussi que ce comportement sera configurable dans TFS 2010

@+

Par défaut, la portée d’une fenêtre (ou d’un contrôle utilisateur)  est publique. Cela n’est pas trop pratique lorsque l’on veut limiter l’accès à ces composants:

Le première réflèxe pour changer cela est de passer le mot clé “public” du code behind de la fenêtre en “internal”, mais on tombe sur l’erreur suivante:

error CS0262: Partial declarations of 'WpfApplication5.Window1' have conflicting accessibility modifiers

En fait la portée est aussi précisée dans le code généré par Visual Studio. Il y a donc conflit:

Pour changer cela, il y a 2 étapes très simples: il suffit d’enlever l’élément de portée redondant dans notre code behind, et d’ajouter l’attribut suivant x:ClassModifier="internal" dans le xaml de la fenêtre:

On recompile et c’est terminé!

@+

je reviens sur mon billet précédent en modifiant légèrement mon API:

using System;

namespace System.Data
{
    private static class Extentions
    {
        public static void DoSomething(this IDbConnection cnx)
        {
            //plein de truc à faire
        }
    }
}

J’ai modifié mon programme pour tenir compte du type renvoyé et voici ce qu’Intellisense me propose:

Mon extension n’est toujours pas là! C’est encore la même raison: l’espace de nom de l’extension n’est pas utilisé dans mon programme même si l’espace de nom de la classe SqlCommand est bien présent. Il faut donc modifier le code en ajoutant “using System.Data”:

Un conseil donc: lorsque vous déclarez des méthodes d’extensions sur des interfaces ou non, bien préciser dans la documentation qu’il faut ajouter l''espace de nom correspondant!

J’ai eu une drôle de surprise l’autre jour. Pour simplifier voici le code suivant:

Une petite API:

using System;
using System.Data.SqlClient;

namespace ConsoleApplication32
{
    static class DBUtil
    {
        public static SqlConnection OpenConnection()
        {
            var ret = new SqlConnection("Mon serveur DB");
            ret.Open();
            return ret;
        }
    }
}

Une extension:

  
using System;

namespace System.Data.SqlClient
{
    private static class Extentions
    {
        public static void DoSomething(this SqlConnection cnx)
        {
           // mon super code

        }
    }
}

Et le code:

  
using System;

namespace ConsoleApplication32
{
    class Program
    {
        static void Main(string[] args)
        {
            var cnx = DBUtil.OpenConnection();
        }
    }
}

Avec cela théoriquement, je m’attendais à voir apparaître ma méthode d’extension dans la liste fournie par Intellisense. En fait non!

En regardant de plus près la réponse est simple: la méthode d’extension est déclarée dans un certain espace de nom: “System.Data.SqlClient” mais qui n’est pas utilisée dans mon code. En effet, je n’ai pas eu besoin de l’utiliser car je n’ai pas eu à déclarer le type grâce au mot clé var: je laisse le compilateur le soin de compléter. Comme l’espace de nom n’est pas renseigné, Intellisense ne vas pas chercher les extensions donc ma méthode n’apparaît pas. Une fois l’espace de nom renseigné, tout revient “à la normale”:

Dans le prochain billet, nous allons voir que cela peut aussi se produire sans “var”!