-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configured debug type 'extensionHost' is not supported. #13394
Comments
This is as designed, when you run vscode out of source the node debug is not packaged as an extension - it only gets packaged once you build the full vscode. |
oh thanks!! |
@isidorn
I copied these folders in to my |
just to add windows 10 64 bit
npm: 4.0.2,
http_parser: '2.7.0',
node: '6.9.1',
v8: '5.1.281.84',
uv: '1.9.1',
zlib: '1.2.8',
ares: '1.10.1-DEV',
icu: '57.1',
modules: '48',
openssl: '1.0.2j' |
@pflannery in the 'launch.json' under |
So why can't there be some sort of better install script that actually installs node debug for the dev version too? Also, if by stable version you happen to mean the one on the website, that one isn't free software (see #17996 ) which means being required to copy from it would imply the "Code - OSS Dev" free version actually doesn't properly work without copying from a proprietary software which is somewhat suboptimal. |
@Jonast just checkout vscode-node-debug, do an |
https://github.com/Microsoft/vscode-go/wiki/sideload Is this the sideload procedure I need to use? Ok, let me try whether that works.. As a note: from #12570 it sounds like this is no longer supposed to be necessary, or did I misunderstand that ticket? It would be neat if at some point an install script would automatically address this. |
Ok that worked, and after editing the launch args as in #13394 (comment) it launches VSCode for debugging - however, apparently not with the extension loaded which I want to debug 😕 (it's not listed in extensions in the inner instance - shouldn't it be?) Also this whole process seems a bit complicated.. e.g. why do I need to edit the launch args, and does everyone else who wants to test it need to do it too? Should I remove the |
Sideloading an extension is trivial: just go to the extension viewlet and select "Install from VSIX.." from the overflow menu. (Are you sure that you that you need "Code - OSS Dev" to debug your extension? Debugging extension is directly supported from the regular stable or Insider builds of VS Code; the 'complicated setup' you mention above is only necessary if you want to debug the VS Code core itself). |
I run Code - OSS Dev because I'd rather have a free piece of software I can freely tinker with than this abomination of a license: https://code.visualstudio.com/License/ (pretty standard for proprietary software I'm aware, but that doesn't make it much better) Why is debugging an extension not directly support from the free version of VS Code? |
Because in the 'free' version of VS Code you are 'free' to decide what extensions you want to use. We do not want to force anybody to use the node debug extension (and we believe that the "Install from VSIX..." action makes it painless to include any extension you want to use). |
That does actually kind of make sense. Would I have needed to manually locate, download & build node-debug though? It might be good to at least make that process a little easier since I imagine it's a common extension. (for example, by adding a list of commonly downloaded extensions right into VS Code where you can just click the name and it gets downloaded & installed) Unless of course that's already inside and I was just needlessly taking the route with more effort 😄 |
We are assuming that if you want to build 'Code - OSS Dev' yourself, then you probably want to build 'node-debug' yourself too. |
This is built on top of microsoft/vscode#30337. Note that I had to follow the instructions at microsoft/vscode#13394 to be able to run this extension from the OSS version of VS Code. Unfortunately, that means I made a personal modification to `.vscode/launch.json`, so hopefully I can find some way to avoid that. This is pretty exciting in that I had to make minimal changes to my existing extension to get this to work! The only issue that I'm running into right now is that `resolveContents()` appears to be called more often than I expect. It is called twice when I open the file for the first time. I also opened a remote `.md` file using this mechanism. I was able to use `Markdown: Open Preview` on this remote file, but when I closed the preview, `resolveContents()` was called again and I'm not sure why. Because loading remote file contents could be expensive, we would ideally fix things so this is called sparingly, or we'll have to maintain a local cache to avoid extra roundtrips. Note that I had to launch the OSS version (built from source) using `./scripts/code.sh --remote nuclide`. There is a TODO in the PR to eliminate the need to pass this flag.
As title described
The text was updated successfully, but these errors were encountered: