[TFS2010] Utilisation de l’API pour récupérer les collections de projets et projets au travers de WCF et droits utilisateurs

EDIT 30/06/2011 : je reviens sur ce vieu post pour apporter une modification / autre possibilité pour résoudre le problème évoqué (cf. bas de page)

Les collections de projets sont une nouveauté de Team Foundation Server 2010. Elles permettent de créer des regroupements logiques de projets d’équipe sur le serveur. L’API de TFS2010 permet bien évidemment de travailler avec celles-ci et de récupérer les projets qui y sont contenus.

Le but de ce post est de vous expliquer un scénario qui m’a posé quelques difficultés pour récupérer les projets puisque je suis passé par un service WCF pour ne pas avoir à référencer l’API Team Foundation Serveur sur chacun de mes clients utilisant l’application. Globalement, voici l’architecture mise en place pour ce scénario :

Ah oui, petite chose marrante également, pour des raisons non contournables (et oui ça arrive) le serveur TFS et le serveur IIS sont dans deux domaines différents :)

Seul problème ici, le compte qui exécute le service WCF pour se connecter à Team Foundation Server via l’API ie le compte qui est en charge de l’exécution du pool d’application IIS doit posséder les droits sur le fichier de cache TFS associé au compte utilisateur avec lequel vous vous connectez à l’API TFS. Suis-je clair ? :)

Si on résume :

• Mon pool IIS s’exécute avec le compte IIS APPPOOL\MonSiteWeb
• Je me connecte à l’API TFS avec le compte JCorioland

Deux cas se présentent alors :

• JCorioland possède un compte d’utilisateur sur le serveur (ou domaine) du serveur IIS hébergeant le service WCF : dans ce premier cas, vous devez donner les droits en écriture au compte IIS APPPOOL\MonSiteWeb sur le dossier : C:\Users\JCorioland\AppData\Local\Microsoft\Team Foundation (sur le serveur hébergeant IIS bien sûr)
• JCorioland ne possède pas de compte d’utilisateur : dans ce cas, vous devez donner les droits en écriture au compte IIS APPPOOL\MonSiteWeb sur le dossier : C:\ProgramData\Microsoft\Team Foundation

C’est pour l’instant la seul solution que j’ai trouvé pour faire fonctionner ce code :

var uri = new Uri(tfsUri);
var credentials = new NetworkCredential(tfsUser, tfsPassword);

using (var applicationInstance = new TeamFoundationApplicationInstance(uri, credentials))
{
    applicationInstance.Authenticate();

    using (var tfsServer = applicationInstance.GetTeamFoundationServer(collectionId))
    {
        var teamProjects = new List();

        var wiStore = new WorkItemStore(tfsServer);

        foreach (Project project in wiStore.Projects)
        {
            teamProjects.Add(new TeamProjectMessage
            {
                Name = project.Name,
                Uri = project.Uri.ToString(),
                CollectionId = collectionId,
                TeamFoundationServerUri = tfsUri
            });
        }

        return teamProjects;
    }
}

Si l’opération décrite ci-dessus n’est pas faite, impossible de passer l’instanciation du WorkItemStore. Il doit être possible de faire beaucoup plus propre que cela en faisant de l’impersonation, mais comme je suis sur deux domaines différents, impossible de réussir quelque chose de vraiment propre. Si quelqu’un a une autre solution, je suis preneur !

EDIT 30/06/2011 : il est également possible de déplacer le cache de Work Items vers un répertoire sur lequel le pool ASP.NET / utilisateur qui se connecte à l’API possède des droits d’accès en écriture en ajoutant une clé de configuration dans le fichier de configuration du service exploitant l’API TFS :

<add key="WorkItemTrackingCacheRoot" value="C:\\tempWICache" />

A bientôt !