TFVC fails with a non-English version of TF.exe

[alexmtnezf]

I'm trying to connect using my Personal Token on my Team Services account, and Visual Studio Code always report this:
"2017-04-17T04:06:19.073Z - error: [13588] It appears you have configured a non-English version of the TF executable. Please ensure an English version is properly configured."

My Visual Studio 2017 has its TF.exe in this path:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\TF.exe",

This is a screenshot of the error:

[alelapeyre]

See this #177

[jeffyoung]

Hi @alexmtnezf and thanks @alelapeyre.

I'd be interested in seeing the output (as much as you can show) from this command: tf.exe workfold {path-to-the-folder-you-opened}. If I'm correct, the output from that command won't contain the English version of Workspace :. @alelapeyre points to the thread with a bit more explanation.

[scaillerie]

@jeffyoung I have the same issue and running the tf command, I obtain the following output :

Espace de travail : MY_WORKSPACE
Collection        : https://tfs-server/tfs/MY_COLLECTION_NAME
$/MY_PROJECT/Dev/MY_WORKING_FOLDER: <PATH_TO_MY_LOCAL_FOLDER>

(as you can see, I work in France...).

[scaillerie]

I have tested the tip provided by @MindGirl on issue #177 but it doesn't work for me (I have renamed the directory "fr" by another name, and executing again the command always gives me the result in french)...

[MindGirl]

Have you restarted your shell (cmd.exe or powershell)?

[scaillerie]

Of course : I have even launch a new shell after the renaming...

[MindGirl]

Just wanted to make sure :-)
Do you execute tf.exe using the full path?

[scaillerie]

I use the following command :
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\tf.exe" workfold "FULL_PATH_TO_MY_FOLDER"

[MindGirl]

Can you try to prefix the folder name (I renamed mine from "de" to "xde")? Or remove the underscore?

[scaillerie]

I have try with "xfr" and opening a brand new shell and re-executing the command, same result : in french...

I don't understand: it looks like the locale is cached or not taken in this folder (I have double checked that it is really the same folder than the tf.exe executable).

[jeffyoung]

Can you also ensure that there are no running instances of tf.exe? This issue only affects tf.exe (as the TEE CLC can be set to return ENU only results) and, for some reason, the French resources are being loaded (even though they shouldn't be found since the folder has been renamed). You may want to ensure that VS Code is closed when you do it. (To improve performance in the editor, we try and keep an instance of tf.exe running and ready to run commands when a user takes an action in VS Code. If you close VS Code, those should be closed as well.)

[scaillerie]

I have checked : there is no more tf.exe process running.
To be sure, I have even closed Visual Studio which I use for another project, but no way, always in french.

The only remaining point is that I have the TFS Power tools installed and I don't succeed to kill it (TfsComProviderSvr.exe is automatically relaunched after I kill it and I don't find any associated service I can suspend or other...).

[jeffyoung]

Ideally, the tf.exe (and its dependencies) would be a tool that you could get on its own. That is, separate from Visual Studio. If we had that, we could just install the English version of TF.exe and point the extension there (problem solved). I don't know if there are plans for that but what appears to be happening is the Microsoft.TeamFoundation.VersionControl.Common.dll is being loaded from another folder even after you rename the one under Common7\IDE.

I have a French version of Windows running (in a VM) and TF.exe loads that assembly from C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\WDExpressExtensions\gn4drvgq.y0a\fr\Microsoft.TeamFoundation.VersionControl.Common.resources.dll. I know this because I ran procmon.exe from https://live.sysinternals.com/ and filtered on the process with Process Name of TF.exe (and with .resources. in the filter for Path). If you do the same, you'd discover from where that resource assembly is being loaded. It certainly doesn't look predictable based on that folder named gn4drvgq.y0a. Once I went into that folder and renamed fr to something else, TF.exe failed to load the French resources and fell back to the English ones inside of TF.exe. (This is basically what @MindGirl was helping you to do.)

Renaming that folder could have some unknown side-effects (and certainly isn't a long-term workaround). I'd either have to start parsing localized strings or we'd have to get an English version of TF.exe on the box (even through another downloaded version of Visual Studio). But it may suffice in the short-term (although you'd need to determine from where the assembly is being loaded using procmon).

[scaillerie]

Oh ok : good method! I have procmon on my PC but don't think to use it for this problem...
On my PC, it was in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\crfdgovc.tzv\fr.
And after renaming, the output was finally in english and most important, it now works!

Nevertheless, as my team uses large projects, we mainly work with server workspaces (I have created a sample local workspace in order to test) : I am now watching issue #176 as I have a workaround for language issue :-)

Thanks for your help and this great extension!

[alexmtnezf]

The solution offered by @MindGirl worked for me. Thanks to @jeffyoung too. I renamed the es folder to es-xx and voilá, there's not error anymore.

[jeffyoung]

Great to hear! Thanks for following up.