Epic: Support System.Text.Json

[RicoSuter]

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

• NJsonSchema
  • 90%: https://github.com/RicoSuter/NJsonSchema/issues/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: https://github.com/RicoSuter/NJsonSchema/issues/1014

Out of scope:

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

Tasks:

• [ ] Document new property SerializerOptions

[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 https://github.com/RicoSuter/NSwag/issues/1052 is regressed in System.Text.Json. It doesn't respect Runtime.Serialization.EnumMember attribute

EDIT: Workaround here: https://github.com/dotnet/runtime/issues/74385#issuecomment-1456725149

[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?