-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
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
Milestone
Comments
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
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
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.
The text was updated successfully, but these errors were encountered: