FATAL UNHANDLED EXCEPTION: System.InvalidOperationException: JsonSerializerIsReflectionDisabled in .NET for Android

[FANMixco]

Description

I have built a .NET for Android app with .NET 8 (not MAUI). The app works perfectly when I don't link the libs. But when I tried to link them using: <TrimMode>link</TrimMode>, then I get the following error:

[ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidOperationException: JsonSerializerIsReflectionDisabled
08-13 10:09:59.275 25131 25237 F mono-rt : at System.Text.Json.JsonSerializerOptions.ConfigureForJsonSerializer()

I have tried to exclude the lib, but nothing worked. I have tried to add this to the .csproj:

  <ItemGroup>
    <LinkerDescriptor Include="Linker.xml" />
  </ItemGroup>

And exclude the full lib but didn't work also:

<?xml version="1.0" encoding="utf-8" ?>
<linker>
  <assembly fullname="System.Text.Json">
    <type fullname="System.Text.Json.JsonSerializer" />
    <type fullname="System.Text.Json.JsonSerializerOptions" />
    <type fullname="System.Text.Json.JsonDocument" />
    <type fullname="System.Text.Json.JsonElement" />
    <type fullname="System.Text.Json.JsonTokenType" />
    <type fullname="System.Text.Json.JsonPropertyName" />
    <type fullname="System.Text.Json.Serialization.JsonConverter" />
    <type fullname="System.Text.Json.Serialization.JsonConverterFactory" />
  </assembly>
</linker>

Avoiding the linking increases the size of the app in almost 1 MiB. So, I'd like to know what I should do.

Reproduction Steps

The code that is failing is the following:

         var timetable = JsonSerializer.Deserialize<List<Timetable>>(results);

        public class Timetable
        {
            public int id { get; set; }
            public string member { get; set; }
            public string role { get; set; }
            public string min { get; set; }
            public string opt { get; set; }
            public string max { get; set; }
            public string time { get; set; }
            public string lastColor { get; set; }
            public bool disqualified { get; set; }
        }

I also tried to exclude the crashing methods adding this:

        //The first line is what I added, yes, I'm calling .NET from JS. This is working if I don't link anything.
        [DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(CallJSInterface))]
        [JavascriptInterface]
        [Export]
        public void ExportToExcel(string data)

No changes.

Also, I tested the suggested solution with the same result:

This is expected behavior when using the reflection-based serializer in trimmed applications. You should consider switching to the source generated serializer instead:

https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/source-generation?pivots=dotnet-8-0

It didn't work.

partial class CallJSInterface
    {
        [JsonSourceGenerationOptions(WriteIndented = true)]
        [JsonSerializable(typeof(List<Timetable>))]
        internal partial class TimetableContext : JsonSerializerContext
        {
        }

        public class Timetable
        {
            public int id { get; set; }
            public string member { get; set; }
            public string role { get; set; }
            public string min { get; set; }
            public string opt { get; set; }
            public string max { get; set; }
            public string time { get; set; }
            public string lastColor { get; set; }
            public bool disqualified { get; set; }
        }
    }

        private static List<Timetable> DeserializeTT(string results)
        {
            return JsonSerializer.Deserialize(results, TimetableContext.Default.ListTimetable);
        }

I'm not sure sure if I should change here also:

var timetable = timetable.Where(x => JsonSerializer.Deserialize<List<int>>(selected).Contains(x.id)).ToList();

However, I don't know how to use the previous documentation for an int since it's not any special class.

Expected behavior

To don't fails.

Actual behavior

Fails when it tries to execute the previously provided code. The rest of the app works and also works if it's not linked.

Regression?

N/A

Known Workarounds

N/A

Configuration

N/A

Other information

N/A

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

You can reply to the origin issue for further questions.

As the exception message says, reflection-based mechanics are disabled when trimming is on, so any trimming related work are unrelated. It's not because something being absent, instead System.Text.Json doesn't invoke them at all.

According to Deserialization examples section in documentation, you need to update the JsonSerializer.Deserialize calls with source generation context.

I'm not sure sure if I should change here also:

var timetable = timetable.Where(x => JsonSerializer.Deserialize<List<int>>(selected).Contains(x.id)).ToList();

However, I don't know how to use the previous documentation for an int since it's not any special class.

You do need to change here too. In source generation mode, you must be explicit about types you want to serialize, otherwise you won't be able to serialize a single integer. The non-special types support will be trimmed away if you don't specify them.

In other words, the Serialize and Deserialize overloads without context will always throw, no matter what types they are used with.

[eiriktsarpalis]

I've converted this to a discussion so we can continue the conversation here.

[FANMixco]

Can you provide me any potential idea of how to fix it the int @huoyaoyuan ? Since I don't know how the other class should look like. Thanks.

[elgonzo]

I am not sure what other class you are referring to, but JsonSerializer.Deserialize<List<int>>(selected) doesn't use a (source-generated) serialization context. You need to use a serialization context that is aware of the root type you are trying to deserialize into. In this case the root type here is List<int>. (If you are using a serialization context that isn't aware of the root type for deserialization, the deserializer would throw an exception informing you about this fact, by the way...)

You don't necessarily need to create separate serialization context classes (but you can), as you can let a single serialization context class handle multiple root types by simply using multiple [JsonSerializable] attributes. For example:

[JsonSourceGenerationOptions(WriteIndented = true)]
[JsonSerializable(typeof(List<Timetable>))]
[JsonSerializable(typeof(List<int>))]
internal partial class MyContext : JsonSerializerContext
{ }

JsonSerializer.Deserialize(selected, MyContext.Default.ListInt32);

---

Side note / FYI: If the type graph of the root types somewhere contains a (public) property of a type that would also be used as a root type for another deserialization task, strictly speaking you don't need to use another [JsonSerializable] annotation for that type as the serialization context then would already be aware of that type.

For example, if your TimeTable class would contain a List<int> property, like for example:

public class Timetable
{
    public int id { get; set; }
    public List<int> FooBar { get; set; }
    ...
}
...
[JsonSerializable(typeof(List<Timetable>))]
internal partial class TimetableContext : JsonSerializerContext
{ }

you would then be able to deserialize List<int> as a root type despite not having a [JsonSerializable] annotation for it by using the Serialize/Deserialize overloads that accept the JsonSerializerContext instance itself (just for illustration purposes; i do NOT recommend doing it this way):

    (List<int>) JsonSerializer.Deserialize(selected, typeof(List<int>), TimetableContext.Default);

I do NOT recommend doing it this way without declaring List<int> as a root type using [JsonSerializable]. the code is less readable/understandable because of the context's awareness of the List<int> type not being clear and easily understood without perusing the type graphs of the root types declared with [JsonSerializable]. More concerning however, i find it to be a sneaky maintenance risk. Because if you ever refactor Timetable and remove or change the type of FooBar, well, then

(List<int>) JsonSerializer.Deserialize(selected, typeof(List<int>), TimetableContext.Default);

suddenly won't work anymore, with the deserializer throwing an exception about the serialization context not being aware of List<int>. (This is also the reason of why i personally try to avoid using the Serialize/Deserialize overloads that accept the JsonSerializationContext instance itself.)