Epic: Support System.Text.Json

[RicoSuter]

A: Use System.Text.Json in generated C# models (DTOs):

• NJsonSchema
  • 90%: Use System.Text.Json in generated C# models (DTOs) NJsonSchema#1013
• NSwag
  • DONE: Use System.Text.Json serializer in ReadObjectResponseAsync (client generator)

B: Use System.Text.Json in JSON Schema generator (also used to generate OpenAPI model schemas):

• NJsonSchema
  • DONE: Use System.Text.Json in JSON Schema generator NJsonSchema#1014

Out of scope:

• Use System.Text.Json to serialize schemas, documents, etc.

Tasks:

• Document new property SerializerOptions

[JoFrMueller]

We're currently moving internal libraries towards System.Text.Json and wonder what the plans for NSwag are regarding migration?

Dazinator makes 2316 sound like you would loose interoperability by not being able to use data contracts anymore. Could you perhaps comment on this and your planned schedule regarding System.Text.Json? Thanks a lot!

[RicoSuter]

Do you need A or B?

[JoFrMueller]

We don't care about data contracts currently. So:

• A: System.Text.Json <-- Waiting impatiently.
• B: DataContract <-- More interesting from an academic/wider point of view...

[skorunka]

Hello, how does it look with A?

[RicoSuter]

No work done yet, but A is the one which is feasible to implement already. B is not possible because no metadata is exposed.

[8VAid8]

@RicoSuter Do you have any progress with A? I've checked a client behavior with replaced Newtonsoft by System.Text.Json. It works.

[stefanluchian]

I can hardly wait to use the asynchronous deserialization (DeserializeAsync) from System.Text.Json.
It would be very handy to be able to choose between Newtonsoft and System.Text.Json for the generation of C# client.

[Jacko1394]

I'd also love to see optional support for System.Text.Json :D

[dubtar]

While this is in progress, is there a workaround to serialize enums as string? In my .net core 3.1 project with nswag.aspnetcore 13.4.2 it does not recognize services.AddJsonOptions(c=>c.JsonSerializerOptions.Converters.Add(new JsonStringEnumConverter()))) and adding services.AddOpenApiDocument(c => c.DefaultEnumHandling = NJsonSchema.Generation.EnumHandling.String); break data class fields casing: id becomes Id.

[jnovick]

Any update on this?

[8VAid8]

I didn't want to wait and just made a simple Newtonsoft -> System.Text.Json converter (it has planty bugs, i guess, but works for me) for my Blazor project. @Jacko1394 you can try this way while the feature implementation is in progress.

[RicoSuter]

@8VAid8 Thanks for sharing your solution - we should support that out-of-the-box as a "generator template style", this is tracked mainly here:

RicoSuter/NJsonSchema#1013

[RicoSuter]

@dubtar @jnovick System.Text.Json support in the schema generator has been greatly improved, see RicoSuter/NJsonSchema#1014 (NSwag v13.5.0)

[dubtar]

Yep, thanks a ton! 13.5.0 resolved my issues - now typescript clients work for me with enums as string.

[electricessence]

You could simply inject the serializer agnostically:
https://www.nuget.org/packages/Open.Serialization.Json/

[SommerEngineering]

Thanks alot @RicoSuter 🙂 It works now out-of-the-box within my blazor wasm client.

[loganmarshall1]

Thanks alot @RicoSuter 🙂 It works now out-of-the-box within my blazor wasm client.

Hi there my friend! was wonder if you'd please share your steps to generate a c# open api NSwag client for blazor wasm? My understanding this that Newtonsoft.Json isn't supported on blazor wasm, would love to get your guidance on what worked best for you in your success story.

Thanks for you time, please let me know 👍

[loganmarshall1]

Hi @RicoSuter

Hope you're having a good day.

I appreciate all the help all your tools and code do with the community. I've used nswag studio on 6 of my projects over the past several years and they do make life better and easier. 👍

Wondering if System.Text.Json will be supported this year? I'm currently hand writing the c# client because blazor wasm doesn't support Newtonsoft. I'm on the fence right now of switching to GRPC for API Layer, with one of the many reasons being the client generation works with blazor wasm. https://blog.stevensanderson.com/2020/01/15/2020-01-15-grpc-web-in-blazor-webassembly/

Please let me know, thanks again!

[jeremyVignelles]

