Skip to content

Conversation

@chuckries
Copy link
Contributor

This adds a debug proxy that acts as the debug adapter program before the
coreclr-debug are fully downloaded. If the user tries to start debugging
before download is finished, the proxy displays a sane error message. Once
the download is complete, we rewrite the manifest to no longer call the
proxy.

During the VS Code session that downloads the components, the manifest is
rewritten but not reloaded. In this case the proxy spawns the real
debugger as a child process and proxies its stdin/stdout. Once vs code is
restarted the new manifest is loaded and the proxy is no longer called.

Also adds an empty command that can be run to force activation of the C#
extension, which will kick off debugger acquisition.

@chuckries
Copy link
Contributor Author

});

return promise;
/*---------------------------------------------------------------------------------------------
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure why this file is showing as one big delete and add. possibly because of the rename? I thought github could handle this better. Maybe I'm missing something? Doesn't seem to be a line ending thing.

@caslan
Copy link
Contributor

caslan commented Mar 30, 2016

LGTM

let _installBeginFilePath: string = '';
let _installCompleteFilePath: string = '';

export function setExtensionDir(extensionDir: string) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm... a bunch of state and function that operate on it. Maybe just make a class? :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably a good call. still not super used to javascript/typescript.

@chuckries
Copy link
Contributor Author

@DustinCampbell I abstracted util into a class. Is this more what you had in mind?

@chuckries
Copy link
Contributor Author

#136

_channel.show(vscode.ViewColumn.Three);
}
});
statusBarMessage.dispose();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want this in the success case too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you asking if we want to dispose the first message before setting the new success message? Probably.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way it's written, the success message will never be disposed. The only thing we could do is set it to be disposed after a certain timeout.

@gregg-miskelly
Copy link
Contributor

Otherwise looks good to me.

This adds a debug proxy that acts as the debug adapter program before the
coreclr-debug are fully downloaded. If the user tries to start debugging
before download is finished, the proxy displays a sane error message. Once
the download is complete, we rewrite the manifest to no longer call the
proxy.

During the VS Code session that downloads the components, the manifest is
rewritten but not reloaded. In this case the proxy spawns the real
debugger as a child process and proxies its stdin/stdout. Once vs code is
restarted the new manifest is loaded and the proxy is no longer called.

Also adds an empty command that can be run to force activation of the C#
extension, which will kick off debugger acquisition.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants