Move Copilot EA project to reference Features layer instead of EditorFeatures

[genlu]

So both Copilot in VS and VSCode can use it

[genlu]

This PR modifies public API files. Please follow the instructions at https://github.com/dotnet/roslyn/blob/main/docs/contributing/API%20Review%20Process.md for ensuring all public APIs are reviewed before merging.

This PR doesn't change public API, it just modifies an existing EA project w/o any internal API change

[CyrusNajmabadi]

This PR doesn't change public API, it just modifies an existing EA project w/o any internal API change

won't this still break our CP consumer? They will have bound to apis in another dll, which are now no longer there.

[genlu]

This PR doesn't change public API, it just modifies an existing EA project w/o any internal API change

won't this still break our CP consumer? They will have bound to apis in another dll, which are now no longer there.

I don't think so? I simply changed the dependency of the EA from EditorFeatures to Features (and the consumer have no reference to anything in EF), and move the files to a different location in the roslyn repo. I believe there's no consumer observable changes, pls correct me if I was wrong

[CyrusNajmabadi]

@genlu Her'es an example. This type moved from EditorFeatures to Features. So anywhere this type might be references in the Copilot codebase, it will now fail to resolve this type as static compilation means that the type referenced has a strong-name that includes teh full assembly it came from.

[genlu]

I'm not following. The source and project file contains this type is moved from src/EditorFeatures/ExternalAccess/Copilot/ folder to src/Features/ExternalAccess/Copilot/ folder, but there's no change to source file's content nor the Microsoft.CodeAnalysis.ExternalAccess.Copilot project contains it (other than a change of dependency)

[davidwengier]

@genlu this is interesting timing, I was just porting the Razor mapcode endpoint to cohosting, which could be helped by this. Does this mean the conversations DLL itself is dropping some editor dependencies, and could potentially load in the Roslyn OOP process?

[genlu]

this is interesting timing, I was just porting the Razor mapcode endpoint to cohosting, which could be helped by this. Does this mean the conversations DLL itself is dropping some editor dependencies, and could potentially load in the Roslyn OOP process?

Good timing indeed. Yes, I believe the EA assembly can be loaded in roslyn OOP after this change