Using the System.Text.Json source generator with ASP NET Core throws NotSupportedException when attempting to serialize IEnumerable<T> #43894

JakeYallop · 2022-09-09T23:50:33Z

Is there an existing issue for this?

I have searched the existing issues

Describe the bug

This was a scenario that was working in .NET 6.0.

When using the .NET 7.0 System.Text.Json source generator with controllers (this is not reproduceable using minimal APIs), ASP NET Core fails to deserialize IEnumerable results.

NotSupportedException: Metadata for type 'System.Collections.Generic.List`1[JsonSourceGenIEnumerableRepro.MyClass]' was not provided by TypeInfoResolver of type 'JsonSourceGenIEnumerableRepro.JsonContext'. If using source generation, ensure that all root types passed to the serializer have been indicated with 'JsonSerializableAttribute', along with any types that might be serialized polymorphically.
  System.Text.Json.ThrowHelper.ThrowNotSupportedException_NoMetadataForType(Type type, IJsonTypeInfoResolver resolver)
  System.Text.Json.JsonSerializerOptions.GetTypeInfoCached(Type type)
  System.Text.Json.JsonSerializer.GetTypeInfo(JsonSerializerOptions options, Type runtimeType)
  System.Text.Json.JsonSerializer.SerializeAsync(Stream utf8Json, object value, Type inputType, JsonSerializerOptions options, CancellationToken cancellationToken)
  Microsoft.AspNetCore.Mvc.Formatters.SystemTextJsonOutputFormatter.WriteResponseBodyAsync(OutputFormatterWriteContext context, Encoding selectedEncoding)
  Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeResultFilters>g__Awaited|28_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, object state, bool isCompleted)
  Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, object state, bool isCompleted)
  Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
  Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
  Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
  Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

Calling JsonSerializer.Serialize(enumerable, JsonContext.Default.IEnumerableJsonTypeInfo) manually succeeds.

Expected Behavior

JSON serialization by the ASP NET Core controller infrastructure has the same behaviour as if JsonSerializer.Serialize was called.

Steps To Reproduce

https://github.com/JakeYallop/JsonSourceGeneratorIEnumerableRepro

using Microsoft.AspNetCore.Mvc;
using System.Text.Json;
using System.Text.Json.Serialization;

namespace JsonSourceGenIEnumerableRepro;

public class Program
{
    public static void Main(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);

        var l = new List<MyClass> { new(), new() };
        //using the STJ source gen default infrastructure succeeds without failing
        var output = JsonSerializer.Serialize(l, JsonContext.Default.IEnumerableMyClass);

        builder.Services
            .AddMvcCore()
            .AddJsonOptions(options =>
            {
                options.JsonSerializerOptions.AddContext<JsonContext>();
            });


        var app = builder.Build();

        app.MapControllers();
        app.Run();
    }
}


[Route("")]
public class MyController : ControllerBase
{
    public MyController()
    {
    }

    [HttpGet("")]
    public IActionResult Get()
    {
        var l = new List<MyClass> { new(), new() };
        return Ok(l);
    }
}

[JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase)]
[JsonSerializable(typeof(IEnumerable<MyClass>))]
public partial class JsonContext : JsonSerializerContext
{

}

public class MyClass
{
    public int MyProp { get; set; }
}

Exceptions (if any)

See above

.NET Version

7.0.100-rc.2.22459.2

Anything else?

dotnet --info output (click to view)