Implementing STJ has a lot of implications for NSwag and for the generated code (things that don't deserialize the same way...). Given the task of implementing that in NJsonSchema and NSwag, and checking that nothing breaks, I wouldn't be surprised if it took some time to be implemented.

On my side, I'm planning to create a new C# code generator built for the modern C#, and see how things goes. This would be a separate project.

[Jacko1394]

Is Newtonsoft not supported on Blazor Wasm? Because it's worked fine in my project.
I used this NSwag C# client generator to build a typed client (referencing Newtonsoft) and it worked in my blazorwasm app for months no issues.

The desire for System.Text.Json support was more one of preference; it's Microsoft supported and more performant, also with a much smaller dll than Newtonsoft, which is important for web load times.

I've since migrated my project to use gRPC as others have suggested and I would strongly recommend this myself.
gRPC has smaller payloads (binary) and also de/serializes faster as well.

Marc Gravell has fantastic gRPC libraries that allow for code-first C# approach to gRPC, there's no need to even understand .proto file definitions.

[loganmarshall1]

Very helpful thanks! Standalone blazor wasm project or dotnet core hosted blazor wasm project? Mine is Standalone. If you try to add newtonsoft as a reference to it, errors. Please let me know your setup so I can learn if you've got it working that's fantastic! Thanks in advance, Logan Marshall, MCP, MCSA, MCITP, MCTS, SA Scrum Agile Certified On Jan 4, 2021, at 8:28 PM, Jack Della <notifications@github.com> wrote:  Is Newtonsoft not supported on Blazor Wasm? Because it's worked fine in my project. I used this NSwag C# client generator to build a typed client (referencing Newtonsoft) and it worked in my blazorwasm app for months no issues. The desire for System.Text.Json support was more one of preference; it's Microsoft supported and more performant, also with a much smaller dll than Newtonsoft, which is important for web load times. I've since migrated my project to use gRPC as others have suggested and I would strongly recommend this myself. gRPC has smaller payloads (binary) and also de/serializes faster as well. Marc Gravell has fantastic gRPC libraries that allow for code-first C# approach to gRPC, there's no need to even understand .proto file definitions. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2FRicoSuter%2FNSwag%2Fissues%2F2243%23issuecomment-754326666&data=04%7C01%7C%7Cb74085fdaf1549eec2c208d8b1192495%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637454068827579979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Lq%2BW5Ze51BlEWggPAPAIozzWzR1%2BeCG%2Fmi7hcJGDCg4%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fnotifications%2Funsubscribe-auth%2FAEYSEOC44MRQIXBNUGDYAYLSYJTKDANCNFSM4HYP45LQ&data=04%7C01%7C%7Cb74085fdaf1549eec2c208d8b1192495%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637454068827589941%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kJVKBEz5SsbJwrbu%2FK9hWFalO8maKlvuGynNbOnn%2FRY%3D&reserved=0>.

[thebynggroup]

Hi Everyone, Does anyone know if there's a open api c# client generator that has no Newtonsoft dependancy? meaning it uses System.Text.Json?

[RicoSuter]

the default JsonSerializerOptions are very strict and won't work in all cases

Because the openapi spec clearly defines how json is serialized/deserialized ideally you should not even be able to change it as it would mean the code gen is buggy - but i know that there are sometimes changes needed, eg if even the spec is wrong

[crobibero]

I 100% agree- but Newtonsoft.Json was very flexible and not everything that it supported is currently / will be supported with System.Text.Json. One big example is displaying enums. In order to return them as a string instead of their int representation we need to add the JsonStringEnumConverter to the converters list

[RicoSuter]

In order to return them as a string instead of their int representation we need to add the JsonStringEnumConverter to the converters list

this is already automatically generated - as the spec would not comply with the spec otherwise

[crobibero]

Sorry, I forgot how we generate the client. Now that I've looked again I can see that all I had to do was add the converts to the nswag.json. If we could keep that option the converter will work great for my use.

Specifically- we need to send Guids without dashes for legacy purposes, but System.Text.Json only supports the "proper" Guid format.

[aureole82]

Could somebody tell me what's the progress of DateTime/DateTimeOffset within generated models like this:

[System.CodeDom.Compiler.GeneratedCode("NJsonSchema", "10.4.4.0 (Newtonsoft.Json v11.0.0.0)")]
public partial class ContactRequest 
{
    /// <summary>Date of birth of the contact person, e.g. "1999-12-31".</summary>
    [System.Text.Json.Serialization.JsonPropertyName("birthday")]
    [System.ComponentModel.DataAnnotations.Required(AllowEmptyStrings = true)]
    [System.Text.Json.Serialization.JsonConverter(typeof(DateFormatConverter))]
    public System.DateTimeOffset Birthday { get; set; }
...
}

[System.CodeDom.Compiler.GeneratedCode("NJsonSchema", "13.11.2.0 (NJsonSchema v10.4.4.0 (Newtonsoft.Json v11.0.0.0))")]
internal class DateFormatConverter : Newtonsoft.Json.Converters.IsoDateTimeConverter
{
    public DateFormatConverter()
    {
        DateTimeFormat = "yyyy-MM-dd";
    }
}

[gregsdennis]

@RicoSuter, I realize that you have NJsonSchema, and that it's currently being updated, but I'd like to offer my library JsonSchema.Net (Nuget | Github | Docs) as a replacement JSON Schema provider.

It was built ground-up on top of System.Text.Json and it has fully supported draft 2020-12 (the latest) since the spec was released, including the $dynamicRef / $dynamicAnchor keywords as well as vocabularies. (Being part of the JSON Schema team gives me a jump on updating my library.) If you'd like, you can test it at https://json-everything.net/.

Using my library provides other benefits as well:

• My focus being on JSON Schema means that you could concentrate your efforts on the OpenAPI/Swagger needs.
• My users could easily use NSwag, and your users get the latest validation logic as well as System.Test.Json support.
• Draft 2020-12 was developed in close cooperation with the OpenAPI spec maintainers for v3.1. Using my validator will make updating this library easier.

(I wish I had found this issue sooner, but I thought I'd open the discussion anyway.)

[loganmarshall1]

Hi Everyone! I would love to ONLY use System.Text.Json instead of newtonsoft on my blazor wasm standalone pwa apps.

The only reason I have to have newtonsoft as a nuget dependacy is because I love NSwag studio api client generator so much! 

would love to get this pushed out by end of year! please let me know if I can help with any pull requests?! 🙏❤️

[loganmarshall1]

Hi @RicoSuter looking very forward to this update and your support!

[RicoSuter]

but I'd like to offer my library JsonSchema.Net (Nuget | Github | Docs) as a replacement JSON Schema provider.

That's not really an option as it would essentially be a rewrite - NSwag and NJsonSchema are more or less one project...

Hi Everyone! I would love to ONLY use System.Text.Json instead of newtonsoft on my blazor wasm standalone pwa apps.

Why are you referencing NSwag in the wasm frontend app? NSwag is usually only needed in the backend to generate the spec, in the frontend you consume the generated client code which has no direct dependency on NSwag/NJS/Newtonsoft.

NSwag/NJsonSchema supports System.Text.Json, it just uses Newtonsoft to serialize/deserialize schemas... this is more or less an "implementation detail" that's why this was not high on the prio list (ie you only have the "bad" dependency).

It would be nice to migrate to STJ but this is quite some work.

[Trapulo]

It is required if you may fix some troubles with some kind of serialize/deserialize using converters. Eg. polymorphism or special types as IPAddress.

[RicoSuter]

Polymorphism should also be supported when using STJ output, no?

I'd say IPAddress is not supported by JSON Schema and you should just use type "string" for that...

[loganmarshall1]

but I'd like to offer my library JsonSchema.Net (Nuget | Github | Docs) as a replacement JSON Schema provider.

That's not really an option as it would essentially be a rewrite - NSwag and NJsonSchema are more or less one project...

Hi Everyone! I would love to ONLY use System.Text.Json instead of newtonsoft on my blazor wasm standalone pwa apps.

Why are you referencing NSwag in the wasm frontend app? NSwag is usually only needed in the backend to generate the spec, in the frontend you consume the generated client code which has no direct dependency on NSwag/NJS/Newtonsoft.

NSwag/NJsonSchema supports System.Text.Json, it just uses Newtonsoft to serialize/deserialize schemas... this is more or less an "implementation detail" that's why this was not high on the prio list (ie you only have the "bad" dependency).

It would be nice to migrate to STJ but this is quite some work.

Hi Rico,

I'm using NSwag to generate an api client that the front end consumes In order to call the api.

Please Let me know if that make sense for the answer to your question.

[loganmarshall1]

but I'd like to offer my library JsonSchema.Net (Nuget | Github | Docs) as a replacement JSON Schema provider.

That's not really an option as it would essentially be a rewrite - NSwag and NJsonSchema are more or less one project...

Hi Everyone! I would love to ONLY use System.Text.Json instead of newtonsoft on my blazor wasm standalone pwa apps.

Why are you referencing NSwag in the wasm frontend app? NSwag is usually only needed in the backend to generate the spec, in the frontend you consume the generated client code which has no direct dependency on NSwag/NJS/Newtonsoft.

NSwag/NJsonSchema supports System.Text.Json, it just uses Newtonsoft to serialize/deserialize schemas... this is more or less an "implementation detail" that's why this was not high on the prio list (ie you only have the "bad" dependency).

It would be nice to migrate to STJ but this is quite some work.

Hi Rico,

The front end generated client has a dependency on newtonsoft json.

can you please confirm if there's an option to not use this on the generated C# client?

[RicoSuter]

?

[loganmarshall1]

?

Perfect thanks. I'll give it a shot!

I knew about we had Support to generate DTO's with STJ. I haven't seen this other option yet.

It's almost like when the Nswag program opens after a version update it should provide a pop up of what's new. Love this.

This is great is this new did it come out recently?

[smokedlinq]

It looks like NJsonSchema is using the right kind of template to generate this converter but it doesn't appear the nswag library is using this version, or maybe there is a bug in NJsonSchema with this template ...

https://github.com/RicoSuter/NJsonSchema/blob/master/src/NJsonSchema.CodeGeneration.CSharp/Templates/DateFormatConverter.liquid

[AHelper]

I'm seeing the same thing for JsonInheritanceConverter. The Newtonsoft version is being emitted, not the System.Text.Json one. The rest of the file uses the correct types.

[loganmarshall1]

?

Thanks @RicoSuter This works perfectly when you select the generate DTO option. However in my case the DTO and are in a shared class library that both my front end and api projects reference therefore I can’t use this option. Thanks!

[DominikPf]

@loganmarshall1 You can enable the DTO option. Switch to System.Text.Json and then disable the DTO option again. This worked for us.

@RicoSuter The Json Library option should maybe be moved outside of the DTO options.

[loganmarshall1]

@loganmarshall1 You can enable the DTO option. Switch to System.Text.Json and then disable the DTO option again. This worked for us.

@RicoSuter The Json Library option should maybe be moved outside of the DTO options.

Wow perfect! Thank you so much!

[jochenjonc]

I'm seeing the same thing for JsonInheritanceConverter. The Newtonsoft version is being emitted, not the System.Text.Json one. The rest of the file uses the correct types.

I have the same issue that the wrong JsonInheritanceConverter is injected in the generated contracts. Somehow this line results in false.
When I manually replace the Newtonsoft version of the JsonInheritanceConverter with the System.Text.Json version it works.

[n1l]

Hi! What is the status of the epic? Is there anything I can help?

[ghost]

Hey Guys!
This is still happening. I'm using the package NSwag.ApiDescription.Client v13.10.7.
Is there a newer version that fixes this problem?

Hi, @frosadev

I fixed it in #3338 Just need to release it.

I'm getting the inverse of this trying to use SystemTexstJson on the latest v13.15.10.

[JustinGrote]

It looks like #1052 is regressed in System.Text.Json. It doesn't respect Runtime.Serialization.EnumMember attribute

EDIT: Workaround here: dotnet/runtime#74385 (comment)

[ThaDaVos]

Any update on this? Currently working on a C# library which will be consumed by a Clarion Application and rather use System.Text.Json over NewtonSoft.Json due to it's size and improved performance

[yori-s]

@JustinGrote - ran into same STJ limitation on customizing enums as strings

It wasn't sufficient for me to provide a custom converter to a generated client's JsonSerializerSettings, but also had to remove the explicit converter annotation in generated enum properties:
https://github.com/RicoSuter/NJsonSchema/blob/94647c590b3c6cbc3d09569b027ee7cd77c20463/src/NJsonSchema.CodeGeneration.CSharp/Templates/Class.liquid#L83-L85

[PolarbearDK]

May I suggest a small fix in the generated code

You get compile errors when you consume a service that has a field called "System".

It will generate the following code:

[System.Text.Json.Serialization.JsonPropertyName("system")]
[System.Text.Json.Serialization.JsonIgnore(Condition = System.Text.Json.Serialization.JsonIgnoreCondition.Never)]   
public OpenMessageSystem System { get; set; }

And you get compile error:
CS0120: An object reference is required for the non-static field, method, or property 'CloseMessage.System'

It will work if you prefix System.Text Namespace with "global::":

[System.Text.Json.Serialization.JsonPropertyName("system")]
[System.Text.Json.Serialization.JsonIgnore(Condition = global::System.Text.Json.Serialization.JsonIgnoreCondition.Never)]   
public OpenMessageSystem System { get; set; }

I guess this you will get the same error with Newtonsoft.Json if you consume a service with a "Newtonsoft" property?

[albertocorrales]

This feature would be awesome since dotnet is doing a great job to improve the performance of System.Text.Json. Are there any ETAs about when System.Text.Json could be supported by NSwag?