Out-of-process host for MSBuild

[tintoy]

At present, MSBuild has to be loaded into the same process as the language server, which can be problematic when the required version of MSBuild does not target the same SDK / runtime as the language server.

High-level design:

[VSCode Extension] ==LSP==> [Language Server] ==MIP==> [MSBuild Server]

• LSP = Language Server Protocol
• MIP = MSBuild Inspector Protocol)
• MSBuild Server = process with some sort of API endpoint, hosting an MSBuild ProjectCollection

LSP is basically JSON-RPC, but has requirements which have resulted in it being designed that way.
For MIP, we can probably get away with GRPC or similar.

Tricky bits:

• Selecting correct SDK and runtime for MSBuild Server
• Launching MSBuild Server so that it uses the correct SDK and runtime
• Managing project state, without making the API too chatty

[tintoy]

This may be a viable strategy for launching the project-host process with a specific version of the .NET runtime:

https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet

(see documentation for the --fx-version command-line argument)

[tintoy]

Will try running some experiments over the holiday break and see how far I can get with this.

[tintoy]

Important to note - the host is primarily about choosing a specific version of MSBuild; the runtime version to be used is only really in service of this.

Simple rules for runtime version selection:

• If MSBuild / SDK require newer version of runtime than project host was built with, then use the newer runtime.
• If MSBuild / SDK require same/older version of runtime than project host was built with, then use the runtime that the project host was built with.

In other words, project host’s “native” runtime version is the minimum version to use, but MSBuild / SDK version is the maximum version to use.

[tintoy]

Useful info about inter-process gRPC using ASP.NET Core over named pipes / unix domain sockets:

https://learn.microsoft.com/en-us/aspnet/core/grpc/interprocess?view=aspnetcore-8.0