``` .NET SDK: Version: 7.0.100-rc.2.22459.2 Commit: 11f6b8f712

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19043
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\7.0.100-rc.2.22459.2\

Host:
Version: 7.0.0-rc.2.22451.11
Architecture: x64
Commit: 6d10e4c8bc

.NET SDKs installed:
3.1.422 [C:\Program Files\dotnet\sdk]
5.0.100 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
5.0.214 [C:\Program Files\dotnet\sdk]
5.0.303 [C:\Program Files\dotnet\sdk]
6.0.101 [C:\Program Files\dotnet\sdk]
6.0.108 [C:\Program Files\dotnet\sdk]
6.0.202 [C:\Program Files\dotnet\sdk]
6.0.203 [C:\Program Files\dotnet\sdk]
6.0.400 [C:\Program Files\dotnet\sdk]
7.0.100-rc.2.22459.2 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.0-rc.2.22452.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.0-rc.2.22451.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.28 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.0-rc.2.22431.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
arm64 [C:\Program Files\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\arm64\InstallLocation]
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
C:\Users\Agmas\source\repos\JsonSourceGenIEnumerableRepro\global.json

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

</details>

The text was updated successfully, but these errors were encountered:

martincostello · 2022-09-10T08:08:32Z

I think the root cause will be the same as #43236, which is due to changes to S.T.J itself.

JakeYallop · 2022-09-10T08:33:05Z

I don't think that this is the same underlying issue.

In #43236, the source generated context has no direct reference to the underlying ProblemDetails type, whereas is this case the context has all the information it needs (we have explicitly opted in with a JsonSerializable attribute on the context), as demonstrated by the fact that serialization via JsonSerializer.Serialize using the source-generated JsonTypeInfo is successful.

There should be no need for a custom type resolver in this case.

Interestingly, using a List<MyClass> instead of an IEnumerable<MyClass> appears to work without an issue.

JakeYallop · 2022-09-10T12:43:09Z

Another data point - a nested IEnumerable property serializes successfully without any errors.

[JsonSerializable(typeof(NestedEnumerable))]
public partial class JsonContext : JsonSerializerContext { }

//...
public class NestedEnumerable
{
    public IEnumerable<MyClass> NestedIEnumerable { get; set; } = null!;
}

//...
[HttpGet("nested")]
public IActionResult Get2()
{
    var l2 = new NestedEnumerable()
    {
        NestedIEnumerable = new List<MyClass>() { new(), new(), new() }
    };
    return Ok(l2);
}

davidfowl · 2022-09-12T04:04:27Z

The issue is [JsonSerializable(typeof(IEnumerable<MyClass>))] vs [JsonSerializable(typeof(List<MyClass>))].

This explicit call:

var output = JsonSerializer.Serialize(l, JsonContext.Default.IEnumerableMyClass);

Is not the moral equivalent of what MVC is doing. The generic is inferred as IEnumerable<MyClass> so it works:

The equivalent would be this:

var options = new JsonSerializerOptions(JsonSerializerDefaults.Web);
options.AddContext<JsonContext>();
await System.Text.Json.JsonSerializer.SerializeAsync(new MemoryStream(), l, l.GetType(), options);

Which also throws. MVC passes the concrete type (which is List<MyClass>) to serialize.

TL;DR change your code to this:

[JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase)]
[JsonSerializable(typeof(List<MyClass>))]
public partial class JsonContext : JsonSerializerContext
{

}

And it should work.

JakeYallop · 2022-09-12T07:01:22Z

@davidfowl, in this simplified example I know exactly what the underlying type is, and could use List<T> - what about if I had a HashSet<T>, Collection<T>, or some other collection returned from a method that returned IEnumerable?

The important thing to realise is that this surfaces as a regression and will break existing code that updates to .NET 7.0. I also think its totally reasonable that we might want to use the abstraction IEnumerable<T>, rather than a concrete type (which we might not know ahead of time).

Good point about async serialization - I was thinking about that yesterday, that, of course, ASP .NET Core is going to be using the async serialization code path.

I'll open another issue in the .NET runtime repo to surface this change in behaviour, thanks for your help!

davidfowl · 2022-09-12T07:02:38Z

Why are you using the source generator at all?

JakeYallop · 2022-09-12T07:14:46Z

Just to get experience using it in a personal project - I don't really need the additional perf in this case. I think this behavioural change might be most likely to surface in performance focused libraries that would want to be a) high performance and b) trim safe, that use async serialization behind the scenes.

davidfowl · 2022-09-12T07:20:36Z

The change is by design BTW dotnet/runtime#71714. You need to enumerate all types that will be used for serialization when using the source generator and it will no longer fall back to reflection based when it can't find the type information. In .NET 6 it did fallback and it was working because of that (and you didn't achieve trim safety as a result).

In .NET 7 now it'll let you know when your type closure is incomplete and needs to be spelling out more (like in this example).

trim safe, that use async serialization behind the scenes.

ASP.NET Core itself isn't trim safe so I'm not sure how much this matters for apps today.

JakeYallop · 2022-09-12T08:01:50Z

One last question. Out of curiosity, what do minimal APIs do differently that means that the above does not repro when using minimal APIs?

davidfowl · 2022-09-12T08:06:52Z

One last question. Out of curiosity, what do minimal APIs do differently that means that the above does not repro when using minimal APIs?

Minimal APIs doesn't use MVC's JSON serializer options. So if you do this:

using System.Text.Json.Serialization;

var builder = WebApplication.CreateBuilder(args);

builder.Services.ConfigureHttpJsonOptions(o =>
{
    o.SerializerOptions.AddContext<JsonContext>();
});

var app = builder.Build();

app.MapGet("/", () =>
{
    var l = new List<MyClass> { new(), new() };
    return Results.Ok(l);
});

app.Run();

[JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase)]
[JsonSerializable(typeof(IEnumerable<MyClass>))]
public partial class JsonContext : JsonSerializerContext
{

}

public class MyClass
{
    public int MyProp { get; set; }
}

It fails.

martincostello · 2022-09-12T08:07:04Z

Minimal APIs needs to be configured with a different mechanism to customise the options compared to MVC.

When updating to preview 7 I had to make the change for concrete types over interfaces as in this commit to get serialisation with Minima APIs working again: martincostello/apple-fitness-workout-mapper@3f13e70

davidfowl · 2022-09-12T08:08:23Z

@halter73 It seems our changes to make JSON writing more polymorphic has broken the source generator really badly 😄. I get an error like this with the above sample:

NotSupportedException: Metadata for type 'System.Object' was not provided by TypeInfoResolver of type 'JsonContext'. If using source generation, ensure that all root types passed to the serializer have been indicated with 'JsonSerializableAttribute', along with any types that might be serialized polymorphically.
System.Text.Json.ThrowHelper.ThrowNotSupportedException_NoMetadataForType(Type type, IJsonTypeInfoResolver resolver)

halter73 · 2022-09-12T19:18:54Z

The problem is that the changes we made to make JSON writing more polymorphic only applied to objects returned via Task or ValueTask. Directly returned values were serialized polymorphically in .NET 6. See #39856

Same goes for already-existing overloads of Results.Ok(), Results.Json(), etc... We had to make the new generic overloads serialize polymorphically as well for compatiblity.

aspnetcore/src/Http/Http.Results/src/HttpResultsHelper.cs

Lines 44 to 47 in 4e0d4c4

    
           return httpContext.Response.WriteAsJsonAsync<object?>( 
        
               value, 
        
               options: jsonSerializerOptions, 
        
               contentType: contentType);

This also goes for TypedResults. Although we could change the behavior of these without breaking existing apps, we didn't want a subtle behavioral difference between Results and TypedResults.

halter73 · 2022-09-12T23:27:48Z

@eiriktsarpalis Do you have any idea why we would have started seeing this between rc1 and rc2?

brunolins16 · 2022-09-13T05:32:15Z

I did an investigation, and it seems to be related to this change dotnet/runtime@f03470b#diff-65021de09c4fb9b39607f1f3ed228e53cd04b483880f66b0ea56310f71a5e400 from July but I can only find in RC2. @eiriktsarpalis @dotnet/area-system-text-json Is this related?

brunolins16 · 2022-09-13T05:34:58Z

Also, I confirmed that we could fix it using the non-generic overload and passing the runtime type directly. @dotnet/area-system-text-json do you have any other suggestions since that is exactly what you were doing before and changed in the commit I mentioned?

eiriktsarpalis · 2022-09-13T14:09:23Z

I did an investigation, and it seems to be related to this change dotnet/runtime@f03470b#diff-65021de09c4fb9b39607f1f3ed228e53cd04b483880f66b0ea56310f71a5e400 from July

Yes, it's related to this intentional breaking change: dotnet/docs#30758

but I can only find in RC2

That change did make it to RC1, perhaps it's not related to the issue at hand?

do you have any other suggestions since that is exactly what you were doing before and changed in the commit I mentioned?

Explicitly passing the runtime type is the suggested workaround for the change. Out of curiosity, are you using a custom JsonConverter<object> implementation?

brunolins16 · 2022-09-13T14:13:44Z

That change did make it to RC1, perhaps it's not related to the issue at hand?

Interesting, maybe the RC1 SDK version installed in my machine is not the official one. I will use an official build to check if the change is already there.

brunolins16 · 2022-09-13T14:18:01Z

Explicitly passing the runtime type is the suggested workaround for the change. Out of curiosity, are you using a custom JsonConverter<object> implementation?

No, but we are calling SerializeAsync<object>() to fix this kind of problem #41724 (comment)

eiriktsarpalis · 2022-09-13T14:26:34Z

Explicitly passing the runtime type is the suggested workaround for the change. Out of curiosity, are you using a custom JsonConverter<object> implementation?

No, but we are calling SerializeAsync<object>() to fix this kind of problem #41724 (comment)

dotnet/docs#30758 should only concern scenaria where a custom JsonConverter<object> is registered, so it's probably unrelated. Could you share a minimal reproduction highlighting the problem?

brunolins16 · 2022-09-13T16:22:30Z

@eiriktsarpalis Here is a minimal repro:

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

var options = new JsonSerializerOptions();
options.AddContext<JsonContext>();

BaseClass obj = new MyClass() {  BaseProperty = 10, MyProp = 1 };
Console.WriteLine(JsonSerializer.Serialize<object>(obj, options));

[JsonSerializable(typeof(MyClass))]
[JsonSerializable(typeof(BaseClass))]
public partial class JsonContext : JsonSerializerContext
{}

public class BaseClass
{
    public int BaseProperty { get; set; }
}

public class MyClass : BaseClass
{
    public int MyProp { get; set; }
}

brunolins16 · 2022-09-13T16:25:11Z

I can fix the issue with:

-Console.WriteLine(JsonSerializer.Serialize<object>(obj, options));
+Console.WriteLine(JsonSerializer.Serialize(obj, obj.GetType(), options));

brunolins16 · 2022-09-13T16:27:41Z

Also, this change will fix as well but cause the serialization issue mentioned here #41724 (comment):

-Console.WriteLine(JsonSerializer.Serialize<object>(obj, options));
+Console.WriteLine(JsonSerializer.Serialize<BaseClass>(obj, options));
// or implict version: +Console.WriteLine(JsonSerializer.Serialize(obj, options));

eiriktsarpalis · 2022-09-13T18:32:13Z

Thanks. I can reproduce the failure in both RC1 and RC2. This is happening because of a combination of dotnet/docs#30755 and dotnet/docs#30758. The contract resolver must access the converter for object to trigger polymorphism but the converter for object is not available because we're not falling back to reflection-based resolution.

A simple workaround would be to add an explicit [JsonSerializable(typeof(object))] annotation on the context type:

var options = new JsonSerializerOptions();
options.AddContext<JsonContext>();

BaseClass obj = new MyClass() { BaseProperty = 10, MyProp = 1 };
Console.WriteLine(JsonSerializer.Serialize<object>(obj, options));

[JsonSerializable(typeof(object))]
[JsonSerializable(typeof(MyClass))]
[JsonSerializable(typeof(BaseClass))]
public partial class JsonContext : JsonSerializerContext
{ }

public class BaseClass
{
    public int BaseProperty { get; set; }
}

public class MyClass : BaseClass
{
    public int MyProp { get; set; }
}

Related to dotnet/runtime#58134. Needing to explicitly specify all runtime types in polymorphic source generated scenaria is a known issue but needing to do it for object itself feels artificial and redundant. We might consider rooting the default JsonConverter<object> in all source generators, but that has obvious cons from a trimability perspective. @layomia @ericstj thoughts?

brunolins16 · 2022-09-13T18:48:22Z

Thanks for the clarification.

A simple workaround would be to add an explicit [JsonSerializable(typeof(object))] annotation on the context type:

Without changes, in aspnetcore

aspnetcore/src/Http/Http.Results/src/HttpResultsHelper.cs

Lines 44 to 47 in 4e0d4c4

    
           return httpContext.Response.WriteAsJsonAsync<object?>( 
        
               value, 
        
               options: jsonSerializerOptions, 
        
               contentType: contentType);

anyone using a JsonSerializerContext with Minimal APIs will need to add it and we are kind of doing this rooting the default JsonConverter<object> in source generators anyway, right?

ghost · 2022-09-14T22:01:10Z

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.

halter73 · 2022-09-15T17:05:05Z

Removing labels so the bot doesn't auto close this again before #43894 is merged.

javiercn added the area-web-frameworks *DEPRECATED* This label is deprecated in favor of the area-mvc and area-minimal labels label Sep 11, 2022

davidfowl added the ✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. label Sep 12, 2022

ghost added the Status: Resolved label Sep 12, 2022

JakeYallop closed this as completed Sep 12, 2022

davidfowl reopened this Sep 12, 2022

eiriktsarpalis mentioned this issue Sep 14, 2022

Implement an AppContext compatibility switch re-enabling reflection fallback in STJ source generators. dotnet/runtime#75615

Merged

brunolins16 mentioned this issue Sep 14, 2022

Changing to use the non-generic WriteAsJsonAsync #43960

Merged

10 tasks

ghost closed this as completed Sep 14, 2022

brunolins16 reopened this Sep 14, 2022

eiriktsarpalis mentioned this issue Sep 15, 2022

Implement an AppContext compatibility switch re-enabling reflection fallback in STJ source generators. dotnet/runtime#75694

Merged

halter73 removed Status: Resolved ✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. labels Sep 15, 2022

rafikiassumani-msft assigned brunolins16 Sep 15, 2022

rafikiassumani-msft added this to the 7.0-rc2 milestone Sep 15, 2022

brunolins16 linked a pull request Sep 15, 2022 that will close this issue

Changing to use the non-generic WriteAsJsonAsync #43960

Merged

10 tasks

brunolins16 closed this as completed Sep 16, 2022

brunolins16 mentioned this issue Sep 16, 2022

[Breaking change]: Using the System.Text.Json source generator with ASP. NET Core throws NotSupportedException in RC1 *only* aspnet/Announcements#494

Open

3 tasks

danroth27 added the bug This issue describes a behavior which is not expected - a bug. label Oct 7, 2022

ghost locked as resolved and limited conversation to collaborators Nov 7, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Using the System.Text.Json source generator with ASP NET Core throws NotSupportedException when attempting to serialize IEnumerable<T> #43894

Using the System.Text.Json source generator with ASP NET Core throws NotSupportedException when attempting to serialize IEnumerable<T> #43894

JakeYallop commented Sep 9, 2022 •

edited

Loading

martincostello commented Sep 10, 2022

JakeYallop commented Sep 10, 2022

JakeYallop commented Sep 10, 2022

davidfowl commented Sep 12, 2022 •

edited

Loading

JakeYallop commented Sep 12, 2022

davidfowl commented Sep 12, 2022

JakeYallop commented Sep 12, 2022 •

edited

Loading

davidfowl commented Sep 12, 2022

JakeYallop commented Sep 12, 2022

davidfowl commented Sep 12, 2022

martincostello commented Sep 12, 2022

davidfowl commented Sep 12, 2022

halter73 commented Sep 12, 2022

halter73 commented Sep 12, 2022

brunolins16 commented Sep 13, 2022

brunolins16 commented Sep 13, 2022

eiriktsarpalis commented Sep 13, 2022 •

edited

Loading

brunolins16 commented Sep 13, 2022

brunolins16 commented Sep 13, 2022

eiriktsarpalis commented Sep 13, 2022 •

edited

Loading

brunolins16 commented Sep 13, 2022 •

edited

Loading

brunolins16 commented Sep 13, 2022 •

edited

Loading

brunolins16 commented Sep 13, 2022

eiriktsarpalis commented Sep 13, 2022

brunolins16 commented Sep 13, 2022 •

edited

Loading

ghost commented Sep 14, 2022

halter73 commented Sep 15, 2022

Using the System.Text.Json source generator with ASP NET Core throws NotSupportedException when attempting to serialize IEnumerable<T> #43894

Using the System.Text.Json source generator with ASP NET Core throws NotSupportedException when attempting to serialize IEnumerable<T> #43894

Comments

JakeYallop commented Sep 9, 2022 • edited Loading

Is there an existing issue for this?

Describe the bug

Expected Behavior

Steps To Reproduce

Exceptions (if any)

.NET Version

Anything else?

martincostello commented Sep 10, 2022

JakeYallop commented Sep 10, 2022

JakeYallop commented Sep 10, 2022

davidfowl commented Sep 12, 2022 • edited Loading

JakeYallop commented Sep 12, 2022

davidfowl commented Sep 12, 2022

JakeYallop commented Sep 12, 2022 • edited Loading

davidfowl commented Sep 12, 2022

JakeYallop commented Sep 12, 2022

davidfowl commented Sep 12, 2022

martincostello commented Sep 12, 2022

davidfowl commented Sep 12, 2022

halter73 commented Sep 12, 2022

halter73 commented Sep 12, 2022

brunolins16 commented Sep 13, 2022

brunolins16 commented Sep 13, 2022

eiriktsarpalis commented Sep 13, 2022 • edited Loading

brunolins16 commented Sep 13, 2022

brunolins16 commented Sep 13, 2022

eiriktsarpalis commented Sep 13, 2022 • edited Loading

brunolins16 commented Sep 13, 2022 • edited Loading

brunolins16 commented Sep 13, 2022 • edited Loading

brunolins16 commented Sep 13, 2022

eiriktsarpalis commented Sep 13, 2022

brunolins16 commented Sep 13, 2022 • edited Loading

ghost commented Sep 14, 2022

halter73 commented Sep 15, 2022

JakeYallop commented Sep 9, 2022 •

edited

Loading

davidfowl commented Sep 12, 2022 •

edited

Loading

JakeYallop commented Sep 12, 2022 •

edited

Loading

eiriktsarpalis commented Sep 13, 2022 •

edited

Loading

eiriktsarpalis commented Sep 13, 2022 •

edited

Loading

brunolins16 commented Sep 13, 2022 •

edited

Loading

brunolins16 commented Sep 13, 2022 •

edited

Loading

brunolins16 commented Sep 13, 2022 •

edited

Loading