Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce likelihood of needing a dual insertion in VS Code #77715

Merged
merged 6 commits into from
Mar 25, 2025

Conversation

ryzngard
Copy link
Contributor

The goal of this PR is to not add new functional changes but instead prepare razor to be added through --extension in VS Code. Razor will be allowed to export endpoints and LSP services which allows for better reuse and sharing of code. It also means that Razor will no longer have an EA for Roslyn to consume and dual insertions won't be required for most VS Code changes.

Razor side: dotnet/razor#11510

/Shared : will eventually be the area for all source items shared between
the current EA and the new EA.Razor.Features
/Features : will have an EA that is restricted to depending only on the
features layer. This will help provide a way to ship a more sane EA
structure for VS Code as well as reduce the likelyhood and work required
for a dual insertion
/EditorFeatures : contains the current EA. The project name is kept the
same for now but the folder is moved. This denotes that the binary does
depend on the EditorFeatures layer in Roslyn
@ryzngard ryzngard requested review from a team as code owners March 20, 2025 21:28
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Mar 20, 2025
@dotnet-policy-service dotnet-policy-service bot added VSCode Needs API Review Needs to be reviewed by the API review council labels Mar 20, 2025
namespace Microsoft.CodeAnalysis.ExternalAccess.Razor.Features;

[MetadataAttribute]
internal class RazorEndpointAttribute : LanguageServerEndpointAttribute
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could RazorMethodAttribute move to the shared layer?

UPDATE: Oh, I guess that would be a break because the namespace is wrong. I guess we'll just have to move over to use this in cohosting, so we can eventually remove RazorMethodAttribute, and move this to the shared project?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'll eventually want cohosting on the Features layer only right? If so I'll just leave this as is for now

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, not too sure. Fine to leave it for now, even if we move it, we don't need to change the namespace so it won't be an issue.

@ryzngard ryzngard merged commit f5d37bf into dotnet:main Mar 25, 2025
28 checks passed
@ryzngard ryzngard deleted the update_razor_ea branch March 25, 2025 21:38
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Mar 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE Needs API Review Needs to be reviewed by the API review council untriaged Issues and PRs which have not yet been triaged by a lead VSCode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants