Exception when attempting to deserialize POCO using Json.NET

[rdavisau]

Great work on this project! I've been having a play with Blazor recently and run into a hitch when trying to use it in conjunction with Json.NET. I know that the cause behind this could manifest anywhere between Blazor, Json.NET and the WASM bits so I apologise in advance if this isn't ultimately the right place to raise it. I won't be offended if you tell me to take this to another repo :)

Title

Exception when attempting to deserialize POCO using Json.NET

Functional impact

Per title

Minimal repro steps

1. Create a new Blazor project using the ASP.NET Core Project wizard in Visual Studio 2017 Preview
2. Install-Package Newtonsoft.Json
3. Replace OnInitAsync in the FetchData component with below:

protected override async Task OnInitAsync()
{
    var emptyJson = "{ }";
    var json = "{ \"Summary\" : \"Value\" }";

    // all working
    Console.WriteLine($"JObject - {JsonConvert.DeserializeObject<JObject>(json)}");
    Console.WriteLine($"ExpandoObject - {JsonConvert.DeserializeObject<ExpandoObject>(json)}");
    Console.WriteLine($"Dictionary<string, object> - {JsonConvert.DeserializeObject<Dictionary<string, object>>(json)}");

    // no setter called, no problem
    Console.WriteLine($"POCO, no setters called - {JsonConvert.DeserializeObject<WeatherForecast>(emptyJson)}");

    // boom
    Console.WriteLine($"POCO, setter called - {JsonConvert.DeserializeObject<WeatherForecast>(json)}");
}

4. Launch the project and navigate to Fetch data page
5. Open console to see output

Expected result

All five calls succeed and display the .ToString() representation of the deserialized objects.

Actual result

4/5 calls succeed and exception is raised for the last.

Further technical details

It seems that POCOs fail to deserialize, specifically when a set operation is called, with the below output:

WASM: [Newtonsoft.Json.JsonSerializationException] Error setting value to 'Summary' on 'WebApplication5.Pages.FetchData+WeatherForecast'. ---> System.NullReferenceException: Object reference not set to an instance of an object. 
WASM: at Newtonsoft.Json.Serialization.ExpressionValueProvider.SetValue (System.Object target, System.Object value) <0x1cf1220 + 0x00086> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.SetPropertyValue (Newtonsoft.Json.Serialization.JsonProperty property, Newtonsoft.Json.JsonConverter propertyConverter, Newtonsoft.Json.Serialization.JsonContainerContract containerContract, Newtonsoft.Json.Serialization.JsonProperty containerProperty, Newtonsoft.Json.JsonReader reader, System.Object target) <0x1cf0508 + 0x00158> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateObject (System.Object newObject, Newtonsoft.Json.JsonReader reader, Newtonsoft.Json.Serialization.JsonObjectContract contract, Newtonsoft.Json.Serialization.JsonProperty member, System.String id) <0x1ce7cb8 + 0x003e8> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject (Newtonsoft.Json.JsonReader reader, System.Type objectType, Newtonsoft.Json.Serialization.JsonContract contract, Newtonsoft.Json.Serialization.JsonProperty member, Newtonsoft.Json.Serialization.JsonContainerContract containerContract, Newtonsoft.Json.Serialization.JsonProperty containerMember, System.Object existingValue) <0x1c3d5b8 + 0x0029c> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateValueInternal (Newtonsoft.Json.JsonReader reader, System.Type objectType, Newtonsoft.Json.Serialization.JsonContract contract, Newtonsoft.Json.Serialization.JsonProperty member, Newtonsoft.Json.Serialization.JsonContainerContract containerContract, Newtonsoft.Json.Serialization.JsonProperty containerMember, System.Object existingValue) <0x1b9c508 + 0x000ca> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize (Newtonsoft.Json.JsonReader reader, System.Type objectType, System.Boolean checkAdditionalContent) <0x19646a0 + 0x001a6> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.JsonSerializer.DeserializeInternal (Newtonsoft.Json.JsonReader reader, System.Type objectType) <0x195ca10 + 0x000ac> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.JsonSerializer.Deserialize (Newtonsoft.Json.JsonReader reader, System.Type objectType) <0x195c330 + 0x0001c> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.JsonConvert.DeserializeObject (System.String value, System.Type type, Newtonsoft.Json.JsonSerializerSettings settings) <0x19269d0 + 0x00060> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.JsonConvert.DeserializeObject[T] (System.String value, Newtonsoft.Json.JsonSerializerSettings settings) <0x1cb3b20 + 0x00020> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at Newtonsoft.Json.JsonConvert.DeserializeObject[T] (System.String value) <0x1cb3ae8 + 0x0000a> in <d32db49e5e3440729da31845c03ddc3a>:0 
WASM: at WebApplication5.Pages.FetchData+<OnInitAsync>d__2.MoveNext () <0x1925bd8 + 0x00096> in <2cb2c533ff6b4424901e788f72648786>:0 

I have also seen a more detailed stacktrace which I happen to have a screenshot of:

Versions

Microsoft.AspNetCore.Razor.Design 2.1.0-preview2-30230
Microsoft.AspNetCore.Blazor.Browser 0.1.0
Microsoft.AspNetCore.Blazor.Build 0.1.0
Newtonsoft.Json 11.0.2

netcore 2.1.300-preview1-008174

Visual Studio Enterprise 2017 Preview (15.7.0 Preview 2.0)

[rynowak]

One limitation that we have right now is that there isn't a good way for a library to know at runtime that it's running in mono on wasm.

