Initializing crypt32-{arch}.node fails in vscode extensions when run in vscode Insiders 1.31.0

[StephenWeatherford]

See microsoft/vscode-docker#733.

I assume this is related #8, but I don't fully understand the issues involved. vscode runs in Electron, but extensions run in a separate process, so I assume Electron has no effect on them. VS Code Insiders 1.31 has switched from Node 8.9.3 to 10.2.0, and process.versions.nApi is set to "3" there. If I force each.fallback to load, I don't have any problems.

Any ideas on what's going on here? Is it somehow a vscode issue? Thanks!

process.versions on VS Code 1.30.2:

process.versions on VS Code Insiders 1.31.0:

[ukoloff]

Well, DLL loading should fail under Electron, this is okay. But this must never happen due to detecting of Electron. My first idea is that the detection is broken.

Do you know the version of Electron used in VS Code Insiders 1.31?

[ukoloff]

Detection is delegated to is-electron and win-ca uses the newest version of it.

[StephenWeatherford]

@bpasero This appears to be caused by the move to Electron 3 (microsoft/vscode#52629). win-ca (see also microsoft/vscode#52880, cc @chrmarti) is trying to use load an N-API module(?), but this fails on Electron (microsoft/vscode#52880), so it uses a fallback if it detects it's running on Electron. This detection returns false in a vscode extension, so the fallback isn't used and loading the module fails.

Does the vscode extension process run in an Electron context? I had thought not, but not sure exactly what that means.

[ukoloff]

I also don't understand the details of interaction between Electron & VS Code. It looks like VS Code hides Electron.

is-electron checks window.process.renderer, process.versions.electron and navigator.userAgent, but window == navigator == undefined and process.versions knows nothing about electron.

So, we should somehow detect we are running in VS Code Extension Host, but I have no idea how to do it.

[bpasero]

@StephenWeatherford the extension host process is running in a forked Electron process, that is a node.js environment but with the V8 version of Electron.

Please note that we currently do not recommend to use native modules in extensions for this reason, you will have to update the extension for each Electron update we do. In the future we will investigate to support N-API to make this a bit easier for extension authors.

[ukoloff]

@StephenWeatherford the extension host process is running in a forked Electron process, that is a node.js environment but with the V8 version of Electron.

Okay, thank you for clarification.

Please note that we currently do not recommend to use native modules in extensions for this reason, you will have to update the extension for each Electron update we do. In the future we will investigate to support N-API to make this a bit easier for extension authors.

Well, NOT using N-API while in Electron is my first idea. It should work fine. The problem is how to detect when win-ca is run inside VS Code Extension Host?

Before it was also Electron and could be detected by is-electron. Now it is still Electron, but looks like regular Node.js.

Is there official way to detect we're running under VS Code Extension Host?

[bpasero]

@ukoloff may I ask why you need to know that you are running inside the extension host?

[ukoloff]

@ukoloff may I ask why you need to know that you are running inside the extension host?

I only need a hint - is N-API available or should we fallback.

I mean regular N-API. Electron uses its own N-API, I don't want to use it. If I could detect Electron, it would suffice.

In other words: is N-API regular or Electron-style? This is the question.

[bpasero]

@ukoloff that should only depend on the node.js version, not Electron or? Is there a reason N-API would not work in Electron? Is it because of the different V8 version?

[ukoloff]

As far as I know, Electron uses its own N-API, which is incompatible with Node.js' one.

I don't know, if process.version can be used to detect that difference. I suppose it cannot.

May be one could compare process.version against process.versions.v8 and deduce whether Electron is used or not. But I have neither will nor time to support this. There must be npm package for this or some official API or whatever.

[bpasero]

@ukoloff I see. We have microsoft/vscode#62315 to support this but it is not yet in any version of VSCode.

[StephenWeatherford]

(FYI, If you look at the process versions I showed up, the detection of electron didn't change - it returned false before, too - the difference is that nApi started showing up in versions so win-ca stopped using the fallback.)

@ukoloff Is there a way I as a caller could force you to always use the non-nAPI fallback? Thx.

[ukoloff]

(FYI, If you look at the process versions I showed up, the detection of electron didn't change - it returned false before, too - the difference is that nApi started showing up in versions so win-ca stopped using the fallback.)

Oh, that's interesting!

@ukoloff Is there a way I as a caller could force you to always use the non-nAPI fallback? Thx.

So far, there is no such possibility. Adding this configuration parameter is easy but not user friendly IMHO. I'll try to figure another way to handle the problem.

[StephenWeatherford]

@bpasero Do you know when the next vscode release will be? I.e. how long before this becomes an issue in vscode and not just Insiders? thx.

[bpasero]

@StephenWeatherford first week of February.

[ukoloff]

@ukoloff Is there a way I as a caller could force you to always use the non-nAPI fallback? Thx.

@StephenWeatherford Quick-n-dirty fix would be

if (process.platform === 'win32')
  delete process.versions.napi

I'm going to make a bit smarter fix for win-ca VS Code extension before February.

[StephenWeatherford]

@ukoloff Thanks, really appreciate it!

[ukoloff]

win-ca v2.4.0 is published, both npm module and VS Code extension.

It works for me (both in regular VS Code and VS Code Insiders), but more testing is needed...

[StephenWeatherford]

@ukoloff I really appreciate the quick turn-around, sorry for the delay in trying this out. I'm still seeing the problem. Here's what I see:

nApi = !!process.versions.napi; -> true

nApi && (nApi = this === require('../fallback')); -> true

nApi && (nApi = !(this.electron = require('is-electron')())); -> this.electron = false, nApi = true

this.each = require((this.nApi = nApi) ? './each' : './each.fallback'); -> error loading DLL

[StephenWeatherford]

I get the same result if I run the extension in ./vscode and change require('win-ca/fallback') to require('win-ca').

[ukoloff]

@StephenWeatherford The problem is here:

nApi && (nApi = this === require('../fallback')); -> true

For me it is false. Cannot imagine how it could be true.

The following files should be executed in that order:

1. win-ca/fallback/index.js
2. win-ca/lib/index.js

Is it true?

[StephenWeatherford]

I don't understand how this is supposed to work. fallback/index.js just requires "..", which is win-ca's root folder, which requires lib/index.js, which is the original file loaded, no?

[StephenWeatherford]

Your vscode extension uses require('win-ca/fallback') instead of require('win-ca'). Am I supposed to be doing that? I'm currently doing require('win-ca') as before.

[ukoloff]

Your vscode extension uses require('win-ca/fallback') instead of require('win-ca'). Am I supposed to be doing that? I'm currently doing require('win-ca') as before.

Yes, if you call win-ca inside VSCode, you should require('win-ca/fallback'),
since there is no portable way for win-ca to know it runs inside VSCode.

By the way, I don't quite understand why you should require win-ca yourself. Do you develop your own VS Code extension?

The intended usage is just to install win-ca extension, it will call win-ca module which fetches list of root certificates and installs it to https.globalAgent.options.ca (available to all other installed extensions).

Of course, you can call win-ca yourself if you know what are you doing. Any way, you should make it use fallback, as stated before.

[StephenWeatherford]

Thanks, that does fix it, I just thought it was supposed to auto-detect.

The intended usage is just to install win-ca extension, it will call win-ca module which fetches list of root certificates and installs it to https.globalAgent.options.ca (available to all other installed extensions).

Been wanting to talk to you about that. I don't like the idea that installing an extension will affect other extensions' behavior (unless you're doing it on purpose by installing your vscode extension as a user). In fact, I take pains to pull out the values and have them not affect the global state.

Imagine that you're an extension author and that some users claim certificates work and some claim they don't, and what you don't know is that it depends on whether or not they have installed an entirely different extension...?

[StephenWeatherford]

(Yes, I'm an extension author - https://github.com/microsoft/vscode-docker)

[chrmarti]

(I'll eventually look into microsoft/vscode#52880 which will load win-ca for all extensions.)

[StephenWeatherford]

@chrmarti Yes, and looking forward to that!