Skip to content

Conversation

@captainsafia
Copy link
Member

Summary of the changes

  • Adds devcontainer for aspnetcore-tooling repo under .devcontainer/
  • Updates tasks.json to support launching workspace inside dev container (preface all paths with ${workspaceFolder}
  • Add companion extension under Microsoft.AspNetCore.Razor.VSCode.BlazorWasmCompanionExtension
    • Adds ms-blazorwasm-companion.launchDebugProxy and ms-blazorwasm-companion.killDebugProxy commands on the UI extension that can be invoked from the workspace
    • Adds LocalDebugProxyManager for downloading and getting path of debugging proxy package locally
  • Updates BlazorWasmDebugConfig type to use debugging proxy launched via the companion extension

Review Guide

To review this PR, I recommend reading through the changes in src/Razor/src/Microsoft.AspNetCore.Razor.VSCode/src/BlazorDebug/BlazorDebugConfigurationProvider.ts then tracing that to the new APIs introduced in the companion extension at src/Razor/src/Microsoft.AspNetCore.Razor.VSCode.BlazorWasmCompanionExtension/src/extension.ts.

Fixes: dotnet/aspnetcore#22587

Copy link
Contributor

@ryanbrandenburg ryanbrandenburg left a comment

Choose a reason for hiding this comment

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

Awesome, just some nitpicks and one questions mostly for my own education.

@@ -0,0 +1,23 @@
# Microsoft.AspNetCore.Razor.VSCode.BlazorWasmCompanionExtension

This directory contains the code for the Blazor WASM companion extension. This extension is designed to support remote debugging scenarios for Blazor WebAssembly.
Copy link
Contributor

Choose a reason for hiding this comment

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

Love the informative README.

Copy link
Contributor

@TanayParikh TanayParikh left a comment

Choose a reason for hiding this comment

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

Nice! Just some minor comments;

@captainsafia
Copy link
Member Author

🆙 📅 Made some major changes to this after a convo with @NTaylorMullen:

  • Instead of acquiring the debug proxy from NuGet, the extension comes bundled with it. Pros: we don't need to worry about acquisition logic in the extension. Cons: users have less flexibility to change the version of the debug proxy they are on and we will need to republish the extension if we want to update to use a newer version that has bugs/features.
  • I used the vscode-dotnet-runtime extension to acquire a dotnet install when running in remote scenarios.

@TanayParikh
Copy link
Contributor

Not sure if I missed the context on this, but what's the empty src/Razor/src/Microsoft.AspNetCore.Razor.VSCode.BlazorWasmCompanionExtension/BlazorDebugProxy/_._ file for?

@captainsafia
Copy link
Member Author

Not sure if I missed the context on this, but what's the empty src/Razor/src/Microsoft.AspNetCore.Razor.VSCode.BlazorWasmCompanionExtension/BlazorDebugProxy/. file for?

Git doesn't commit empty folders sometimes and I wanted this to be included so that devs know it needs to be loaded with content. I decided to change this and added a README that outlines what content it should contain (in addition to the docs that already exist in the extension's README).

Copy link

@NTaylorMullen NTaylorMullen left a comment

Choose a reason for hiding this comment

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

Just to clarify, this PR purposefully doesn't have the VSIX creation / publish lifecycle bits included right?

@captainsafia
Copy link
Member Author

Just to clarify, this PR purposefully doesn't have the VSIX creation / publish lifecycle bits included right?

Correct. This PR is here to get consensus on the implementation of the PR. My plan is to open a separate PR for publishing-related things.

Copy link

@NTaylorMullen NTaylorMullen left a comment

Choose a reason for hiding this comment

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

Loooks good!

To make sure I have the next steps in my head correctly could you verify this list is correct:

  • Meet with O# about adding the dependency & it's implications
  • Find the msdotnettools subscription owners and learn what it takes to publish an extension under that publisher
  • Implement the publishing logic to create the VSCode extension assets

@captainsafia
Copy link
Member Author

Meet with O# about adding the dependency & it's implications

I've spoken with @JoeRobich a handful of times about this but we can loop in other folks from the extension team for awareness now that the concrete implementation is done.

Find the msdotnettools subscription owners and learn what it takes to publish an extension under that publisher

I already did this. Chatted with Joey and Sarah a while back and they've created a doc about this.

Implement the publishing logic to create the VSCode extension assets

Can you clarify what you mean by this? For publishing, we can use the vsce to package and publish everything.

@captainsafia captainsafia merged commit f21b320 into master Feb 1, 2021
@captainsafia captainsafia deleted the safia/remote-dbg branch February 1, 2021 02:20
@NTaylorMullen
Copy link

Can you clarify what you mean by this? For publishing, we can use the vsce to package and publish everything.

This is just referring to adding the MSBuild logic to aspnetcore-tooling to actually generate a VSIX that we can then publish to the marketplace.

I've spoken with @JoeRobich a handful of times about this but we can loop in other folks from the extension team for awareness now that the concrete implementation is done.

Have you spoken to the management on that side to get buy off? Asking because technically it influences the install experience of O# so we'll need a concrete agreement of what's going to happen.

I already did this. Chatted with Joey and Sarah a while back and they've created a doc about this.

O could you link? I imagine we'd need to go through some sort of managerial hurdles to get approved to publish another extension under that publisher.

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.

Add support for launching DebugProxy from blazorwasm debug type in VS Code

6 participants