F#：如何使用 Newtonsoft.Json 反序列化私有歧视联合？

Question

In his question and answer from 2018 , Onur Gumus used [<JsonObject(MemberSerialization = MemberSerialization.Fields)>] to enable serialization/deserialization of a discriminated union with a private constructor.

For me, the serialization works as advertised, but deserialization produces this error: " Newtonsoft.Json.JsonSerializationException: Unable to find a constructor to use for type FSI_0037+Foo. A class should either have a default constructor, one constructor with arguments or a constructor marked with the JsonConstructor attribute. "

Does anyone know how to get the deserialization working? I don't want to switch to a class type if it can be avoided. However, I've tried figuring out where to place a JsonConstructor attribute without any luck. I also tried passing a settings value with the ConstructorHandling value set to AllowNonPublicDefaultConstructor, but that changed nothing.

For convenience, I copy Onur's solution here:

open Newtonsoft.Json
[<JsonObject(MemberSerialization = MemberSerialization.Fields)>]
type Foo =  private Bar of string
let f = Bar "f"
let s = JsonConvert.SerializeObject(f)
let f2 = JsonConvert.DeserializeObject<Foo>(s)

printf "%A" f2

In case it matters (since things seem to have changed since 2018), I'm using .NET 5.

Answer 1

I am reasonably sure you have stumbled onto a bug.

When I copied the sample code you refer to into LINQPad v6.13.13, and ran it, then it worked fine. I then tried to replace the attribute with another attribute - the one I mentioned in the comment. Not unexpectedly that didn't compile. So I just reverted to the original attribute. Then I got the same compile error you encountered. That should not have happened. It's a bug. But where?

Further investigation has revealed that the compile error is produced erroneously if I do the following in LINQPad:

1. Open the code snippet from a file, and try to run it. This compiles and runs fine.
2. Comment out the attribute, and try to run it. This produces the compile error in question. This is as it should be.
3. Bring back the attribute, and try to run it. This should compile and run fine of course, since the source is now as it was in step 1, but it still produces the compile error in question.

Trying the same steps repeatedly will produce the same problem, whether I restart LINQPad between runs or not.

Then I tried to reproduce the problem with Visual Studio. I did not succeed - there is no such problem in VS 16.10.3

I have no more time at the moment, but will continue to investigate later. I want to check this with the latest LINQPad beta.

As for your question, was this the cause?

UPDATE

I have now checked with LINQPad v6.14.10, the current beta version. The bug is not present there. I am not surprised. As I've mentioned in a comment, the compiler is my prime suspect. Even more so because you tell you have the problem in VSCode. But there is an even more interesting detail.

LINQPad has used a very old version of the F# compiler service for ages, because there was a bug that prevented updating it. Joseph Albahari, the creator of LINQPad, recently got impatient waiting for a fix for this bug, and found a workaround. That fix is only in the beta. The huge leap in the F# compiler service version naturally means lots of bugs has been fixed, and likely this one too.

I am not going to pursue this further. I don't use VSCode, but if this problem is present even in the latest REPL there, then maybe somebody should look into it.