Check DotnetRuntimeExtensionResolver for DOTNET_ROOT

[WardenGnaw]

This PR adds in a check to obtain the DOTNET_ROOT from DotnetRuntimeExtensionResolver. This should be using the same dotnet as the roslyn LSP.

The future work for this would be a global API from the runtime acquisition and centralize how C# Extension would obtain the dotnet cli path and we can remove the getDotNetInfo utils methods.

[gregg-miskelly]

Andrew, do you know how this is supposed to work? Do you know if there is some documentation?

A few specific questions:

1. Do the various extensions acquire a single .NET SDK and runtime?
2. The expectation is that if there isn't a global .NET, the target app will run on the same runtime as the extension?
3. Assuming the answer to Q2 is 'yes', one side effect is that as soon as we move the language server to a new version of .NET, all older projects will be broken (since they will still be targeting .NET 7). Did the designers of this plan consider this?

[WardenGnaw]

Andrew, do you know how this is supposed to work? Do you know if there is some documentation?

A few specific questions:

1. Do the various extensions acquire a single .NET SDK and runtime?
2. The expectation is that if there isn't a global .NET, the target app will run on the same runtime as the extension?
3. Assuming the answer to Q2 is 'yes', one side effect is that as soon as we move the language server to a new version of .NET, all older projects will be broken (since they will still be targeting .NET 7). Did the designers of this plan consider this?

1. For Runtime, Yes. Theres a .NET Runtime install tool that the extension use. For SDK, I think its in progress @nagilson should have more information on this.
2. I don't think so, I think users should have their own SDK / runtime? If its not gobally installed, should we reccomend users to just set omnisharpOptions.dotNetCliPaths?
3. Skipping because I think its a no.

[gregg-miskelly]

Broadly speaking, I think there are two ways that we could solve the problem of acquiring a .NET SDK and/or Runtime for the app to use, and I don't know what one was selected --

Option 1: VS Code extension(s) install the .NET SDK and/or Runtime(s) that we think users are most likely to target

This is obviously what VS does, though VS installs the SDK globally. I don't entirely understand the VS behavior, and how similar it is to the VS Code behavior -- if VS switches from installing say, .NET 6 to .NET 7, does it remove .NET 6? Will this work with the way VS Code is installing them?

In an ideal world, under this option, I think the debugger should really be doing nothing. Otherwise, one can F5/Ctrl-F5 from VS code, but if one just opens a terminal, the app will no longer run. At the very least, I think we need documentation somewhere for what a user should do.

Option 2: User should be guided to install the .NET Runtime and/or SDK the "normal way"

In this option, we add some basic detection for understanding if there is a .NET runtime installed, and if that fails, we point them at instructions on how to install the runtime or SDK themselves. The nice thing about this is that the user is in charge of picking the right SDK/runtime, as there are many options and the one we pick may not be right for the user.

[dibarbet]

Broadly speaking, I think there are two ways that we could solve the problem of acquiring a .NET SDK and/or Runtime for the app to use, and I don't know what one was selected --

I can explain the current expectations from the language server / project side. Note that there are two distinct parts -

1. Acquiring the dotnet runtime used to start the server process - this is the code in DotnetRuntimeExtensionResolver
   1. We first check if there is an installed runtime with high enough version (.NET 7 or above) and the right architecture on the PATH, if so, we use the runtime from the dotnet on path to launch the server.
   2. If there is no matching runtime, we download a local runtime using the .net acquisition extension. This is only the runtime, and has no ties to any globally installed SDKs or runtimes.
2. Acquiring the dotnet SDK needed to load the project
   1. Currently we rely on the dotnet SDK being on the path. We do not do any acquisition of SDKs. We use MSBuildLocator on the server side to find it.

However this may be changing once the .net runtime acquisition extension supports acquiring SDKs. I'm not 100% sure what the plans are there (I haven't seen the latest details).

[nagilson]

We are releasing the API to acquire a Global .NET SDK using the '.NET Runtime Install Tool', which will become the '.NET Install Tool' by the end of next week. C#/CDK will be able to call into that API to have us acquire a .NET SDK (versioned like so: 'major' like '6', major.minor like '3.1', feature band, such as '7.0.3xx' or specified version, like '7.0.103'.

Work is starting on CDK side to consume this new API and add a UI layer.

[WardenGnaw]

I think it would be best to hold off on these changes and utilize omnisharpOptions.dotNetCliPath for folks who do not install dotnet globally.