0

I have a set of objects that contain fields & properties that need to be inspectable in the output of serialization but not read back in when deserialized.

This is purely for debugging/confirmation purposes. We are creating hundreds of files and I want to spot check that serialization is occurring correctly by adding supplementary information. I do not want this supplementary information to be read in during deserialization - it's impossible to do so in fact.

I also need to do this with equal facility across different serialization formats, so we can assess which one is working best. I have a generic serialization approach where the desired format is passed in as an argument, so don't want anything too messy or intricate for each different format.

I've hunted around and found various things on related topics - mostly to do with the opposite: not writing certain fields during serialization. What's out there seems to be quite complicated and at times hacky.

Is it possible to serialize an object differently to deserializing it using Json.Net?

JsonConvert .NET Serialize/Deserialize Read Only

Serialize Property, but Do Not Deserialize Property in Json.Net

Also it appears any approach is inconsistent between serialization formats. i.e. unlike the [*Ignore] attributes, there are no [*SerializeOnly] attributes (where * = JSON, XML, YAML).

Is there an easy way to do this across these serialization formats? Is there a single family of attributes that can help? Or is it idiosyncratic and hacky in each case?

Bit Racketeer
  • 493
  • 1
  • 3
  • 13
  • This answer seems very warm. Is this approach generally applicable? https://stackoverflow.com/a/31732029 The reason I ask is that I have found YAML deserialization can throw errors on get-only properties as it expects to find a setter. YAML is the real interest here as that is the format we want to end up with, but we do need XML and JSON available as necessary. – Bit Racketeer Jun 17 '18 at 11:45
  • 1
    Consider using two different types which have the exact same fields and properties but different attributes to enable / disable serialisation (even add a unit test to ensure they 100% match). Add implicit conversion operators between the two of them. Use the appropriate type matching the specific type of serialisation you want. – mjwills Jun 17 '18 at 11:49
  • 1
    Have two different types, as @mjwills suggests, but don't include the fields/properties on the type where you don't want to deserialise all of the data. The data for those fields/properties will be ignored, no attributes required. SRP applies to models just as much as it does for services. – John H Jun 17 '18 at 12:07
  • Then put the debug info in xml comments. – jdweng Jun 17 '18 at 13:11

1 Answers1

0

I have tested and applied this only to XML serialization, but it works for me:

When I want a property to be serialized, but not read back, I just declare an empty setter.

public String VersionOfApplicationThatHasWrittenThisFile
{
     get
     {  
         return "1.0";
     }
     set 
     {
         // Leave empty
     }
}
PMF
  • 14,535
  • 3
  • 23
  • 49
  • How would you ever set that property? Why even include the setter at all if it does nothing? – mjwills Jun 17 '18 at 13:43
  • @mjwills: In this particular case, the property is constant, so I wouldn't ever want to set it. Otherwise, I'd take a variable and set that one using some other property or function. And if I don't add the set property, the value is not serialized with the XML serializer (that's the entire trick here) – PMF Jun 17 '18 at 17:26
  • @PMF I love this solution. Add a non-serializable backing field to the getter and it's a workaround to a missing part of C#. Simple and brilliant. – Bit Racketeer Jun 26 '18 at 11:29