Simple Json Serialiser/DeSerializer

Seems a bit of interest int he past, but anyone know of any update Json Serializers / Deserializers to work with TinyCLR?

Guess I can do it in other ways, but just starting to think about it.

Basically I have a device constantly transmitting data from a I2C device and sending that out over a UART port.
I want it to send Data and also receive Commands (eg, simple example Stop/Start/Set Params etc)

Serializing is simple enough, as can be hard coded as its just going to be something like

return ($"{{ “Data”: {{ “Dir”:"{Heading}", “Cal”: “{true}” }} }}");

{ “Data”: { “Dir”: “360”, “Cal”: “true” }}

or

{ “CmdACK”: { “GainSet”: “100” }}

That output will be consumed by a Application written in full dot net, so can use JSon library there to DeSerialize easy enough if needed.

But for the TinyCLR app on the device to DeSerialize I wanted to use Reflection to actually create a class object of a certain received type, which might vary. eg Command Object, other Objects of different type. But that’s not available.

eg

{ “Command”: { “Cmd”: “SetParams”, “Parms”: [ {“Gain”: “100”}, {“Time”: “100”}] }}

pseudo:

Class Command {
public string Cmd;
public string Params[];
}

I might be able to get away with just using a generic object like above “Command” to send anything I need to the device to control it, and ‘tokenize’ it on the device as a generic Command object, but just wondering if anyone had any good suggestions?

Ta

I’d previously posted a json/bson serializer/deserializer on codeshare, but codeshare seems to have gone *poof*, so I’ll repost it on github and follow up with a link here. I’ll try to recover a few of my other older codeshare contributions as well.

1 Like

Actually, looks like it is already on github : https://github.com/PervasiveDigital/jsonnetmf

2 Likes

So you think this would just work on TinyCLR? Or changes are necessary?

Haven’t tried it, but I don’t think that the code touches anywhere that TinyCLR is different, so it should be fine as is. That said, I don’t have anything running TinyCLR right now with which to try it.

Thanks for input! Yes I did find that on search of forum, but it seemed lost.
Will check out GIT!

Guys, Just did a bit of a hack conversion to see if I could build a TinyCLR Library and use it.
Its about 25 mins of work, so its a no care put together, never seeing project before.
Very little appears to have to be done to bring it across! (at this stage)
All the Tests work OK, seems to serialise and deserialise with the test cases included.

image
image

Only issue I have seen is in TimeExtentions FromIso8601(), which will be fixable. (Havent got head around project yet!)

But looks like this is doable!
Thanks for your efforts Martin!! @mcalsyn Appreciated.

Whats the Licencing obligations etc ?

GITFork GitHub

4 Likes

Excellent. The license is Apache v2, so you are free to use the code, including for commercial applications.

4 Likes

Spent some time with it and yet to resolve the following so far.

Seems not to handle Classes with Properties set

public class ChildClass
    {
        public int one { get; set; }    // Has issues Serialising Properties
        public int two;
        public int three;
    }

also

public static JObject Serialize(Type type, object oSource){

foreach (var m in methods)
{
  if (!m.IsPublic)
	continue;

  // Gets triggered on get_Length and get_Empty, get_Chars
  // But this might relate to TinyCLR having incorrect properties for these Fields??
  // Might relate to other issue Ref https://forums.ghielectronics.com/t/failed-to-emit-module-projectname/22390

  if (m.Name.IndexOf("get_") == 0)

Believe I have had some luck fixing issues with Properties not serializing & de-serializing, Setter & Getter methods etc.

Anyone got time to have a look?, appreciated!!

https://github.com/PRIMETSS/jsonnetmf/blob/TinyCLRConversionTest/README.md

Glad to hear you’ve made progress with this! I’m having trouble figuring out where the meat of the changes are. I looked through the commits, but most of the files have whitespace change or other wholesale changes, so it’s hard to tell where the functional changes are without doing manual line-by-line comparison. Best practice is to separate formatting changes from functional changes so that we can follow the commits more easily. That said, if you point out what your changed specifically for the property problem, I’ll do my best to comment and take those back into the main source.

Also, the dir structure was designed to have one set of source code and then use shared project files to build each target (4.3, 4.4, Tiny, etc). That way, a bug fix for one shows up in all the targets. In this repo, it looks like the files where actually copied to a TinyCLR directory.

Again, all my comments are really git nit-picking. My goal was a long-lived redistributable package and your goal is probably just to get it working, so please take my comments in that context and with a grain of salt. Again, if you can point out the code fixes, I’m happy to fold them back into the main repo, and thanks much for sharing your changes!

1 Like

Thank you for you input!
You’re absolutely right, and I was not happy with the butcher Git job i saw on commits, but yes, I was not expecting to get it going at all, so it was a hack attempt.
Thanks for the tip on the different projects. I definately didnt bother to look and just ripped the Net-mf stuff out as wasnt interested. But now you have said that, I can see its worth leaving that in and just do TinyCLR as separate target.

Yesterday I seemed to have most of the luck in find and possibly made some modifications that seem to work, but must admit, Im not 100% confortable with.
Now I have it at this stage. Id really appreciate you to have a look and see if we can get this ported to TinyCLR as its a significant bit of work you have done, and it’s really well designed.

What I’ll do is, start over and just merge my changes into it to make it less taxing to follow what Ive done and get yur feed back. As Im sure there are some concepts in the Json Object classes I might be miss understanding!

Will get back

Paul

Sorry got side tracked. Then pondered over how best to handle this trial while also maintaining all the MF stuff.

Basically, I decided for now to pull the netMF stuff out again, since this was really just a trial run to see if it worked. Also I didn’t want to setup my PC for netMF again (new PC does have VS2015, and for some reason this week MS decided to drop my VS2017 license from being auto renewed under MSDN License?? was working before, now I can only renew license for VS2019! Is this a thing? Thought you where allowed to use prev versions!?)
This prevented me from migrating the ‘legacy’ netMF solutions across (I dont think they are compatible anyway with VS2019? seem to remember I got errors saying just that) so I had to remove them to build & test.

The key area I found was in the recursive Serialisation method JObject.Serialize() which for Class Properties didn’t appear to create the JProperty correctly.

Anyway, appreciate your advice/comment on what I did and if looks ok. Seems to Serialize & DeSerialize OK in tests with extra Properties in test classes!

Main commit to focus on:

Regards
Paul