You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
StreamJsonRpc, as originally chosen to use for cross-process RAR request serialization, has proven problematic and ended up being the primary reason for reverting the work. It brings in a bunch of dependent assemblies: StreamJsonRpc, Nerdbank.Streams, MessagePack, MessagePack.Annotations. Surprisingly also Microsoft.VisualStudio.Threading, Microsoft.VisualStudio.Validation because of its close ties with Visual Studio.
The dependencies raise eyebrows - Why do I need "VisualStudio" in my .NET SDK package, it's adding size, etc. - and will add burden going forward synchronizing the dependencies with anything else running inside VS.
There is a known issue with another VS component which mistakenly loads Microsoft.VisualStudio.Threading from MSBuild directory (it's not uncommon to have this directory on the assembly load path), the proposed solution to which would be to move the assembly to a subdirectory under MSBuild.
Alternative solutions:
Stick with the insecure BinaryFormatter for now. Sooner or later MSBuild will have to move over to something else anyways and adding this one use-case shouldn't incur much additional cost.
Hand-write a custom serializer (no external dependecies!).
Pick another existing serialization library: Protocol buffers, Bond, ...
What should be the criteria on which to pick the protocol?
Perf, security, protocol actively maintained, easy to deploy (needs runtime dependencies or not), homogeneity (with MSBuild and other .NET tools), adoption cost, …
Next steps: Define criteria, assign weights, investigate and measure to fill out a table, and come up with the winner.
The text was updated successfully, but these errors were encountered:
We have decided to keep using the existing serialization technology based on BinaryFormatter and have the parent User Story focused only on RAR and not on this orthogonal problem. BinaryFormatter will be replaced in all of MSBuild IPC later.
StreamJsonRpc, as originally chosen to use for cross-process RAR request serialization, has proven problematic and ended up being the primary reason for reverting the work. It brings in a bunch of dependent assemblies: StreamJsonRpc, Nerdbank.Streams, MessagePack, MessagePack.Annotations. Surprisingly also Microsoft.VisualStudio.Threading, Microsoft.VisualStudio.Validation because of its close ties with Visual Studio.
Alternative solutions:
What should be the criteria on which to pick the protocol?
Next steps: Define criteria, assign weights, investigate and measure to fill out a table, and come up with the winner.
The text was updated successfully, but these errors were encountered: