Consider using vscode-dotnet-runtime about msbuild-project-tools-vscode HOT 11 CLOSED

Reopening since this work was reverted as a hotfix. We should investigate whether it is possible to isolate extension's runtime while also keeping the ability to reliably check information about .NET on the host and either bring this change back or provide a proof that this is not possible

from msbuild-project-tools-vscode.

Ok, I've done a research which seems to have positive results. My idea is to use 2 well-known environment variables: DOTNET_HOST_PATH and DOTNET_ROOT. The good thing is that these variables are also respected by other components of .NET, most importantly for us is that by setting them we can override default location where MSBuildLocator searches for MSBuild. This is the opposite of what I've suggested doing in tintoy/msbuild-project-tools-server#72, but in this case I think it is a good solution, since all shenanigans with .NET's path are our internal implementation detail and are not in user-controlled settings space. Moreover, this will give potential language server users (tintoy/msbuild-project-tools-server#33) more flexibility since they will be able to choose whether they want to use user's .NET or an isolated runtime with DOTNET_HOST_PATH environment variable pointing to user's distribution of .NET. The server side PR is tintoy/msbuild-project-tools-server#86. Client-side PR is expected to come next

from msbuild-project-tools-vscode.

Check out the 2 links I posted in that other issue - it’s possible to configure the vscode-dotnet extension to use the global .net instance for a given extension:

#137 (comment)

from msbuild-project-tools-vscode.

TBH this is the opposite of what I want to achieve with this. My idea originally was to completely isolate .NET runtime, which runs language server, so for the end user there is no impact on his global .NET environment. + it seems that the thing you've suggested works on "user level", meaning that as a user I can configure vscode dotnet runtime extension to provide existing .NET installation for a specific extension id I choose, but it isn't clear whether it is possible to do this through code inside another extension.
I never expected that implementing this will break detection of host .NET though

from msbuild-project-tools-vscode.

Oh, I see. Yeah, in that case I am not entirely sure whether this idea is practical; the official .NET SDK discovery logic (and most of its underlying machinery and tooling) uses built-in knowledge from the current runtime to discover SDKs (especially each SDK’s associated MSBuild instance).

I suspect we would be swimming against the tide to try using our own isolated runtime but their global SDK (which we would need to do in order to load their project with correct behaviour and metadata).

I can see why you’d want to do that for a “normal”extension but for one that has to utilise the correct SDK tooling and runtime metadata to mimic what they would see if running stuff from the command line it would be very hard to be sure you’d got it right (and wouldn’t break if they changed undocumented behaviour).

from msbuild-project-tools-vscode.

(most of the complexity comes from having to load the correct version of the MSBuild engine and any custom SDKs or tasks they have configured)

from msbuild-project-tools-vscode.

Nice idea! Thanks, will have a look at this tomorrow morning 🙂

from msbuild-project-tools-vscode.

I think if we are going to go down this route then we will, at minimum, need to have a working CI pipeline which runs integration-type tests with various SDK / runtime combinations (in containers, for example).

Maybe using TestContainers?

from msbuild-project-tools-vscode.

I'm happy to look into the testing side if that would be helpful.

from msbuild-project-tools-vscode.

BTW, I can't remember if I showed you before, but our CI runs here:

https://dev.azure.com/tintoy-dev/msbuild-project-tools-vscode/_build?definitionId=2

from msbuild-project-tools-vscode.

Ok CI is now running for both language server and extension package:

https://dev.azure.com/tintoy-dev/msbuild-project-tools-vscode/_build/results?buildId=136&view=artifacts&pathAsName=false&type=publishedArtifacts

Later, I'd like to improve extension-package CI to get the language-server artifact from the appropriate GitHub release but this will do for now.

from msbuild-project-tools-vscode.