Erreur de création d'équipe: le chemin… est déjà mappé à l'espace de travail

Lors de la création d'une nouvelle version dans Team Foundation Server, j'obtiens l'erreur suivante lorsque j'essaie d'exécuter la nouvelle version:

Le chemin C: \ Build \ ProductReleases \ FullBuildv5.4.2x \ Sources est déjà mappé à l'espace de travail BuildServer_23.

Je ne parviens pas à voir un espace de travail portant ce nom dans la boîte de dialogue des espaces de travail.

Utilisez l'utilitaire de ligne de commande TF - Team Foundation Version Control Tool ( tf ).

Vous pouvez obtenir une liste de tous les espaces de travail en affichant une invite de commande Visual Studio, puis en passant à votre dossier d'espace de travail et en émettant les commandes suivantes:

C:\YourWorkspaceFolder>tf workspaces /owner:*

Vous devriez voir votre espace de travail à problèmes dans la liste ainsi que son propriétaire.

Vous pouvez supprimer l'espace de travail avec la commande suivante:

C:\YourWorkspaceFolder>tf workspace /delete /server:BUILDSERVER WORKSPACENAME;OWNERNAME

Supprimez simplement le contenu du ou des dossiers suivants:

C: \ Users \ UserName \ AppData \ Local \ Microsoft \ Team Foundation \ 3.0 \ Cache

Où UserName est l'utilisateur réel ou actuel et 3.0 est le numéro de version.

J'ai reçu cette erreur, qui a été causée par deux définitions de construction qui pointaient vers la même source. Le problème était que j'utilisais un répertoire de construction statique dans Build Agent.

Ce message de forum décrit exactement mon problème et ma résolution: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/60a4138a-9b28-4c46-bdf4-f9775ce43c3e/

J'ai eu un problème similaire et pour supprimer l'espace de travail qui me causait un problème, je me suis connecté à une autre machine avec le client TFS installé et j'ai effectué les opérations suivantes:

• Dans le menu Fichier , pointez sur Contrôle de code source , Avancé , puis cliquez sur Espaces de travail ... .
• Dans la boîte de dialogue Gérer les espaces de travail , cochez la case Afficher les packages distants case .
• Sous la colonne Nom , sélectionnez l'espace de travail que vous souhaitez supprimer, puis cliquez sur Supprimer .
• Dans la boîte de dialogue Confirmation , cliquez sur OK .

Nous avons eu le même problème mais la suppression des espaces de travail du serveur TFS n'a pas fonctionné. (Je dois mentionner que j'ai saisi la VM de mes collègues qui était déjà configurée avec ses informations d'identification.)

Pour moi, cela a fonctionné: http://blogs.msdn.com/b/buckh/archive/2006/09/12/path-is-already-mapped-in-workspace.aspx

Je suis juste allé dans le: ... \ Local Settings \ Application Data \ fait une recherche pour VersionControl.config, ouvert le dossier qui contenait ce fichier et supprimé tout son contenu.

Avant cela, j'ai essayé de modifier manuellement le fichier, mais cela a continué avec le même message d'erreur.

J'espère que ça aide.

Pour une raison quelconque, j'avais du mal à supprimer l'espace de travail de l'utilitaire de ligne de commande. Heureusement, j'ai trouvé Team Foundation Sidekicks 2010 (à partir de cet article ) qui est gratuit et fournit une interface graphique pour afficher et supprimer les espaces de travail TFS, et de nombreuses autres fonctionnalités TFS utiles.

J'ai eu un problème similaire avec Visual Studio 2010 en me plaignant d'un espace de travail déjà mappé, mais au lieu de supprimer tout l'espace de travail, j'ai utilisé ce qui suit à partir de l'invite de commande de Visual Studio: "tf workspace PROBLEM_WORKSPACE_NAME". Cela a fait apparaître une boîte de dialogue "Modifier l'espace de travail". De là, j'ai pu supprimer le chemin d'accès en question de la liste "Dossiers de travail", ce qui a éliminé l'erreur.

le reste était assez facile.

Accédez simplement à ce dossier: C: \ Users {UserName} \ AppData \ Local \ Microsoft \ Team Foundation \ 4 \ Cache et supprimez tout ce qui se trouve dans le dossier.

J'obtenais une exception m'indiquant que le fichier était déjà mappé dans un autre espace de travail: "Le chemin {Chemin du fichier} est déjà mappé dans l'espace de travail {Nom de l'espace de travail}."

Cet espace de travail a été supprimé avant . Avec l'aide d'un de mes amis, j'ai découvert que TFS enregistrait les informations de l'espace de travail sous le répertoire des paramètres locaux de l'utilisateur. Nous avons trouvé un fichier nommé:

VersionControl.config sous {dir Documents utilisateur et paramètres} \ Local Settings \ Application Data \ Microsoft \ Team Foundation \ 1.0 \ Cache. Ce fichier contient tout le mappage local de TFS. Probablement lorsque vous utilisez la méthode Map et que vous n'utilisez pas: public void DeleteMapping (WorkingFolder mapping); avant de supprimer l'espace de travail, les informations de mappage ne sont pas supprimées de ce fichier qui est utilisé par TFS pour vérifier si vous avez déjà mappé un chemin spécifique.

Pour résoudre ce problème, supprimez toutes les clés du fichier de configuration. Ne supprimez pas le fichier car vous le récupérerez à partir du cache du serveur.

Voici ce que j'ai fait (enfin ce que je fais):

