JsonProperty equivalent?

[netclectic]

Hello, is there any equivalent way to specify property name mappings in an agnostic manner rather than using the JsonProperty/JsonPropertyName attributes?

[electricessence]

It might be possible but I'm not sure how.
Right now, the only way I've seen this done is to include multiple attributes from different libs. I know, it's terrible.
This is because each lib is looking for it's own attributes. :(
Most of the time, this is dodged by simply maintaining a standard that doesn't require the attributes.

I think it may be possible however to configure a serializer at startup to have a special handler.
Again, maybe possible...

[netclectic]

Thanks for the reply.

The incoming json is not under my control, so standard naming that doesn't require the attributes is a non-starter :-(

I looked into custom resolvers, which you can now (kind of) do in System.Text.Json as of .Net 7, but it seems they didn't got as far as allowing you to change the property names, which seems like a bit of an oversight.

I'm thinking the cleanest option, for my end user at least, would be to supply json library specific abstractions for the model etc.

[electricessence]

So let me get this straight.
You have a model/DTO that you don't own.
But you need System.Text.Json or something like this lib to know how a property is named.
Can you just do a remap to another class?

Things that are easy:

• deserializing with case ignored

Things that are hard:

• serializing to specific casing per property or remapping to different names

Can you simply have a class that maps exactly and then just remap to the signature you need?
Maybe by writing an extension?

[netclectic]

I do own the model/dto, but its for a 3rd party api.
I want to provide a client library for the api without forcing the end user to take a dependency on a specific Json library.
Some of the naming I've come across can make it impossible to make an exact map in c#.

I guess one solution would be to split the model into its own package and have a specific version for each of the supported Json libraries.

[electricessence]

Yeah I get it. As you can see much like having different implementations for System.Data by having other libs, this is the kind of approach I took with this project.

I think I see where you're going. You're trying to open the door to allow for the consumer of your DTOs to use whatever lib they want without incurring the cost of importing all the libs.

It may be possible to have an attribute provided by Open.Serialization.Json and then possibly use that as a signal/marker for the subsequent implementations to indicate what the token (name) should actually look like.

It's not a trivial thing. :(

Other options include:
Have the DTO as a class with virtual properties, then you can publish a "Newtonsoft" and a "System.Text.Json" version that override those properties but apply the appropriate attribute for those specific libs.
It's a bit messy, but it would definitely work and you'd still have a common class that both would share. You'd just make it so that when it deserializes it, it uses it's respective model, but that model is coercable to the underlying common class.

That approach sadly would not allow for simply switching a project's DI config from one to the other easily without actually importing that version. I dunno, might be fun to try it that way.
Your DTOs could be published and contain the respective Open.Serialization lib that also has a reference to the library it uses. :/ Promising.