Allow services to use System.Text.Json for OOP comms in Razor #74280
Conversation
|
@dibarbet @tmat @CyrusNajmabadi PTAL. Mostly Razor EA changes, but one real roslyn change in the remote infra |
|
Ping @dotnet/roslyn-ide for reviews please |
| /// </summary> | ||
| internal readonly record struct JsonSerializableRazorPinnedSolutionInfoWrapper( | ||
| [property: JsonPropertyName("data1")] long Data1, | ||
| [property: JsonPropertyName("data2")] long Data2) |
There was a problem hiding this comment.
interesting. would like to know more about this. when are you guuys pinning solutions?
There was a problem hiding this comment.
@eiriktsarpalis how do longs get serialized in STJ? Are they guaranteed to roundtrip?
There was a problem hiding this comment.
interesting. would like to know more about this. when are you guuys pinning solutions?
hopefully never? This is just a version of RazorPinnedSolutionInfoWrapper, which is really just Checksum, but this serializes with STJ and that uses messagepack. I could add STJ attributes to RazorPinnedSolutionInfoWrapper, but then I'd need them on Checksum too.
This type is only used to call OOP, and is then passed back to roslyn to get the real solution
There was a problem hiding this comment.
@eiriktsarpalis how do longs get serialized in STJ? Are they guaranteed to roundtrip?
They serialize to JSON numbers which have arbitrary precision. They are guaranteed to roundtrip.
Requires dotnet/roslyn#74280, and won't even compile without it. Part of #9519 This brings signature help to Cohosting. It's a pretty simply PR, for a pretty simple endpoint, as we just delegate, and there is no translation of delegated info. The interesting part here is that we use `System.Text.Json` for the remote signature help service, because it makes more sense to take advantage of the existing Json converters for the potential complexity of the `SignatureHelp` result type.
4 participants
Given the amount of inheritance and variation in the LSP types, between VS and VS Code etc. the original plan to wrap LSP types for OOP comms, or add MessagePack compatible attributes, or something, seems way too hard. This is much easier :)
The use of Json is opt-in per service, so this will let us pick and choose the best method on a case-by-case basis.