Erreur de génération en équipe: le chemin ... est déjà associé à un espace de travail
Lors de la création d'une nouvelle génération dans Team Foundation Server, le message d'erreur suivant s'affiche lors d'une tentative d'exécution de la nouvelle génération:
Le chemin C:\Build\ProductReleases\FullBuildv5.4.2x\Sources est déjà associé à l'espace de travail BuildServer_23.
Je ne parviens pas à voir un espace de travail portant ce nom dans la boîte de dialogue Espaces de travail.
Utilisez l'utilitaire de ligne de commande TF - Outil de contrôle de version Team Foundation ( tf ).
Vous pouvez obtenir une liste de tous les espaces de travail en ouvrant une invite de commande Visual Studio, puis en modifiant votre dossier d’espace de travail et en lançant les commandes suivantes:
C:\YourWorkspaceFolder>tf workspaces /owner:*
Vous devriez voir votre espace de travail de problème 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:\Utilisateurs\Nom d'utilisateur\AppData\Local\Microsoft\Team Foundation\3.0\Cache
Où UserName est l'utilisateur actuel ou actuel et 3.0 le numéro de version.
J'ai reçu cette erreur, causée par deux définitions de construction qui pointaient vers la même source. Le problème était que j'ai utilisé un répertoire de construction statique dans l'agent de génération.
Ce message sur le 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/
Nous avons eu le même problème, mais la suppression de l'espace de travail du serveur TFS ne fonctionnait pas. (Je dois mentionner que j'ai saisi mes collègues VM déjà configurés 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 viens d’entrer dans: ...\Paramètres locaux\Application Data\fait une recherche sur VersionControl.config, ouvre le dossier contenant ce fichier et supprime tout son contenu.
Avant cela, j’essayais d’éditer manuellement le fichier mais le message d’erreur restait le même.
J'espère que ça aide.
J'ai eu un problème similaire et pour supprimer l'espace de travail qui me causait un problème, je me suis connecté à un autre ordinateur avec le client TFS installé et j'ai exécuté les opérations suivantes:
- Dans le menu Fichier , pointez sur Contrôle de la 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 .
- 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 surOK.
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 (from this post ) qui est gratuit et fournit une interface graphique permettant d'afficher et de supprimer des espaces de travail TFS, ainsi que de nombreuses autres fonctionnalités utiles de TFS.
J'ai eu un problème similaire avec Visual Studio 2010 qui se plaignait d'un espace de travail déjà mappé, mais au lieu de supprimer l'intégralité de l'espace de travail, j'ai utilisé ce qui suit à partir de l'invite de commande Visual Studio: "espace de travail tf PROBLEM_WORKSPACE_NAME". Cela a amené une boîte de dialogue "Modifier l'espace de travail". A partir de là, j'ai pu supprimer le chemin en question de la liste "Dossiers de travail", ce qui a permis d'éliminer l'erreur.
le reste était assez facile.
Allez simplement dans ce dossier: C:\Utilisateurs {Nom d'utilisateur}\AppData\Local\Microsoft\Team Foundation\4\Cache Et supprimez tout ce qui se trouve dans le dossier.
Voici ce que j'ai fait (bien ce que je fais):
L'utilisation de TFS Sidekicks supprime 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 PO, il s'agit de BuildServer_23. C’est différent dans mon environnement, mais en gros, faites simplement correspondre le nom de l’erreur avec celui de la liste des sidekick de tfs.
Cliquez sur le x rouge pour supprimer l'espace de travail.
Alto!
Je recevais une exception me disant que le fichier était déjà mappé dans un autre espace de travail: "Le chemin d'accès {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é de beofre . Avec l'aide d'un de mes amis, j'ai découvert que TFS enregistre les informations relatives à l'espace de travail sous le répertoire des paramètres locaux de l'utilisateur. Nous avons trouvé un fichier nommé:
VersionControl.config sous {Répertoire Documents et paramètres utilisateur}\Paramètres locaux\Données de l'application\Microsoft\Team Foundation\1.0\Cache. .__ Ce fichier contient tout le mappage local de TFS. Probablement lorsque vous utilisez la méthode Map et n'utilisez pas: Public void DeleteMapping (mappage de WorkingFolder); avant de supprimer l'espace de travail, les informations de mappage ne sont pas supprimées de ce fichier 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 du cache du serveur.
J'ai essayé toutes les solutions suivantes telles que:
- Utilisez des sidekicks pour supprimer WS.
- Utilisez les commandes tf pour supprimer les espaces de travail du serveur distant.
- Supprimez le dossier de cache TFS.
Ce qui suit a fonctionné pour moi:
tf workspaces /remove:*
Le cas échéant, vous pouvez également cloner la définition de construction et changer son nom. Cela a fonctionné pour moi.
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 construction. TFS créera un nouvel espace de travail et le mappera sur "C:\Build\ProductReleases\nouveau nom de construction ici\Sources".
J'ai changé
Build Definition -> Workspace -> Build Agent Folder
de
c:\some\path
à
$(SourceDir)
et cela a résolu le problème.
Supprimez simplement l'espace de travail:
workspace /delete "the-workspace-name"
La solution de TDN a fonctionné pour moi alors que j'avais le même problème. Le serveur de génération a créé des espaces de travail sous mon compte. Cocher cette case m'a permis de les voir et de les supprimer.
Mon problème était lié à l'utilisation de plusieurs comptes. Voici comment j'ai pu changer de compte.
Ouvrir Team Explorer
Dans le grand menu déroulant près du haut de la fenêtre ...
Accédez à: Projets et mes équipes > Gérer les connexions
Accédez à: Gestion des connexions > Connexion au projet d'équipe
Utilisez le lien "Changer d'utilisateur" pour changer de compte.
Maintenant, les noms des espaces de travail correspondront au compte choisi.
J'ai 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 seul MyFirstProject a été mappé.
Tout ce que vous devez faire c'est:
- 1. Accédez à votre page Web TFS et supprimez le projet du serveur.
- 2. Supprimez le projet de vos "Worksapces" locales
- 3. Allez dans "Gérer les connexions" qui actualisera votre page d'accueil dans TeamExplorer.
- 4. Vous obtiendrez une page de configuration qui vous permettra de configurer le chemin racine de votre collection par défaut.
- 5. Vous devriez recevoir le message que cela a été fait avec succès. Maintenant, vous pouvez créer votre projet.
Il est important de mapper d'abord la racine de votre collection sur votre espace de travail, puis un nouveau projet.
La façon la plus simple de procéder consiste à accéder à votre AppData et à supprimer le cache TFS (selon la version 3.0 ou 4.0).
C:\Utilisateurs {Nom d'utilisateur}\AppData\Local\Microsoft\Fondation Team\3.0\Cache Ou C:\Utilisateurs {Nom d'utilisateur}\AppData\Local\Microsoft\Fondation Team\4.0\Cache
Lors de la tentative d'obtention de la dernière version d'un projet que j'avais précédemment mappé sur un répertoire local, puis supprimé, j'ai vu le même message d'erreur . dont m'a dit que je n'avais aucun espace de travail cartographié.
Ensuite, j'ai cherché 'VersionControl.config' dans c:/users/myuser/appdata et supprimé les 4 références qu'il a trouvées . J'ai rouvert Visual Studio et j'ai pu remapper le projet, plus d'erreur!
J'ai eu ce problème avec cela avec les générations automatisées Azure DevOps dans un agent de génération TFS sur site. La suppression de l'espace de travail à l'aide de TFS Sidekicks ne fonctionnait pas. 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:
- Prenez note de l'espace de travail GUID dans le message d'erreur.
- Sur la machine où la génération est en cours, accédez à:% USERPROFILE%\AppData\Local\Microsoft\Team Foundation\(où% USERPROFILE% appartient à l'utilisateur qui a déclenché la génération).
- Recherchez et supprimez toutes les instances de l'espace de travail GUID dans 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.