System.Text.Json support

[arkadiuszwojcik]

Hello, I would like to ask if it is possible to implment in Anvil features discussed here: System.Text.Json + NativeAOT ? @pablopioli implemented it already in his fork I also created certes fork with this changes implemented and it works fine for me, although I would prefere to have it in this repo as it is better mantained. I could even try to create PR for that.

[webprofusion-chrisc]

Eventually we would indeed like to switch to System.Text.Json but it really depends on what's currently required for Certify The Web. I would like to think this repo is better maintained but on the other hand our absolute priority is compatibility and stability within Certify and we don't prioritize supporting other consumers of the library - if Anvil works for you that's great :) but we also will make changes that can break compatibility with other consumers.

From memory my main issue with the System.Text.Json port was the amount of changes required and serialization hints that it needs to enable AOT. If we can find a way to support System.Text.Json +AOT with absolutely minimal differences that would be ideal, but it may be too difficult.

[arkadiuszwojcik]

Just some notes from my conversion, regarding AOT:

1. AOT requires explicit classes, there are few places where payload is serialized using dynamic objects. In Certes it was 6 additional payload classes that have to be added. Such change can be done even for current Newtonson.Json solution (as first step). Basicaly remove all = new { ... }
2. AOT require additional JsonSerializerContext class, with list of all serializable classes provided as annotation

[webprofusion-chrisc]

Thanks, some other things that might require consideration:

• the ACME newOrder payload can include the ARI "replaces" field but it's generally best practise not to send this field if a CA doesn't support the (still in draft) ARI standard. So serialization of that field would need to be skipped if it's value is null.
• Things like JsonWebKey key types have fields which require a specific serialization order.
• We support both .net 462 and dotnet 7+ currently. We need to retain .net 462 support for the time being and don't really want a lot of conditional compilation with different code paths to maintain, if that can be avoided.
• We would need new serialization tests to check the serialization output but I'm not sure if AOT output is testable in that way? Haven't used it much yet.

[arkadiuszwojcik]

From what I remember:

• There is annotation for that: [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
• There is annotation for that: [JsonPropertyOrder(1)]
• Not sure about that. In theory System.Text.Json support .net 462 so it should work, In case of AOT new compiler just generates extra code for json serializable classes so should not affect older version of .net provided that generated code don't use some fancy language constructions not avaliable in .net 462
• Not sure about that, how such test should look like

[pablopioli]

Adding to this thread: everything @arkadiuszwojcik said is correct.
About the AOT output: you can test it against a string literal, so you're absolutly right about the generated Json.

[arkadiuszwojcik]

Just for reference, looks like this ACMESharpCore fork use System.Text.Json and supports AOT but their minimal target is .net 7, so status of potential .net 462 is unknown.