L'utilisation de TFS Sidekicks efface les filtres utilisateur et serveur afin qu'ils soient vides. Cela vous permettra d'obtenir tous les espaces de travail.

Vérifiez l'erreur de construction pour le nom de l'espace de travail. Dans le cas des OP, il s'agit de BuildServer_23. C'est différent dans mon environnement, mais il suffit de faire correspondre le nom de l'erreur avec celui de la liste des acolytes tfs.

Cliquez sur le x rouge pour supprimer l'espace de travail.

Alto!

Si vous ne disposez pas des autorisations sur le serveur pour supprimer les espaces de travail d'autres personnes, vous pouvez simplement modifier le nom de la définition de build. TFS créera un nouvel espace de travail et le mappera sur "C: \ Build \ ProductReleases \ new build name here \ Sources".

Le cas échéant, vous pouvez également cloner la définition de build et modifier son nom. Cela a fonctionné pour moi.

J'ai essayé toutes les solutions suivantes telles que:

1. Utilisez des sidekicks pour supprimer WS.
2. Utilisez les commandes tf pour supprimer les espaces de travail du serveur distant.
3. Supprimez le dossier de cache TFS.

Ce qui suit a fonctionné pour moi:

tf workspaces /remove:*

j'ai changé

Build Definition -> Workspace -> Build Agent Folder

de

c:\some\path

à

$(SourceDir)

et il a résolu le problème.

En essayant de 'Obtenir la dernière version' d'un projet que j'avais précédemment mappé dans un répertoire local puis supprimé, j'ai vu ce même message d'erreur. J'ai d'abord essayé l'outil SideKick, puis l'invite de commande de Visual Studio 2010, qui m'ont tous deux indiqué qu'aucun espace de travail n'était mappé.

Ensuite, j'ai recherché 'VersionControl.config' à l'intérieur c:/users/myuser/appdataet j'ai supprimé les 4 références trouvées. J'ai rouvert Visual Studio et j'ai pu remapper le projet, plus d'erreur!

Le moyen le plus simple de le faire est d'accéder à votre AppData et de supprimer le cache TFS (selon la version 3.0 ou 4.0)

C: \ Users {UserName} \ AppData \ Local \ Microsoft \ Team Foundation \ 3.0 \ Cache ou C: \ Users {UserName} \ AppData \ Local \ Microsoft \ Team Foundation \ 4.0 \ Cache

La solution de TDN a fonctionné pour moi lorsque j'avais le même problème. Le serveur Build a créé des espaces de travail sous mon compte. Cocher cette case m'a permis de les voir et de les supprimer.

J'ai eu le même problème dans Visual Studio 2017 et TFS 2017. DefaultCollection doit d'abord être mappé sur votre chemin local. D'une manière ou d'une autre, cette étape a été ignorée et je n'ai mappé que MyFirstProject.

Tout ce que vous avez à faire est de:
- 1. Accédez à votre page Web TFS et supprimez le projet du serveur.

- 2. Supprimez le projet de votre "Worksapces" local

- 3. Allez dans "Gérer les connexions" qui actualisera votre page d'accueil dans TeamExplorer.

- 4. Vous obtiendrez la page de configuration qui vous permettra de configurer le chemin racine de votre DefaultCollection.

- 5. Vous devriez recevoir un message indiquant que cela a été fait avec succès. Vous pouvez maintenant créer votre projet.

Il est important de mapper d'abord la racine de votre collection à votre espace de travail, puis de mapper un nouveau projet.

Mon problème était lié à l'utilisation de plusieurs comptes. C'est ainsi que j'ai pu changer de compte.

Ouvrez Team Explorer

Dans le grand menu déroulant près du haut du volet ...

Accédez à: Projets et mes équipes > Gérer les connexions

Accédez à: Gérer les connexions > Se connecter à Team Project

Utilisez le lien "Changer d'utilisateur" pour changer de compte.

Désormais, les noms des espaces de travail correspondent au compte choisi.

Je n'ai pas pu faire fonctionner une autre solution.

J'avais un nouveau compte créé et l'ancien compte n'avait plus d'autorisations (les deux sur la même machine).

J'ai essayé: 1) Suppression de l'espace de travail (impossible de voir dans VS avec ou sans espaces de travail distants cochés) 2) Suppression de la ligne de commande 3) Nouvelle commande propriétaire 4) Suppression du cache

J'ai donc simplement ouvert VS en tant qu'administrateur et mappé vers un dossier différent.

J'ai eu ce problème avec les builds automatisés Azure DevOps dans un agent de build TFS sur site. La suppression de l'espace de travail à l'aide de TFS Sidekicks n'a pas fonctionné. Et tf.exe n'a même pas pu trouver l'espace de travail pour le supprimer.

Cette solution devrait fonctionner pour TFS 2017, TFS 2018, Azure DevOps et éventuellement d'autres versions:

1. Notez le GUID de l'espace de travail dans le message d'erreur.
2. Sur la machine sur laquelle la génération a lieu, accédez à:% USERPROFILE% \ AppData \ Local \ Microsoft \ Team Foundation \ (où% USERPROFILE% appartient à l'utilisateur qui a déclenché la génération).
3. Recherchez et supprimez toutes les instances du GUID de l'espace de travail sous ce répertoire. Il y aura probablement un dossier dans un répertoire «cache», ainsi que des entrées dans «LocationServerMap.xml» et «LocalItemExclusions.config». Retirez-les tous.

Cela a fonctionné dans ma situation.

Supprimez simplement l'espace de travail:

workspace /delete "the-workspace-name"