Stefan Tsalapatis - 321 - Feb 6, 2014

I try to serialize a Dictionary<string, object> as  a  member of Response or Request.  
JsonSerializer returns the  dictionary,  but the values are  returned as strings, and the DateTime  string is  formatted as  ticks (it seems like that).    
The “JsConfig.TryToParsePrimitiveTypeValues = true;”  does not change anything.
Using the ProtoBufServiceClient,  also  throws  an exception (from protobuf-net)  that “serializer for system.object is not defined”.
Newton.Json  serializes the dictionary  in their types (tested string,  DateTime, decimal, boolean)
So, in order to transfer a  dynamic  column-store as  a  member of the  Request/Response  DTO, 
 my workaround  is to  serialize/deserialize the dictionary, using Newton.Json and transfer it as a simple string.

Is this possible to change with ServiceStack or it is  a purposeful design decision  ?

No we don’t have support for dynamic dictionaries containing late-bound object value types, consider just using a string dictionary.  You can also use a JsonObject which also inherits Dictionary<string,string> but provides convenience overloads for parsing values if you know their types, e.g: http://stackoverflow.com/a/21603948/85785

Stefan Tsalapatis:

In such case, I will continue what I do right now.   Serialize - deserialize  in a simple string field, member of the Response , using the Newton.Json  http://stackoverflow.com/a/3744505

Robert van Drunen:

We’re running into the same issue: a property with type Object which holds different datatypes. We had a custom JsConfig RawDeserializeFn handler to handle deserialization of DateTime values but JsConfig requires ServiceStack.Text which is excluded from the “free usage” part of ServiceStack v4. Since this handler is/was the only ServiceStack functionality we use in our client toolkit (besides JsonServiceClient) we would like to keep the licensed bits limited to our server code. Does this mean we have to implement deserialization  on each DTO that uses Object typed properties, or is there possibly a way around this?

Not sure what the question is, object properties (whilst a bad idea on DTOs) are still supported (they’re not supported in dictionaries), they do require SS.Text to emit verbose __type info on the wire to be able to support it.

Robert van Drunen:

In short: we have classes with object properties which in practice also hold DateTime values (while a bad idea there is no way around it) Deserialization back to DateTime values does not happen because of the object property type. Our client toolkit only uses the service clients (which are free to use) and one function to handle deserialization of datetime value (using JsConfig, not free) This means we have to extend our license plan dramatically if we want our datetime values deserialized client side. It would be great if there was some way to get datetime values deserialized properly in these situations without the need to add a license for each client.

You can still use JsConfig to configure JSON serialization on ServiceClients? 
I would like to have a better understanding of what doesn’t work or what you’re trying to do, are you trying to use the JSON serializer outside of the service clients? Would you be better off using a string instead?
Otherwise can you post a failing test / code sample of what doesn’t work on: https://github.com/ServiceStack/Issues

Robert van Drunen:

Functionally everything is working, nothing but praise for the software. Thing is that we have to reference ServiceStack.Text in our client project to be able to use JsConfig. This in turn causes a licensing message when that client exceeds the “free usage” limitations (10 operations, 20 types, 6000 requests, …) which we would not get if we only use JsonServiceClient. And since we only need the custom deserializer for datetime values in object properties it would be excessive to include SS.Text for just that single reason.