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

Boot Razor's language server on LSP client start #17789

Closed
NTaylorMullen opened this issue Dec 11, 2019 · 0 comments
Closed

Boot Razor's language server on LSP client start #17789

NTaylorMullen opened this issue Dec 11, 2019 · 0 comments
Assignees
Labels
area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates Done This issue has been fixed enhancement This issue represents an ask for new feature or an enhancement to an existing one

Comments

@NTaylorMullen
Copy link
Contributor

When VS initializes Razor's LSP client we should actually go through the process of booting the server. This does not include the shipping mechanism of the language server.

@NTaylorMullen NTaylorMullen added enhancement This issue represents an ask for new feature or an enhancement to an existing one cost: S area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates labels Dec 11, 2019
@NTaylorMullen NTaylorMullen added this to the Razor vNext - Alpha 4 milestone Dec 11, 2019
@NTaylorMullen NTaylorMullen self-assigned this Dec 11, 2019
NTaylorMullen added a commit to dotnet/razor that referenced this issue Jan 13, 2020
- Included the LanguageServer core dlls as part of the VSIX install. To do this I had to expose the language server's output path via a target and then dynamically include its outputs in the VSIX output.
- Given how VSIX's are built I could not privately reference our language server to ensure that it's built when the VSIX is built. To work around this limitation I added a `_BuildLanguageServer` target that calls MSBuild directly on the language server as part of build.
- For now I'm dynamically booting the currently built language server that's deployed with the extension. I haven't given a lot of thought to what flavor of OS (x64 vs. x86) the server can run on; or if we need to ensure dotnet.exe is available.

dotnet/aspnetcore#17789
NTaylorMullen added a commit to dotnet/razor that referenced this issue Jan 13, 2020
- Included the LanguageServer core dlls as part of the VSIX install. To do this I had to expose the language server's output path via a target and then dynamically include its outputs in the VSIX output.
- Given how VSIX's are built I could not privately reference our language server to ensure that it's built when the VSIX is built. To work around this limitation I added a `_BuildLanguageServer` target that calls MSBuild directly on the language server as part of build.
- For now I'm dynamically booting the currently built language server that's deployed with the extension. I haven't given a lot of thought to what flavor of OS (x64 vs. x86) the server can run on; or if we need to ensure dotnet.exe is available.
- Found that the VS LSP client and the O# language server library that we use don't inter-operate as we'd expect. The server ends up telling the client that it doesn't care about text document change events (we do). I've created a separate PR in O# to fix this: OmniSharp/csharp-language-server-protocol#199

dotnet/aspnetcore#17789
NTaylorMullen added a commit to dotnet/razor that referenced this issue Jan 14, 2020
- Included the LanguageServer core dlls as part of the VSIX install. To do this I had to expose the language server's output path via a target and then dynamically include its outputs in the VSIX output.
- Given how VSIX's are built I could not privately reference our language server to ensure that it's built when the VSIX is built. To work around this limitation I added a `_BuildLanguageServer` target that calls MSBuild directly on the language server as part of build.
- For now I'm dynamically booting the currently built language server that's deployed with the extension. I haven't given a lot of thought to what flavor of OS (x64 vs. x86) the server can run on; or if we need to ensure dotnet.exe is available.
- Found that the VS LSP client and the O# language server library that we use don't inter-operate as we'd expect. The server ends up telling the client that it doesn't care about text document change events (we do). I've created a separate PR in O# to fix this: OmniSharp/csharp-language-server-protocol#199
- Add OmniSharp 3rd party library to signing information for VSIX insertions.


dotnet/aspnetcore#17789
NTaylorMullen added a commit to dotnet/razor that referenced this issue Jan 14, 2020
- Included the LanguageServer core dlls as part of the VSIX install. To do this I had to expose the language server's output path via a target and then dynamically include its outputs in the VSIX output.
- Given how VSIX's are built I could not privately reference our language server to ensure that it's built when the VSIX is built. To work around this limitation I added a `_BuildLanguageServer` target that calls MSBuild directly on the language server as part of build.
- For now I'm dynamically booting the currently built language server that's deployed with the extension. I haven't given a lot of thought to what flavor of OS (x64 vs. x86) the server can run on; or if we need to ensure dotnet.exe is available.
- Found that the VS LSP client and the O# language server library that we use don't inter-operate as we'd expect. The server ends up telling the client that it doesn't care about text document change events (we do). I've created a separate PR in O# to fix this: OmniSharp/csharp-language-server-protocol#199
- Add OmniSharp 3rd party library to signing information for VSIX insertions.


dotnet/aspnetcore#17789
NTaylorMullen added a commit to dotnet/razor that referenced this issue Jan 14, 2020
- Included the LanguageServer core dlls as part of the VSIX install. To do this I had to expose the language server's output path via a target and then dynamically include its outputs in the VSIX output.
- Given how VSIX's are built I could not privately reference our language server to ensure that it's built when the VSIX is built. To work around this limitation I added a `_BuildLanguageServer` target that calls MSBuild directly on the language server as part of build.
- For now I'm dynamically booting the currently built language server that's deployed with the extension. I haven't given a lot of thought to what flavor of OS (x64 vs. x86) the server can run on; or if we need to ensure dotnet.exe is available.
- Found that the VS LSP client and the O# language server library that we use don't inter-operate as we'd expect. The server ends up telling the client that it doesn't care about text document change events (we do). I've created a separate PR in O# to fix this: OmniSharp/csharp-language-server-protocol#199
- Add OmniSharp 3rd party library to signing information for VSIX insertions.


dotnet/aspnetcore#17789
@NTaylorMullen NTaylorMullen added Done This issue has been fixed and removed Working labels Jan 14, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Feb 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates Done This issue has been fixed enhancement This issue represents an ask for new feature or an enhancement to an existing one
Projects
None yet
Development

No branches or pull requests

1 participant