Skip to content

MessagePack for C# v4: Round4 - #2290

Draft
neuecc wants to merge 4 commits into
masterfrom
v4
Draft

MessagePack for C# v4: Round4#2290
neuecc wants to merge 4 commits into
masterfrom
v4

Conversation

@neuecc

@neuecc neuecc commented Aug 7, 2026

Copy link
Copy Markdown
Member

This round resolves the netstandard2.0 -> net10 compatibility problem that was the main concern from the previous round.
Rewrites MessagePackFormatterFactory, and implements nearly all formatters.
With this, the core is now mostly finalized.

  • DLLs compiled against netstandard2.0 now run on net10 as well
    • Previously this only went as far as throwing an exception with a dedicated message. This has been moved forward: at the Serialize/Deserialize root we now detect whether the graph contains legacy formatters, and if so, pass compatible buffer implementations as IWriteBuffer/IReadBuffer, so everything just works
    • The analyzer that raised an error when net10 was not included in the targets has been removed — it was unnatural and placed too much burden on third parties
    • I consider the v4 compatibility problem solved with this
    • The performance penalty of the compatible tier is around +4–7%
      • Given the overall speedup, this is an acceptable range — even the compatible tier is still overwhelmingly faster than the others
  • IMessagePackFormatterFactory -> MessagePackFormatterFactory
    • The API now provides MessagePackFormatterFactory.Default, .DefaultAot, .DotNetOptimized, and .DotNetOptimizedAot as the built-in factories, plus .Combine() to return composed ones
    • DefaultAot is Default with GenericFormatterFactory removed, and is therefore not [RequiresDynamicCode]
    • DotNetOptimized uses formats more optimized than the default — for example, binary for Guid. Since DotNetOptimized can also read data in the Default format, you can migrate from Default to DotNetOptimized later
      • It does not use any dangerous mappings, so it is safe and can be used with untrusted data.
  • Collection formatters implemented to meet security requirements
    • Depth checks during serialization/deserialization
    • HashDoS resistance using SipHash-1-3
    • Validation of malicious length headers
  • The output format of the Default formatters maintains 100% compatibility with v3
    • OldSpec is automatically compatible for reading only; writing is not supported

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant