How to change credential for TFS server without causing problems with builds

I changed the credentials for the tfs server source control and since then I get this error message when trying to get latest source. How can I fix this ?

An unhandled exception occurred while executing this action: Microsoft.TeamFoundation.VersionControl.Client.MappingConflictException: The path D:\BuildMaster_SVCTMP\SrcRepos\sw12-tfs01_8080_tfs_Atlas is already mapped in workspace BM-***********.
at Inedo.BuildMaster.Extensibility.Actions.RemoteCommandExecution.RemoteCommandExecuter.ExecuteCommand(RemoteActionBase remoteAction, String commandName, String[] commandArgs)
at Inedo.BuildMaster.Extensibility.Agents.Local.LocalAgent.Inedo.BuildMaster.Extensibility.Agents.IRemoteCommandExecuter.ExecuteCommand(RemoteActionBase action, String commandName, String[] commandArgs)
at Inedo.BuildMaster.Extensibility.Actions.RemoteActionBase.ExecuteRemoteCommand(String name, String[] args)
at Inedo.BuildMaster.Extensibility.Actions.ProviderBasedAction`1.Execute()
at Inedo.BuildMaster.Extensibility.Actions.ActionBase.ExecuteInternal(IActionExecutionContext context, ExtensionConfigurerBase extensionConfigurer, Boolean resumeNextOnError, Boolean logErrorsAsWarnings)

Product: BuildMaster
Version: 4.9.6

Hi Alexis,

That error is coming from TFS, and has something to do with a mismatched/duplicate workspace. In later versions of VS/TFS, they try to abstract that complexity away, but it's still implemented, and sometimes causes problems.

So, to resolve it for BuildMaster (or if you ever come across same message in VS), I would suggest to delete that workspace from the TFS server (a TFS admin can do that), and then also delete the corresponding D:\BuildMaster_SVCTMP\SrcRepos directory.

Hi,

I should have mentioned the troubleshooting steps I took in my initial question.
I did try what you suggested and even went a bit further. here are the steps I took :

In a command prompt, delete the workspace with a tf workspace /delete command
Verified there is no workspace with that name on the tfs server anymore with a tf workspaces command
On the VM on which BuildMaster is installed, delete the ..BuildMaster_SVCTMP\SrcRepos directory
On the VM on which BuildMaster is installed, delete the TFS cache in AppData\Local\Microsoft\Team Foundation
Delete the source control provider in buildmaster
Create a new source control provider with a different name and credentials
Reboot the BuildMaster VM

Even after all that, I still get the error. Also, a tf workspaces command return the owner of the workspace as the new credentials, yet buildmaster return an error message with the old credential, so it appear that Buildmaster is keeping some kind of cache or something like that somewhere.

I would suggest that Buildmaster use a different directory name for the workspace, maybe a new Guid when creating a provider ? Or use the name of the provider instead of the url of the tfs server.

I also though about adding an entre in the host file and use a different address for the server.

But really these are workaround, I would much rather BuildMaster fix it.

Any other suggestions ?

BuildMaster doesn't cache anything related to workspaces, it merely builds the workspace name by convention: https://github.com/Inedo/bmx-tfs/blob/master/Providers/TfsSourceControlContext.cs#L71-L88

If you delete the workspace from the server, that should fix this. By default, tf workspaces only displays workspaces created by you on the machine you run it on. You'll want to make sure you run: tf workspaces /owner:* /computer:* to see the one created by BuildMaster, then delete it with the tf workspace /delete command.

If that doesn't fix it, do you have a subdirectory of that workspace mapped for another project perhaps? I believe that may also cause the issue, but I haven't tried that scenario.

Hi,

Thank you for your time.

I did use the /owner:* flag and deleted the workspace from the TFS server and the Buildmaster VM.

In case someone else run into this problem and find this page.

I worked around this bug by adding a en entry in my host file pointing to my tfs server ip and using this new url with the new credentials.

Glad you were able to find a workaround, but we'd still like to resolve the underlying issue.

Did you make sure to use the /computer:* flag with tf workspaces? If a build was executed on an agent, a workspace could exist on that machine as well, and that command should find it.

Additionally, can you confirm if you have a subdirectory of that workspace mapped for another project? This is most likely the culprit.

Yes, I have used the /computer:* option as well as the /owner:* option for the tf workspaces command.

I also confirm there are no subdirectory of that workspace mapped for another project.

This happened for the first application I configured on a fresh install of Buldmaster.

Have you tried replicating the issue on your side ? Because it's not so hard to reproduce here, I just have to switch the credentials used by the tfs extension and it will happen. It will still happen after all the troubleshooting steps I listed earlier.

Yes I can reproduce the same error, but then when I delete both mapped workspaces, it works fine again.

Are you absolutely certain you're actually deleting the workspace for both users, the previous one and the current one?

You'll essentially have to run 2 commands:

.\TF.exe vc workspace /delete 
   /collection:http://<tfsserver>:8080/tfs/<collection> 
   <BM-workspace-name> /login:<domain\old-user>,<password>

and

.\TF.exe vc workspace /delete 
   /collection:http://<tfsserver>:8080/tfs/<collection> 
   <BM-workspace-name> /login:<domain\new-user>,<password>

I also note that when I tried deleting the workspaces with tf vc workspaces /delete... it didn't actually delete them, I had to use tf vc workspace. Not sure why that is exactly.

Yup, I've deleted both and they do not appear in the list after I deleted them.

The vc part in the tf command is only with the latest version and I am stuck with older software so it may be related to a specific version and that could explain why we have different result.

BuildMaster version Version 4.9.6 (Build 6)
Running on Windows Server 2008 R2 sp1
Using the tf tool from visual studio 2010
Team Foundation Server 2013 Version 12.0.21106.0

It's unfortunate that you are unable to reproduce my issue. At this point, I have found a workaround that is somewhat satisfactory.

Even if the root cause can be attributed to TFS, the issue could be resolved by using another scheme for the local directory name. By using the name instead of the server Url of the TFS source control provider (this name is validated already for uniqueness), I would just have to rename the provider and would not have to enter command or delete local cache.

I agree, the auto-workspace name is problematic in other situations (TFS client library doesn't deal with long file names, for example).

This is definitely something we are planning to address in v5 (due next month), where you will be able to specify a workspace directory instead of auto-generating one. We may change the auto-generated path to do what you suggest as well!

That's great news !

Thank you for following up :)