extensionHost launch ignores runtimeExecutable

[vaclavHala]

Type: Bug

Create launch.json like this

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Different Version of VSCode",
            "type": "extensionHost",
            "request": "launch",
            "runtimeExecutable": "/path/to/some/VSCode/code"
        }
    ]
}

and launch it (pick path to different version of VSCode than the one you launch it from).

Expected behavior:

When I look into help -> about I see the new VSCode is the one I put into runtimeExecutable (by looking at version)

Actual behavior:

The launched VSCode always uses same executable as the one I launched it from (${execPath}). Also if I put some garbage into the runtimeExecutable field like foobar second VSCode still launches, making me think that field is just ignored completely

This is especially hurtful for us as we'd like to have version to use baked into the launched configuration for our tests so any developer who launches that gets the same environment every time, no matter what version they use to develop

VS Code version: Code 1.87.0 (019f4d1419fbc8219a181fab7892ebccf7ee29a2, 2024-02-27T23:42:16.599Z) OS version: Linux x64 4.19.0-18-amd64 Modes:

System Info

|Item|Value| |---|---| |CPUs|AMD Ryzen 7 2700 Eight-Core Processor (16 x 2627)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: disabled_software
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off| |Load (avg)|3, 2, 3| |Memory (System)|31.43GB (22.62GB free)| |Process Argv|--enable-proposed-api genuitecllc.codetogether --crash-reporter-id b7de6dff-a380-43b3-8eb5-e5e11c79fe00| |Screen Reader|no| |VM|0%| |DESKTOP_SESSION|xfce| |XDG_CURRENT_DESKTOP|XFCE| |XDG_SESSION_DESKTOP|xfce| |XDG_SESSION_TYPE|x11|

Extensions: none

[VSCodeTriageBot]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.87.2. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

[vaclavHala]

@VSCodeTriageBot yes exactly the same thing happens with 1.87.2

[roblourens]

I think this is by design and not sure I understand the scenario. I recommend always using and developing against the latest vscode. Trying to debug the extension host of a vscode instance of some other version may not work when the two are out of sync.

[vaclavHala]

Well the scenario is

• Consistency (any developer who checks out given repo and runs tests therein should get the same result, no matter what version of VSCode they use to run those tests)
• Testing of backwards compatibility - we are working on an extension that should work (in some limited capacity) with older versions of VSCode as well as the most recent ones. To ensure this is actually the case we run some subset of our test suite using the latest as well as selected prior VSCode releases

These work fine when run from terminal using https://github.com/microsoft/vscode-test as I can specify

await runTests({
  version: anyVersionIWantToUse,

It is inconvenient though that similar thing can' be done when running from launch.json, not least of which because it makes it complicated to attach debugger to such tests.

Trying to debug the extension host of a vscode instance of some other version may not work when the two are out of sync.

I don't know the technical details of what goes on behind the scenes, but I can't see why this should be the case from extension developers point of view. I'm not running VSCode itself from source and can't actually step into it in the debug session (well I can, but will see minified JS only). From my point of view it should be the same as when I just run any old external node app, the entrypoint executable just sometimes happens to be the code from process.argv[0] and other times it is some other code I give it as path via the runtimeExecutable

Does this answer your question or is there some more info I should provide?

[vaclavHala]

@roblourens I just noticed some of the options we try to pass to the vscode launched for test are ignored, in particular --extensions-dir and --user-data-dir have no effect. Is this also intentional?

This is even worse problem than being unable to set custom runtimeExecutable as it makes it impossible to run the tests in controlled environment from the point of view of other extensions present while the tests run. Originally we ran our tests using --profile-temp which was respected, but now since we have some extensionDependencies that is no longer an option. I'm sure you can see the set of dependencies our extension requires at runtime can be very different from what individual developers of the extension have installed in their development instances. We also want changes done to user configuration during the test run to not affect actual user configuration in home folder of the developer.

Our launch.json works like this now

"args": [
    "${workspaceFolder}/.vscode-test/ws/test.code-workspace",
    // share extensions and user data with test run via `npm run test-vscode`
    // can't simply --profile-temp because we need the 3rd party extensions we depend on preinstalled in the environment
    "--extensions-dir=${workspaceFolder}/.vscode-test/extensions",
    "--user-data-dir=${workspaceFolder}/.vscode-test/user-data",
    "--extensionDevelopmentPath=${workspaceFolder}/out-src",
    "--extensionTestsPath=${workspaceFolder}/out-test/test-vscode-entrypoint.js",
],

The .vscode-test/extensions folder gets populated by code we use to run the tests from terminal, again using @vscode/test-electron which behaves as expected

const vscodeExecutablePath = await vscodeTest.downloadAndUnzipVSCode(versionVscode);
const [cli, ...args] = vscodeTest.resolveCliArgsFromVSCodeExecutablePath(vscodeExecutablePath);

for(const dep of extensionDependencies){
    const installResult = cp.spawnSync(cli, [...args, '--install-extension', dep], {
        encoding: 'utf-8',
        stdio: 'inherit'
    });
    // check result, report error...
}

Here is what I mean when I say the --extensions-dir and --user-data-dir options are ignored:

When I run the Extensions: Open Extensions Folder (inside the VSCode launched for test) it takes me to the correct folder, but the extensions from it are not actually used. Instead extensions from my development instance are shown, and marked as disabled. I suspect this is because the --user-data-dir has no effect - when I run Preferences: Open User Settings (JSON) (inside the test instance) it takes me into my home directory, not the path I provided, so the list of extensions to use (I suppose the list is stored somewhere in the user data dir rather than just using whatever is found in the extensions dir) comes from my development instance rather than the one I want to run the tests in.

[connor4312]

Yea, this is by design at the moment. VS Code does some special stuff to hook up debugging via communication through its main process, and doing that across instances of VS Code is not readily feasible.