Remove VSWin dependencies from RazorInProcLanguageClient

[KirillOsenkov]

RazorInProcLanguageClient currently imports VisualStudioWorkspace:

https://sourceroslyn.io/#Microsoft.VisualStudio.LanguageServices/Implementation/LanguageClient/RazorInProcLanguageClient.cs,99e841363bce23be

We can't use this on Mac. We should investigate moving RazorInProcLanguageClient into the EditorFeatures layer or removing the dependency on VisualStudioWorkspace.

Additionally the work item https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1351469 is tracking a MEF export for IBrokeredServiceContainer, we should switch to obtaining it from MEF so we can use it from Mac.

In general, we can't use anything from the Microsoft.VisualStudio.LanguageServices layer and we can't use any VS APIs that start with "IVs". But we can and should use MEF.

[KirillOsenkov]

To remove dependencies on VisualStudioWorkspace, if all we need is HostServices, then HostServices is initialized here:

roslyn/src/VisualStudio/Core/Def/Implementation/ProjectSystem/VisualStudioWorkspaceImpl.cs

Line 118 in 3d8acbd

: base(VisualStudioMefHostServices.Create(exportProvider))

Perhaps we should extract it into a separate reusable thing that can be imported from both IDEs to initialize their respective workspaces.

Also I'm wondering whether we should be reusing HostServices across the RoslynVisualStudioWorkspace, MiscellaneousFilesWorkspace, InteractiveWorkspace and all our other workspaces.

[tmat]

Also I'm wondering whether we should be reusing HostServices across the RoslynVisualStudioWorkspace, MiscellaneousFilesWorkspace, InteractiveWorkspace and all our other workspaces.

No, each workspace has a separate customized MEF composition.

[tmat]

Perhaps we should extract it into a separate reusable thing that can be imported from both IDEs to initialize their respective workspaces.

Yes, I'll be looking into that.

[dibarbet]

Started taking a look at this, encountered a few issues so far

1. It isn't as simple as moving the LSP client definitions down to EditorFeatures as currently MS.CA.LanguageServer.Protocol also depends on EditorFeatures. This would cause a circular dependency. My plan of attack is to move the feature handlers from MS.CA.LanguageServer.Protocol that use EditorFeatures into EditorFeatures alongside the ILanguageClient definitions.
2. Microsoft.VisualStudio.LanguageServer.Client targets net472 only while EditorFeatures targets netcoreapp3.1 / netstandard. I believe that Microsoft.VisualStudio.LanguageServer.Client needs to be updated to multi-target. Otherwise I get this error during restore.

C:\Users\dabarbet\source\repos\roslyn\src\EditorFeatures\Core\Microsoft.CodeAnalysis.EditorFeatures.csproj : warning NU
1701: Package 'Microsoft.VisualStudio.LanguageServer.Client 17.0.3094-g82ddffa096' was restored using '.NETFramework,Ve
rsion=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Ver
sion=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETCoreApp,Version=v3.1'. This packa
ge may not be fully compatible with your project. [C:\Users\dabarbet\source\repos\roslyn\Roslyn.sln]

[dibarbet]

blocked on https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1369985

[KirillOsenkov]

I think the easiest for now would be to just ignore the warning for this package using the NoWarn metadata on the PackageReference:

https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#nuget-warnings-and-errors

<PackageReference Include="Microsoft.VisualStudio.LanguageServer.Client" Version="17.0.3094-g82ddffa096" NoWarn="NU1701" />

We know it's benign since we have BinaryCompatChecker to actually prove the compatibility.

I'd like this work to progress without waiting on the LSPClient as we can do further spiking and prototyping to continue uncovering other blockers early.

[dibarbet]

Ah, I didn't realize that was possible. I will take a look at implementing that then!