ExternalAccess.Razor breaks Roslyn layering rules

[tmat]

Microsoft.CodeAnalysis.Remote.ServiceHub should not depend on EditorFeatures layer, but it does via EA.Razor:

[davidwengier]

We need to split EA.Razor up into two different assemblies, one for EditorFeatures (and above) and one for everything else. This will be needed for cohosting in VS Code anyway.

FYI @phil-allen-msft

[CyrusNajmabadi]

@davidwengier @phil-allen-msft plz. asap :)

[davidwengier]

@ryzngard is working on this as we speak :)

[ryzngard]

#77715 is the start. Once that's in I think we can do more cleanup and make sure Microsoft.CodeAnalysis.Remote.ServiceHub references the Features EA. Is that only loaded in OOP?

[tmat]

Yes, Remote.ServiceHub is OOP only

[ryzngard]

Alright, I did an initial pass to see what is needed from EditorFeatures

1. RazorDynamicRegistrationServiceFactory uses IUIContextActivationService
2. RazorCSharpInterceptionMiddleLayerWrapper uses AbstractLanguageClientMiddleLayer

That doesn't seem too bad. I think the easiest path forward would be to move everything to shared that isn't editorfeatures, make Roslyn OOP uses the new Microsoft.CodeAnalysis.ExternalAccess.Razor.Features dll, and move razor over. That should also avoid needing to dual insert. Will have to test if this ends up being another binary load.

@davidwengier does that make sense for the direction of cohosting and what requires the editor?

[davidwengier]

Yep, makes sense, those two things are specifically VS concepts. Eventually we might want VS Code equivalents though. I thought there was also some stuff we used in tests that created a Roslyn language server, but maybe that's already abstracted on the Roslyn side.

[CyrusNajmabadi]

Makes sense to me as well. Do you think this can be done soon? Thanks!