While upgrading to 5.7.4 (from 5.6.1) we’ve noticed a functional change that has caused a regression for one of our use cases.
We use git as our source control and have Visual Studio Code as part of our standard workstation setup. We’ve added/updated our DefaultEditorPerProjectUserSettings.ini file to launch VSCode as our text diff tool (“TextDiffToolPath=(FilePath=“Code.exe”)”). This is working fine in 5.6.1 but I noticed it has stopped working during my testing of 5.7.4.
Looking at changes to FWindowsPlatformProcess in GitHub I can see this commit the change on GitHub to ([Make FWindowsPlatformProcess::CreateProc and FMacPlatformProcess::Cre… · EpicGames/UnrealEngine[Content removed] but unfortunately that will cause a several hour rebuild due to other (unrelated) technical problems.
When I was originally investigating setting VSCode as the default diff tool app I was running into an issue because the default VSCode installation (at least with winget) is to install into the users directory (eg. “C:\Users\DamonLewis\AppData\Local\Programs\Microsoft VS Code\Code.exe”). On Windows this path can be shortened to “%LOCALAPPDATA\Programs\Microsoft VS Code\Code.exe” but the Win32 api CreateProcess doesn’t expand %LOCALAPPDATA%. I had a change that would manually expand the URL with any macros and that was working fine, but I abandoned that after finding that “Code.exe” works. IF the current behaviour is correct/intentional, this is something I could revive and attempt to upstream.
Any advice on this issue would be appreciated 
[Attachment Removed]
Steps to Reproduce
* Install VSCode via winget (winget install Microsoft.VisualStudioCode)
* Ensure DefaultEditorPerProjectUserSettings.ini exists in the project
* Set “TextDiffToolPath=(FilePath=“Code.exe”)” under “[/Script/UnrealEd.EditorLoadingSavingSettings]”
* Connect to revision control and diff a data table (or any asset that can be diffed as text)
* In 5.6.1 this opens VSCode, in 5.7.4 this says it can’t open Code.exe
[Attachment Removed]
Hi Damon,
At the beginning of your post you mention that “Code.exe” alone worked in 5.6.1 but not 5.7.2, however, later, you mention that abandoned changes for environment variable expansion after finding that “Code.exe” works (which I assume is due to Code.exe being on %PAT%). Can you confirm that that is indeed working under 5.7.2? And that it’s the case of a path referencing an environment variable that worked under 5.6.1 and not under 5.7.2?
You are correct that the Windows API doesn’t expand environment variables and that an explicit call to ExpandEnvironmentStrings on the executable path prior to CreateProcess to support this.
In your winget install of VSCode, is “Code.exe” located under %LOCALAPPDATA%\Programs\Microsoft VS Code or %LOCALAPPDATA%\Programs\Microsoft VS Code\bin?
Best regards.
[Attachment Removed]
I have answers to your questions and the short version is: This never worked, but I thought it did because an absolute path to code.exe got saved into Saved/Config/EditorPerProjectUserSettings.ini file without my knowledge which overrode the value in Config/EditorPerProjectUserSettings.ini.
I’m very sorry for wasting your time on this. I will still answer all of your questions for completeness anyway.
“Can you confirm that that is indeed working under 5.7.2? And that it’s the case of a path referencing an environment variable that worked under 5.6.1 and not under 5.7.2?”
Specifying “Code.exe” as the text diff tool path never truly worked, and I was led to believe it did due to my flawed testing.
“In your winget install of VSCode, is “Code.exe” located under %LOCALAPPDATA%\Programs\Microsoft VS Code or %LOCALAPPDATA%\Programs\Microsoft VS Code\bin?”
Code.exe exists in the “%LOCALAPPDATA%\Programs\Microsoft VS Code” directory. The installation adds an environment variable to the user path to “%LOCALAPPDATA%\Programs\Microsoft VS Code\bin”.
I still want to add support for having VSCode as the default text diff tool for us so my next steps from here will be to revive my work to expand path macros (eg. %LOCALAPPDATA%) before they get passed to the Windows API so we can set “%LOCALAPPDATA\Programs\Microsoft VS Code\Code.exe” as the diff tool path. I already had an engine branch with this change working and only abandoned it due to thinking it wasn’t required. I will create a PR and post to EPS about it as I believe it could be useful for others.
[Attachment Removed]
Hi Damon,
Thanks for clarifying, It is odd that winget results in Code.exe being in the application root and not the \bin subdirectory like the Windows store installation. If you udpated the PATH environment variable to be correct, does Code.exe alone function as expected? CreateProcess should inherit the environment. As for including environment variables in the executable path, a call to ExpandEnvironmentStrings would need to precede the CreateProcess call to support that use case. I’ll check with the dev team if they would consider a change of the sort as a PR.
Best regards.
[Attachment Removed]
“If you udpated the PATH environment variable to be correct, does Code.exe alone function as expected?”
Yes it does. I’ll consider adding some additional tooling around setting an additional environment variable to be what we require instead of an engine change.
Thank you for all the help
[Attachment Removed]
Happy to help Damon. Glad you have a path to resolution.
Best regards.
[Attachment Removed]