Json serializer code generator doesn't support internal constructors

[dotMorten]

Description

If I have a public class that I want to be able to deserialize, but I don't want that class publicly constructable, I can no longer deserialize it, even though the generated deserializer code has access to the internal constructor.

This issue prevents moving from DataContractJsonSerializer to S.T.J.

Reproduction Steps

In a console app, add the following code:

using System.Text.Json;
using System.Text.Json.Serialization;

string json = "{\"name\":\"Hello World\"}";

var obj = JsonSerializer.Deserialize(json, MyDataModelSerializationContext.Default.MyDataModel);

[JsonSerializable(typeof(MyDataModel))]
[JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase)]
internal partial class MyDataModelSerializationContext : JsonSerializerContext
{
}

public class MyDataModel
{
    // [JsonConstructor] Won't make a difference
    internal MyDataModel() { }
    public string? Name { get; set; }
}

Expected behavior

Object deserializes.

Actual behavior

Exception thrown on deserialize:

System.NotSupportedException: 'Deserialization of types without a parameterless constructor, a singular parameterized constructor, or a parameterized constructor annotated with 'JsonConstructorAttribute' is not supported. Type 'MyDataModel'. Path: $ | LineNumber: 0 | BytePositionInLine: 1.'

Looking at the generated code, you'll note the ObjectCreator is null.

Compare that to when the constructor is declared public:

Related

A similar issue is hit with a data model like this:

internal class MyDataModel
{
    [JsonPropertyName("name")]
    public string? Name { get; internal set; }
}

In this case for this internal class, a setter isn't generated for the Name property and during serialization the value is never defined. Granted in this case there's no need to mark it internal since the entire class is already internal - however even if the class is public, I can't restrict the setter from public abuse and only allow the deserializer to set it.

Regression?

No response

Known Workarounds

Not really. If I make the entire class internal (and make the constructor public albeit it is effectively internal now), it works again. However I do want my class to be publicly accessible

Configuration

.net 6.0.401

Other information

No response

[ghost]

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

Issue Details

---

Description

If I have a public class that I want to be able to deserialize, but I don't want that class publicly constructable, I can no longer deserialize it, even though the generated deserializer code has access to the internal constructor.

Reproduction Steps

In a console app, add the following code:

using System.Text.Json;
using System.Text.Json.Serialization;

string json = "{\"name\":\"Hello World\"}";

var obj = JsonSerializer.Deserialize(json, MyDataModelSerializationContext.Default.MyDataModel);

[JsonSerializable(typeof(MyDataModel))]
[JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase)]
internal partial class MyDataModelSerializationContext : JsonSerializerContext
{
}

public class MyDataModel
{
    // [JsonConstructor] Won't make a difference
    internal MyDataModel() { }
    public string? Name { get; set; }
}

Expected behavior

Object deserializes.

Actual behavior

Exception thrown on deserialize:

System.NotSupportedException: 'Deserialization of types without a parameterless constructor, a singular parameterized constructor, or a parameterized constructor annotated with 'JsonConstructorAttribute' is not supported. Type 'MyDataModel'. Path: $ | LineNumber: 0 | BytePositionInLine: 1.'

Looking at the generated code, you'll note the ObjectCreator is null.

Compare that to when the constructor is declared public:

Regression?

No response

Known Workarounds

Not really. If I make the entire class internal (and make the constructor public albeit it is effectively internal now), it works again. However I do want my class to be publicly accessible

Configuration

.net 6.0.401

Other information

No response

Author:	dotMorten
Assignees:	-
Labels:	area-System.Text.Json
Milestone:	-

[layomia]

Triage: this can be considered for .NET 8.0.

[eiriktsarpalis]

FWIW this is by design and consistent with the behavior of the reflection-based serializer. A notable exception is internal getter/setter support via the JsonIncludeAttribute -- we might consider extending this to constructors (or extend the JsonConstructorAttribute so that internal constructors can be annotated) but obviously there will be restrictions when it comes to the source generator.

[dotMorten]

FWIW this is by design and consistent with the behavior of the reflection-based serializer.

I'm literally porting from the reflection based DataContractSerializer and it works just fine with these internal classes and properties. If we don't have parity I find it hard for us to move and start supporting full trimming in our assemblies. Perhaps there could at least be a setting on JsonSourceGenerationOptions to support internal members? As it stands right now, this is a blocker for us wrt being able to move.

[eiriktsarpalis]

Is making the constructors public an option?

[dotMorten]

No :(

[jkotas]

EF Core is running into similar set of issues with source-generating equivalent of private reflection. Once you start looking at this, we should talk about the possible solutions.

[eiriktsarpalis]

What might be a way to offer a source-generating equivalent of private reflection? I suppose it might be possible to generate member accessor stubs inside the type declaration itself provided it lives in the same project, but is there any other way you have in mind?

[jkotas]

What might be a way to offer a source-generating equivalent of private reflection?

One extreme is to make JIT pattern-match reflection calls with constant inputs and replace them with direct invocations. For example, if you wrote typeof(MyType).GetMethod("MyMethod", BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance, new Type[] { typeof(string), typeof(int) }).Invoke(thisArg, new object[] { stringArg, intArg }), the JIT can replace it with thisArg.MyMethod(stringArg, intArg) in theory. This would be a very complex and fragile pattern match. I do not think we want to do that.

Other extreme is to emit IL (either via an extra IL .dll or via IL rewriting). It is possible to suppress visibility checks in IL today using IgnoresAccessChecksToAttribute. https://gist.github.com/jkotas/ddfeb9ec47bff90b4249534c4cd0761a shows a small demo using Fody. Extra IL file or IL rewriting comes with a bunch of problems that are very hard to solve (e.g. IL rewriting breaks edit-and-continue). I do not think we want to do that.

So the idea is that we may be able to come up with something viable (e.g. new runtime API) between these two extremes.

[eiriktsarpalis]

Closing in favor of the more general user story tracked in #87431