New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for .Net Core 3 Json library #1347
Comments
Love this idea! We would be happy to guide someone in contributing this as an option to the existing C# language support. |
any news about supporting System.Text.Json? |
@dvdsgl ... I (potentially) volunteer as tribute! Can you share any contribution guidelines/tips/insight? I'm in that brief window of time where I'm trying to decide if it would be easier to just change the generated code, or contribute this change to pay it forward :P |
@joelmartinez do it! I'll help you if you get stuck. Should not be too bad. See how we support many different serialization frameworks in Kotlin. Just make it an option, then we'll create some high-level helpers that emit the right code depending on which framework you're using. |
Can't wait for this!! 👍 |
@joelmartinez Do you have any progress on this issue? |
Unfortunately, my "brief window of time" ended up going in another direction ... I never got quite deep enough into implementation territory here. So the task is still open for anyone else that wants a crack. |
Any news? |
I got quicktype running with the code from the PR, seems to work fine as is for at least my needs. Is there any progress as to getting this included? |
@bzuidgeest You might consider use my version of quicktype. Source: https://github.com/doggy8088/quicktype/tree/CSharp-SystemTextJson npm: @willh/quicktype |
I already made a version for myself based on your code. much nicer output then njsonschema. I got it compiling and working on linux on an old laptop. But I can't seem to get it to compile on windows and that is where I need it. All kinds of weird errors with packages an dependencies. I develop in c#, nodejs and npm are alien to me. Though i could read and modify the typescript code. Its close to javascript en very readable. I do wonder why you create a converter for enum?. .net 5 and 6 both have the build in stringenumconverter. |
It because |
That much was obvious. But not very helpfull. I do know it has an "issue" arround nullable enums, but personally I find enums should not be nullable, if you don't know the value a "unknown" option should be added to the enum. But opinions like that are personal and I cannot expect everyone to share them. Was this your "circumstance"? |
@bzuidgeest I took some time to remember what's my circumstance. 😅 I have a json like this. [
{
"name": "Will",
"department": "CorpA.General",
"age": "18"
},
{
"name": "Mary",
"department": "CorpB.Finance",
"age": "19"
}
] The Here is my sample code that can run under LINQPad 7. void Main()
{
var serializerOptions = new JsonSerializerOptions
{
Converters = {
DepartmentConverter.Singleton
},
NumberHandling = JsonNumberHandling.AllowReadingFromString,
WriteIndented = true
};
var jsonPath = Util.CurrentQueryPath.Replace(".linq", ".sample.json");
var jsonText = File.ReadAllText(jsonPath);
var user = JsonSerializer.Deserialize<UserProfile[]>(jsonText, serializerOptions);
user.Dump();
string json = JsonSerializer.Serialize(user, serializerOptions);
json.Dump();
}
public class UserProfile
{
[JsonPropertyName("name")]
public string Name { get; set; }
[JsonPropertyName("department")]
public Department Department { get; set; }
[JsonPropertyName("age")]
public int Age { get; set; }
}
public enum Department
{
CorpA_General,
CorpB_Finance
};
public class DepartmentConverter : JsonConverter<Department>
{
public override bool CanConvert(Type t) => t == typeof(Department);
public override Department Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
{
var value = reader.GetString();
switch (value)
{
case "CorpA.General":
return Department.CorpA_General;
case "CorpB.Finance":
return Department.CorpB_Finance;
}
throw new Exception("Cannot unmarshal type Department");
}
public override void Write(Utf8JsonWriter writer, Department value, JsonSerializerOptions options)
{
switch (value)
{
case Department.CorpA_General:
JsonSerializer.Serialize(writer, "CorpA.General");
return;
case Department.CorpB_Finance:
JsonSerializer.Serialize(writer, "CorpB.Finance");
return;
}
throw new Exception("Cannot marshal type Department");
}
public static readonly DepartmentConverter Singleton = new DepartmentConverter();
} As this doc The Support enum string value deserialization:
My custom converter support every circumstances and make sure |
Would be amazing to have this option built in to replace Json.NET. |
@doggy8088 That seems like an excellent reason for doing it the way you did. The use case is rather specifc however (I think) and I don't know if it would hold up in a general use tool. What if the next person would use a different seperator and a different way of correcting it in the conversion. For example what if the replaced the dot in the enum by removing it al together? You would have to define a lot of use cases. But thanks for explaining, that is very usefull. |
@dylanvdmerwe Replace is a bad option. A lot of people have invested in the code as-is and rely on it. Also JSON.net is far from dead. It might fade eventually, but for now its still heavily used and has unique features that are not in System.Text.Json and might never be available there. Personally I am a proponent of what @dvdsgl suggested. The Kotlin generator has an option to choose the framework to be used. We should have that for C# to. I looked into the code files and we could copy the way kotlin does it and then cobine @doggy8088 repo his generator code with the existing generator code. Some name clashes would need to be fixed, but it should not be to difficult. Basically two generators and a choice between the two. |
@bzuidgeest agreed my apologies I meant that having the option to select which generator to use would be incredible. |
I took the code from the repo of @doggy8088 and merged it with the current version of quicktype using the kotlin generator as an example of how to implement selecting between frameworks. Just like @dvdsgl sugested
code is here: |
So I committed number of changes and as far as I can determine most tests run fine. Even some that are excluded with newtonsoft lib because of framework issues. Seems reasonable to me. Lets hope someone actually want to take a look at the PR |
Why is this not a thing yet? .net 6 does not even have newtonsoft |
That is nonsense, Newtonsoft Json.net library always has been a sperate lib and is very much supported on .NET6. Just as normal with the nuget package. The fact that Microsoft included it (the nuget) by default in some templates has no bearing on that. With the latest .net you are free to choose between the system.text.json and newtonsoft libs. That said, this project seems to be "on hold" as in the discussions you can read the maintainers do not have the time to maintain it. Wish I new that before I create my branch and PR. |
…1347 (#1997) * Started modifying Charp.ts to have multiple framework support. Using kotlin as example. * First version with new framework option is building * Adjusted index.ts and removed some rundundant targetlanguage definitions * Made some changes to get the charp language test to work. basically defaulting to newtonsoft as the test docker use a version of .net core that is to low. * small fixes to render code to make tests compile * Added .net6 sdk and fixed the test commands * fix to remove warnings from console to be able to run tests. * Most test work, 18 still to check and possibly fix. * fixed code for test bug863.json. Missing options parameter on deserialisation * fix all test with datetimeoffset parsing errors and 29f47 * in some test String.IsNullOrEmpty is not accepted but string.IsNullOrEmpty is. * all basic tests seem to run. Changed to general defaults for the serializer. * Add csharp-SystemTextJson fixture * Small C# fixes * Bump versions Co-authored-by: Bart Zuidgeest <bzuidgeest@outlook.com> Co-authored-by: David Siegel <dvdsgl@users.noreply.github.com> Co-authored-by: David Siegel <djsiegel@gmail.com>
Fixed in #1997 |
.Net Core 3 comes with its own set of classes to serialise and deserialise JSON, located in the
System.Text.Json
andSystem.Text.Json.Serialization
.Previous versions used to rely on
Newtonsoft.Json
andNewtonsoft.Json.Converters
instead.This also means some attribute names need to be adapted:
becomes
Serialisation of enums to string can be done this way
but cannot be done by involving
JsonReader
andJsonWriter
like it was in previous versions.It would be nice to be able to choose between Newtonsoft.Json and System.Text.Json when using quicktype to create classes from Json.
Here is a good starting place to understand the changes I am refering to:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#fast-built-in-json-support
Cheers!
The text was updated successfully, but these errors were encountered: