A recent business requirement demanded an unexpected change to a web API endpoint. A numeric field in the request body had to accept a set of predefined string values in addition to numeric values. I managed to implement it in a way which wasn't a breaking change for the existing clients of this endpoint.
Recently, I was troubleshooting some unexpected behavior of a REST service my team is maintaining: in its JSON response, the same numeric field sometimes included insignificant zeros after the decimal separator and sometimes it didn't. Further research revealed that the differences originated from another JSON document which served as the data source and manifested the same behavior. But we were still wondering why the insignificant zeros in the fractional part were preserved across deserializing the value and serializing it again.
JSON serialization allows a lot of flexibility, sometimes even too much, e.g., a field that can be serialized into two different JSON types, depending on its contents. It could be serialized as string. Or, it could be serialized as a number. To make deserialization work, I had to implement a custom JsonConverter.
Usually, before manipulating JSON inputs, you first deserialize them into strongly typed objects that match their structure. However, that might not always be possible. Recently, I had to combine multiple JSON inputs into a single JSON array, without any knowledge of the input JSON structure.
The navigation properties in Entity Framework Core models are not only useful for reading hierarchical data from database, but can also very much simplify importing hierarchical data from other sources like JSON files.
After I learned about JsonStringEnumMemberConverter, I wanted to use it for an enum in a large project I was working with, but to my surprise it didn't seem to have any effect on the serialization.
When serializing enums to JSON, it's usually better to serialize them as descriptive strings than incomprehensible magic numbers. Most of the time, it's good enough to simply use the names of enum members for this purpose. However, these must follow the rules for identifier names in C#, so they might be too restrictive if you need to use specific string values because of interoperability with other systems.
An endpoint in my ASP.NET Core web API project suddenly started returning a truncated JSON response with a 200 response code. According to the logs, an exception was thrown, but for some reason the response code was not 500 as I would expect.
With the new System.Text.Json built into .NET Core, JSON serialization can now be performed without the Json.NET library. However, there are differences between the two libraries once you go beyond the basics. For example, support for serializing and deserializing polymorphic objects is limited in the new library.
XmlSerializer is often a great choice for persisting objects or transmitting them over the wire, either by using default object serialization tailored only with attributes or by implementing the IXmlSerializable yourself. If you're not careful though, this might come at a significant performance cost.
Recently I tackled a seemingly simple task: XML serialization of a generic class used with a TimeSpan data type. It turned out that XmlSerializer doesn't serialize the TimeSpan structure at all.