Nswag: Question: How to [JsonIgnore] properties for some clients and not for others?

[jtheisen]

I have a big model assembly where ultimately all model classes depend on all others: It's a entity graph with the edges being navigational properties.

There are multiple web applications compiling against it, many of which have an API using some of those model classes and Nswag generated TypeScript clients.

Usually the clients don't need all of the model, but they'll get all of the model as Nswag is recursively finding them all.

There's [JsonIgnore], but sometimes one client needs a property or class and the other doesn't.

Is there a way to ignore properties that doesn't depend on attributes?

[RicoSuter]

NSwag will generate all necessary schemas and properties with the operations being the entry points that cannot be changes...

So you want to dynamically ignore/show properties per API endpoint?

[RicoSuter]

Maybe this might help here: https://blog.rsuter.com//advanced-newtonsoft-json-dynamically-rename-or-ignore-properties-without-changing-the-serialized-class/

[jtheisen]

I'm only talking about client code generation. The linked material is about how to get Json.NET to ignore properties, but I want Nswag to ignore properties when generating the client (which it does if [JsonIgnore] is on one) - but without having this to be the same properties for different generated clients.

At runtime, those properties are all always null for the clients I want to exclude them for.

[RicoSuter]

Then I think you need to transform the spec for each client gen run with something like this:
https://github.com/Picturepark/Picturepark.SDK.Playground/blob/master/src/AutoRestTransformer/Program.cs

[jtheisen]

Ok, fair enough. Thanks for your time!

[jtheisen]

@RicoSuter I had a closer look and I'm able to chose which properties to include with a custom IContractResolver. It also makes nswag drop all the types that can't be reached any longer due to some omitted properties.

Is something making this a bad idea?

[RicoSuter]

In general this should work as long as each type is static (i.e. they are not different for read/write and depending on where they are used).

[jtheisen]

For the record, your design decision to use IContractResolver is fantastic.

It's awesome because I can control client generation and serialization with the same code!

Really super-flexible.