Error when starting a 2nd VS Code+Ada ext with recent versions of VS Code

[JHag6694]

Hello

I have noticed that, in my environment, since VS Code 1.86, Ada extension triggers an error on start if another VS Code is already running

To rephrase

• I have a VS Code started WITHOUT Ada extension activated, to work on workspace A
• If I start a 2nd VSCode - on workspace B - with Ada Extension activated, I get the following in the Problem pane :

• 

Same behavior with Ada extension 24.0.3, 24.0.4 or 24.0.5 :

• No problem until VS Code 1.85
• Problem since VS Code 1.86

No problem if I open the same workspace WITHOUT other VSCode started

Is there any log option/log file I should activate/analyze?

[AnthonyLeonardoGracio]

Hello @JHag6694,

That's really strange indeed. This looks like an environment problem to me: it seems that VS Code does not pass your environment variables to the Ada Language Server in one case, for an unknown reason.

Can you run the Ada: Show extension output command and send us the output on a session that exhbits the issue? If you could share the corresponding Ada Language Server log in your ~/.als folder that would help too.

Regards,

[JHag6694]

You are right:
According to the extension output I saw with 'Ada: Show extension output', it seems that ALS inherits the environment of the 1st VS Code "process". FYI, in both case, VS Code is started from a CMD prompt with specific environment variables according to the context. And, in the second run, as my .gpr file uses some environment variables that are wrong or undefined, it triggers the error.

Same problem if I start VS Code with '--profile "Ada dev"'

[reznikmm]

I my point of view, this is expected, because (AFAIK) VS Code doesn't launch a new process when you start new editor. This way it can't inherit new environment for second invocation. I suggest to configure explicit environments as described there:

https://github.com/AdaCore/ada_language_server/wiki/Set-workspace-specific-environment-variables

[JHag6694]

Thanks for the link.

As this issue is not related to ALS VS Code extension, but to a VS Code behavior change, I guess this issue can be closed.

To reproduce it: Under Windows, from a command prompt

1. Start VS code
2. Set a new environment variable (or change an existing one)
3. Start VS Code 2nd instance
4. Check environment variable from Terminal inside VS Code 2nd instance

With VS Code 1.85- : variable visible (or changed) With VS Code 1.86+: variable NOT visible (or unchanged)

[AnthonyLeonardoGracio]

Indeed, we can't have control on that unfortunately. The best way to avoid that is to set the environment needed for a given workspace in the settings, as explained in the doc mentioned above.

Closing this ticket then.

[JHag6694]

Indeed, we can't have control on that unfortunately. The best way to avoid that is to set the environment needed for a given workspace in the settings, as explained in the doc mentioned above.

Hello @reznikmm @AnthonyLeonardoGracio

FYI, adding '--preserve-env' in the command line seems to allow to retrieve previous behavior.

Refs.

• https://github.com/microsoft/vscode/issues/194736
• https://github.com/microsoft/vscode/commit/5260b203172155949040d89e7de897ddb5975937
• https://github.com/microsoft/vscode/issues/212964

[AnthonyLeonardoGracio]

Indeed, we can't have control on that unfortunately. The best way to avoid that is to set the environment needed for a given workspace in the settings, as explained in the doc mentioned above.

Hello @reznikmm @AnthonyLeonardoGracio

FYI, adding '--preserve-env' in the command line seems to allow to retrieve previous behavior.

Refs.

• Issue with PATH expansion in VSCode subprocess on macOS microsoft/vscode#194736
• microsoft/vscode@5260b20
• In 2nd VSCode run, environment variables are no longer inherited from the current process  microsoft/vscode#212964

Ah interesting, thanks for the tip!