vscode-csharp: existingPath Setting is not always respected on C#, CDK

Explanation

We sometimes get user reports that the ‘existingPath’ setting for the .NET Runtime extension does not work, even though it does seem to work on our end, and we have never gotten any further information about how it does not work. Specifically, this option:

  "dotnetAcquisitionExtension.existingDotnetPath": [
        {
            "extensionId": "ms-dotnettools.csharp",
            "path": "C:\\Program Files\\dotnet\\dotnet.exe"
        }
    ]

There is confusion there because it needs to be set for csharp as well as c# devkit. But there is another issue which is present in both extensions that I realized is very confusing to users. That is because the setting is ignored if there’s a .NET on the PATH.

https://github.com/dotnet/vscode-csharp/blob/efd9e7f332d73063a34fbb72cbca48aba6ee3e4b/src/lsptoolshost/dotnetRuntimeExtensionResolver.ts#L59

Taking a look at the code, we can see for both C# and C# DevKit that the dotnet on the PATH is used over this setting. I think its a good idea to use the .NET on the PATH if its available, but if someone specifically gave us a different dotnet path and we still used this one, it’s a bit confusing. I realized this because of a customer who was confused why the setting on the PATH was not being used and thought it didn’t work. It was because of this.

Admittedly, people may not understand that they would need to use a different host, which would be what actually picks the .NET runtime and SDK to use. But, its still a UX improvement in my eyes.

Proposal

We should write a command API for DevKit and C# to call that tells CDK and C# what the existingPath setting is on our extension for them. If its set, c# and CDK should use that before it uses the .NET on the PATH, to eliminate this confusion.

Let me know your thoughts, if we agree then I will go do that work item from the .NET Install Tool end.

cc @dibarbet @arkalyanms @AArnott @webreidi @baronfel @leslierichardson95

About this issue

Original URL
State: open
Created 8 months ago
Comments: 15 (15 by maintainers)

Most upvoted comments

@nagilson can you send the spec to Andrew and me as well?

gregg-miskelly on Nov 2, 2023

I meant I’m less clear on the design on the devkit side (how and where devkit uses that API). Do they download a local runtime still, then download an SDK corresponding to the project? Does it automatically happen, or requires a prompt? Or does devkit download a .net7 SDK always instead of a runtime? Does C# still download a runtime only? What about when devkit is not installed? Think we need to answer those questions before we can talk about specific settings.

DevKit’s current plan is to still use the local runtime. The SDK that we acquire is part of a ‘getting started guide’ and mostly intended to simplify the getting started experience so users don’t need to get one themselves. It is a click-through UI walkthrough. @leslierichardson95 and @mavasani are working on the UI for it. I will try to dig that up spec and send it to you offline. C# is still runtime only to my knowledge but I may be wrong on that fact.

nagilson on Nov 2, 2023

It is 1 and 2. And perhaps 3, unless DevKit sets a custom DOTNET_ROOT per project

I don’t believe it is 2). Build commands in devkit execute via the dotnet CLI, which has no idea that this path exists. And when we’re loading projects in the C# extension we load them in a separate process using the dotnet on path with rollforward. As of today - we only use this path as the server runtime.

I’m not sure how this will change with SDK acquisition - I haven’t seen a concrete plan for the UX of SDK acquisition yet.

I have two concerns with trying to use the same setting for 1, 2 and 3, though maybe there are all things we can do about these concerns –

I also agree with this. Any VSCode setting we use for 2 will be incomplete. The dotnet CLI (which we use across the extensions) will not know about this setting. I don’t think we should use a vscode setting at all for 2 (not as sure about 3).

dibarbet on Nov 2, 2023

I have two concerns with trying to use the same setting for 1, 2 and 3, though maybe there are all things we can do about these concerns –

Is the reason why one wants a custom runtime for your own project the same reason why you would want a custom runtime to run VS Code extensions processes on? – The reason that I know of for 2 and 3 is that you are targeting some sort of special runtime and you don’t want to globally install it. For example, targeting a pre-release version of .NET for some new repo. I would imagine in this scenario you would still want to use the ‘normal’ runtime install for running extensions (1), unless maybe I am missing something.
Support for different processor architectures – One scenario for debugging (3 from my above list) is that you want the target app to target a different processor architecture, ex: target maos-x64 on a macos-arm64 mac. Any extension process that includes architecture-specific code should be following the processor architecture of VS Code, which hopefully follows the native processor architecture of their computer. One possible remedy here would be to ignore the setting when the architecture is wrong.

gregg-miskelly on Nov 2, 2023

+ @gregg-miskelly

There is another setting that CDK has if I recall like ‘cliSDKPath’

Its in the C# Extension, and its an older omnisharp setting. Its primary used for finding dotnet for executable launches. Related: https://github.com/dotnet/vscode-csharp/blob/8c42eb1853059ae1114c02a924035ccbe1e91f0b/src/coreclrDebug/activate.ts#L295

WardenGnaw on Nov 1, 2023