Hi @vasudeva_shenoy, do you know whether your customer is using the latest version of the 2.x branch of swagger-codegen or the latest version of the 3.x branch of swagger-codegen?
Right now the latest versions are 2.4.5 and 3.0.8 (see here), but csharp support in 3.0.8 is listed as “experimental”. And as far as I’m aware, we haven’t verified whether our Swagger spec is compatible with the 3.x branch of swagger-codegen.
Assuming your customer isn’t wanting to use the 3.x branch of swagger-codegen, I’ve got a couple of suggestions for your customer:
There is a known bug in version 2.3.0 and later of swagger-codegen that affects ZObject (see here). Would it be possible to use an earlier version of swagger-codegen?
If you can use an earlier version than 2.3.0 - You should set type: object within additionalProperties as explained earlier in this thread. This will ensure that the ZObject class extends Dictionary<String, Object> in ZObject.cs:
public partial class ZObject : Dictionary<String, Object>, IEquatable<ZObject>, IValidatableObject
Otherwise, ZObject won’t extend Dictionary correctly:
public partial class ZObject : Dictionary<String, >, IEquatable<ZObject>, IValidatableObject
Per my previous post in this thread, you can grab a Swagger spec that already includes the workaround from https://assets.zuora.com/zuora-documentation/swagger-codegen-workaround.yaml. Update 5 May, 2019: We plan to provide this Swagger spec until June 2019.
If you can’t use an earlier version than 2.3.0 - additionalProperties will cause compilation errors, so you’ll need to remove additionalProperties . You could replace additionalProperties by all the properties that you anticipate needing to reference in the ZObject class. For example, if you’re going to use Query to always query fields called Name and Status , you could modify the Swagger spec to look like this:
zObject:
type: object
properties:
Name:
type: string
Status:
type: string
This workaround is not ideal from a flexibility point of view, but it could be your best option.
As an alternative suggestion, I am aware of a fork of swagger-codegen 2.x called openapi-generator. I don’t know what the results are like, but would be interested to know whether it improves upon swagger-codegen in terms of compatbility with our Swagger spec.
Would any of these suggestions help you to make progress?
... View more