My guess from the call stack is that there is a problem with the code that JSON.NET is using to generate compiled expressions, which it uses for property getters/setters. I'm not sure what the long term solution to this will be.

[danroth27]

@kumpera Is this an expected limitation with compiled expressions?

[danroth27]

Closing as there isn't anything we can do about this in Blazor, but we will follow up with the Mono folks.

[danroth27]

mono/mono#7839

[kumpera]

@danroth27 not 100%, we invested a lot of time in the SLE interpreter.
As a rule of thumb, if it works under Xamarin.iOS, is should work under WebAssembly. It's a bad one, I know, but it's the best approximation I can get right now.

CC @marek-safar as he knows this area the best.

[danroth27]

Turns out the issues we've had with Json.NET are with our linker configuration. If you want to use Json.NET in a Blazor app you should be able to get it to work by using the following linker configuration: https://gist.github.com/Suchiman/a5e65f40c353120c9cf7f6a631ded28b.

[rdavisau]

Using the above worked for me, thanks 👏

[MitchellEnsink]

@danroth27 Adding the linker doesn't seem to work for me. I'm getting the following error:

Error	MSB3073
The command "dotnet "C:\Users\Mitchell\.nuget\packages\microsoft.aspnetcore.blazor.build\0.5.1\targets\../tools/illink/illink.dll" -l none -c link -u link -b true -t --verbose  -d "C:\Users\Mitchell\.nuget\packages\microsoft.aspnetcore.blazor.build\0.5.1\targets\../tools/mono/bcl/" -d "C:\Users\Mitchell\.nuget\packages\microsoft.aspnetcore.blazor.build\0.5.1\targets\../tools/mono/bcl/Facades/" -o "D:\Documents\BlazorLinker\BlazorLinker\obj\Debug\netstandard2.0\blazor/linker/" -x "D:\Documents\BlazorLinker\BlazorLinker\Linker.xml" -a "C:\Users\Mitchell\.nuget\packages\microsoft.aspnetcore.blazor\0.5.1\lib\netstandard2.0\Microsoft.AspNetCore.Blazor.dll" -a "C:\Users\Mitchell\.nuget\packages\microsoft.aspnetcore.blazor.browser\0.5.1\lib\netstandard2.0\Microsoft.AspNetCore.Blazor.Browser.dll" -a "C:\Users\Mitchell\.nuget\packages\microsoft.extensions.dependencyinjection\2.1.0\lib\netstandard2.0\Microsoft.Extensions.DependencyInjection.dll" -a "C:\Users\Mitchell\.nuget\packages\microsoft.extensions.dependencyinjection.abstractions\2.1.0\lib\netstandard2.0\Microsoft.Extensions.DependencyInjection.Abstractions.dll" -a "C:\Users\Mitchell\.nuget\packages\microsoft.jsinterop\0.5.1\lib\netstandard2.0\Microsoft.JSInterop.dll" -a "C:\Users\Mitchell\.nuget\packages\mono.webassembly.interop\0.5.1\lib\netstandard2.0\Mono.WebAssembly.Interop.dll" -a "C:\Program Files\dotnet\sdk\NuGetFallbackFolder\newtonsoft.json\11.0.2\lib\netstandard2.0\Newtonsoft.Json.dll" -a "D:\Documents\BlazorLinker\BlazorLinker\obj\Debug\netstandard2.0\BlazorLinker.dll"" exited with code 1.	BlazorLinker	C:\Users\Mitchell\.nuget\packages\microsoft.aspnetcore.blazor.build\0.5.1\targets\Blazor.MonoRuntime.targets	441

I'm using Blazor 0.5.1, though I was also getting the error with 0.4.0.
Clean, Rebuild and restarting Visual Studio don't have any effect.'

Source code: https://github.com/MitchellEnsink/BlazorLinker

Steps to reproduce:

1. Create new Blazor 0.5.1 project (non-hosted variant)
2. Add the linker.xml file you provided to project
3. Copy the contents of the .csproj you provided into the existing .csproj, but change the Blazor version numbers to 0.5.1

My setup:
OS: Windows 10 Home version 1803 build 17134.165
.NET Core version 2.1.302
Visual Studio Community 2017 version 15.7.5
ASP.NET Core Blazor Language Services version 15.7.10384

[danroth27]

@MitchellEnsink Yeah, I've also seen some issues using Json.NET with the latest Blazor bits even when using the linker config @Suchiman put together. Can you try disabling linking on build completely by adding the <BlazorLinkOnBuild>False</BlazorLinkOnBuild> MSBuild property and see if that addresses the issue?

[MitchellEnsink]

@danroth27 Yes, setting BlazorLinkOnBuild to seems to solve the original issue with Json.NET without the need for the linker config.

[danroth27]

@marek-safar we could use some guidance on how to configure the IL linker so that libraries like Json.NET "just work". Are there changes that @JamesNK could make to Json.NET to facilitate this?

[marek-safar]

@danroth27 Please follow documentation we have at https://docs.microsoft.com/en-us/xamarin/ios/deploy-test/linker?tabs=vsmac it applies to wasm as well

[danroth27]

Thanks @marek-safar! This documentation is very helpful for understanding how you can configure the IL linker. But I think it still leaves a lot for library authors to figure out to make their libraries work well with IL linking. I think what's needed is guidance for library authors that walks through the process of taking an existing library that wasn't originally designed for IL linking and then determining which parts need to be explicitly preserved. This guidance would enable library authors to methodically update their libraries to support IL linking instead of playing whack-a-mole with linker related issues.