-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
[BUG][CSHARP] DeserializeObject putting everything in inherited Dictionary #16767
Comments
The generichost library had a sample called something like manualtest which verifies round trip de/serialization, so yes it works. It covers inheritance too, but maybe not inheriting a dictionary. Though im not sure what would be expected with a dictionary of objects. |
This does seem like a blocker for any C# usage. I agree that inheriting from a Directory is unnecessary, especially at the cost of breaking the serialization of normal objects. However, I was unable to locate where this inheritance is implemented in the code. |
This spec is causing an error: Seems to be coming from dozens of string properties which also have their own properties such as this status property I ran the spec through a validator and it says it is good, but this library seems to disagree. @wing328 Can you clear this up? |
I believe that the issue identified by @devhl-labs is distinct from the one I've encountered. To address my specific issue, I created a custom version of the Plaid specification where I modified all instances of I'm curious about the reasoning behind inheriting from public class MyModel : Dictionary<string, object>
{
public string LinkToken { get; set; }
public IDictionary<string, object> AdditionalProperties { get; set; }
public new object this[string key]
{
get
{
if (key == nameof(LinkToken))
{
return LinkToken;
}
return AdditionalProperties[key];
}
set
{
if (key == nameof(LinkToken))
{
LinkToken = value as string;
}
AdditionalProperties.Add(key, value);
}
}
} Alternatively, a cleaner approach might be to implement the |
Interesting, we see this in the samples too. Zebra only inherits dictionary with additionalProperties enabled. I don't think it is supposed to. The additionalProperties should just go in here instead of inheriting dictionary. @wing328 Is this intended? Do I need to patch it in the abstract csharp? Seems like this must be a bug in the default generator, because how could it inherit correctly if additionalProperties forces it to inherit dictionary? C# does not have multinheritence so that can't work. |
Bug Report Checklist
Description
I am using the openAPI-generator to generate a Client. I am using the
httpclient
, but i have notice the same problemrestsharp
andgenerichost
.When the API serialized the response it get back, it adds all of the value to the inhered dictionary instead of the correct properties. I have written a unit test below that the reproduce the problem.
openapi-generator version
7.0.1, don't know first time using it
OpenAPI declaration file content or url
https://raw.githubusercontent.com/plaid/plaid-openapi/master/2020-09-14.yml
Steps to reproduce
See unit test below
Related issues/PRs
Could not find any mentions of this
Suggest a fix
If inheritance of
Dictionary<string, object>
and thethis.AdditionalProperties
is remove the object is serilized correctly. However i can not find a way to do this via the settings even though there is aisAdditionalPropertiesTrue
in the mustache template.Test to reproduce
The Deserialize code is lifted from the generated code, to test it in isolation
The model generated:
Upon investigation, it appears that if an object is of type Dictionary, both
Newtonsoft.Json
andSystem.Text.Json
will treat the object solely as a Dictionary, disregarding any other properties on the object. Moreover, the test suite seems to lack any tests that verify whether a JSON string can actually be deserialized. This raises the question: has the C# code generation ever been functional?The text was updated successfully, but these errors were encountered: