Ship Roslyn devkit assembly as a downloadable component

[dibarbet]

Today we ship a dll as an npm package inside devkit, but load that dll inside the C# extension's language server. This is problematic due to the way vscode extensions work and are versioned. Because vscode has no way to ensure that devkit loads a particular version of the C# extension, it means that the version of Roslyn that the devkit dll was built with may be entirely different (and incompatible) with the version of the Roslyn language server in the C# extension.

So if the devkit dll uses Roslyn types, we could end up with runtime exceptions if the types are mismatched. This essentially forces us to restrict usage of Roslyn types in that assembly, see https://github.com/dotnet/roslyn/blob/main/src/VisualStudio/DevKit/Impl/Microsoft.VisualStudio.LanguageServices.DevKit.csproj#L34

An alternative path we should consider taking is instead downloading the devkit dll at runtime (if devkit is installed). This would allow us to download a version of the dll that matches the version of the Roslyn language server and so could use Roslyn types at will.

To do this we need to:

1. Find an appropriate to store the devkit dll that we could download from. This storage needs to support a large volume of downloads as anyone using devkit would have to download this item. We could consider re-using the same azure blob storage that we use to download O# today as it is known to support the vscode volume.
2. Automatically upload the builds we insert into vscode to the storage. We likely don't want to upload every Roslyn signed build, only the builds we actually consume from vscode. This could live in a insertion pipeline to vscode (does not exist yet) or something else.
3. Add support in vscode for downloading the assembly when devkit is installed. If we're using the same blob storage as O# this should be relatively straightforward - we already have code to download it in vscode.

cc @tmat @ToddGrun

[dibarbet]

This came up in a conversation with Todd as he is looking to add the aggregated telemetry support to vscode. Unfortunately the implementation we would need to ship in devkit has fairly tight coupling between workspaces dependencies and VS telemetry. Ideally we could avoid a large refactor by allowing the devkit assembly to depend on other parts of Roslyn

[dibarbet]

We've decided to go a different approach here. The size of the additional dependencies is quite small (< 10 MB), so the plan is to ship the additional dependencies inside the C# extension (but separate from the Language server itself).