Open eiriktsarpalis opened 2 hours ago
cc @eerhardt @stephentoub @sbomer
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis See info in area-owners.md if you want to be subscribed.
Here's a draft of the proposed change: https://github.com/dotnet/runtime/pull/108782
Adding just three suppressions removed the bulk of the RUC/RDC annotations from the STJ API surface.
Today all
JsonSerializer
methods acceptingJsonSerializerOptions
are marked asRequiresUnreferencedCode
/RequiresDynamicCode
on account of their behavior in a couple of cases:JsonSerializerOptions
is specified, it will be defaulted toJsonSerializerOptions.Default
.JsonSerializerOptions
is specified that doesn't explicitly set aTypeInfoResolver
, then that field will be silently populated usingJsonSerializerOptions.Default.TypeInfoResolver
.The pervasiveness of the annotations in some of the most commonly used APIs in STJ is creating substantial usability issues for library and Native AOT application authors, who often have to come up with elaborate workarounds to evade warnings.
What appears to be true for both cases is that code paths accessing unreferenced/dynamic code are guarded by the
JsonSerializer.IsRefectionEnabledByDefault
feature switch:JsonSerializerOptions.Default
constructor andTypeInfoResolver
populating behavior.It seems to me that this protection should suffice to remove the annotation; the
IsRefectionEnabledByDefault
feature switch is turned off by default for every application settingPublishTrimmed
totrue
. Granted, a trimmed/Native AOT application could explicitly turn onIsRefectionEnabledByDefault
but this is usually a case of misconfiguration. In any case, this is the tactic that has been employed by ASP.NET core since .NET 8 and one that just got rolled out in Microsoft.Extensions.AI so it makes sense that this a tried approach that we could try moving down the stack.