Consider offering just one "install .NET SDK" command

[richlander]

I see the following commands:

I don't find the distinction between "Install New .NET SDK" and "Install the .NET SDK System-Wide" intuitive. For starters, they are both (by default) going to be new and installed system-wide.

I'd rather:

• A single command with simpler wording, like "Install .NET SDK".
• Prefer the simpler "New .NET SDK" experience
• Include ".NET SDK" for all install and uninstall commands. The current uninstall command doesn't follow that pattern.
• Encourage users to use command-line or other experiences if they want a way to install specific versions.

@JoeRobich @nagilson

[nagilson]

Removing 'New' from the text is the only change that would be in CDK.
The rest would be in the Install Tool.

Would it be better to have the System-Wide command say, 'Install a specific version of the .NET SDK'? Rather than to get rid of it?
We have telemetry on the command palette option we have. It might be worth exploring how often people utilize that to get different versions from what the UI presents.

[richlander]

We could also update the "New SDK" UI to allow specifying a version number.

[nagilson]

I believe @webreidi's focus, and now @claudiaregio's for the UI menu was to target it to new developers to help them get started, so we decided against allowing that in the UI. @baronfel felt similarly IIRC. However, we can revisit that decision. I see the value in consolidating these (at the very least renaming both to clarify), as long as there isn't a loss of functionality.

[richlander]

I'd like to understand how we think of exposing functionality in the command palette vs an MCP. Or if the command palette could expose MCP-oriented Copilot prompts.

Here's the thing I don't like about this architecture:

• Only exists in VS Code
• Only usable via the command palette not GHCP.

I'd much rather see a general-purpose standalone CLI that can be used for lots of scenarios and that works well with GHCP. The command palette would possibly be the last experience I'd suggest we enable, not the first. I realize how we got here and that CP is completely changing the game, which is what is driving my intuition.

[richlander]

Here's today's experience.

I suggest we remove the command palette commands as a way of forcing ourselves to build a great Copilot-first experience. If the command palette experience can drive GHCP chat, that's great.

As a longer-horizon task, we should make the install tool extension depedendent on a general purpose installatoin binary that can be used for other purposes.

The fact that GHCP is suggesting brew and we have these underutilized installation experiences in the command palette strongly suggests that we haven't chosen the right approach.

[timheuer]

@richlander I just want to explain your copilot chat a bit.

First "latest" really is not awesome with models without grounding. It sucks. What you see -- which may not be clear -- is that "VSCode" suddently became your responder. That's a 'chat participant' that got kicked in via some intent detection and now took over trying to resolve (observe 'rerun without' link). I do not believe that chat participant indexes all non-core commands without additional grounding itself (which would be a good thing to suggest on microsoft/vscode repo as an enhancement). It would have saved a few back/forth. Especially if we have some client-specific responders that aren't fully aware of all client-specific (regardless of who owns the commands).

[nagilson]

As a longer-horizon task, we should make the install tool extension depedendent on a general purpose installatoin binary that can be used for other purposes.

That was one goal of the 'dnvm' project 😁 Though they can be solved in or not in parallel.

I'd much rather see a general-purpose standalone CLI that can be used for lots of scenarios and that works well with GHCP.

That is a large undertaking, but I do think it's an interesting / more long-term focused architectural decision. We got here because we wanted logic that worked with VS Code directly and did not require a .NET; as soon as we bundle .NET with the extension, its update schedule is directly tied to .NET's release schedule. Whether that's acceptable or not is another topic.

I like @timheuer's suggestion to fix the broader problem by having the vscode repo be aware of commands that are contributed by other extensions.

I would be interested to see if there's a short-term fix to improve the experience with GHCP, like MCP servers for VS Code. I have not looked into that yet.

[timheuer]

I like @timheuer's suggestion to fix the broader problem by having the vscode repo be aware of commands that are contributed by other extensions.

Not discounting any other feedback @richlander is providing I just wanted to make sure that I capture the feedback about this good idea to the VSCode team: microsoft/vscode#255860

improve the experience with GHCP, like MCP servers for VS Code

We haven't looked into generic ones yet, but for sure our extension could deliver them. Some more lighter-weight ones like .NET/SDK version management might be simple since we have the commands already...and ideally would have been triggered by that chat (but still no guarantees LOL)

[nagilson]

I was able to get our commands to work with the copilot chat agent in Code: dotnet/vscode-dotnet-runtime#2375 though this is very much a proof of concept.

[richlander]

That's an extremely good idea! Yes, MCP-ize extension commands (either actually or conceptually).

[richlander]

First "latest" really is not awesome with models without grounding. It sucks. What you see -- which may not be clear -- is that "VSCode" suddently became your responder.

I'm working on the grounding separately. Agree with your point.