0

When I run the following code in a windows console application referencing AWSSDK.Core.3.3.19.1\lib\net45\AWSSDK.Core.dll, I get nice output:

public class Person
{
   public string Name { get; set; }
   public int Age { get; set; }
   public DateTime Birthday { get; set; }
}

public static void PersonToJson()
{
   Person bill = new Person();

   bill.Name = "William Shakespeare";
   bill.Age = 51;
   bill.Birthday = new DateTime(1564, 4, 26);

   string json_bill = JsonMapper.ToJson(bill);

   Console.WriteLine(json_bill);
}

The output (formatting added) is:

{  
   "Name":"William Shakespeare",
   "Age":51,
   "Birthday":"04/26/1564 00:00:00"
}

But when I run the same code referencing AWSSDK.Core.3.3.19.1\lib\MonoAndroid10\AWSSDK.Core.dll, I get different results:

EDIT Original post had different code here, but I was able to reproduce the problem with the same code.

The alternate version looks like this:

{  
   "Name":"William Shakespeare",
   "Age":51,
   "Birthday":"04/26/1564 00:00:00",
   "<Name>k__BackingField":"William Shakespeare",
   "<Age>k__BackingField":51,
   "<Birthday>k__BackingField":"04/26/1564 00:00:00"
}

Is this a bug? Can I work around it and clean this up? I assume I need to use the Android version in order to run on an Android device, but interestingly, I can reference the MonoAndroid10 version from a Windows console application. Why are there different files for different platforms when .NET is cross-platform?

BlueMonkMN
  • 25,079
  • 9
  • 80
  • 146

2 Answers2

1

Is this a bug? Can I work around it and clean this up? I assume I need to use the Android version in order to run on an Android device, but interestingly, I can reference the MonoAndroid10 version from a Windows console application. Why are there different files for different platforms when .NET is cross-platform?

I've tested the latest AWSSDK.Core (3.3.21.6), this issue persists.

Then I also tested LitJson separatly with latest version(0.11.0). There is no such issue.

So the problem appears to be exists only in AWSSDK.Core. Until the framework author fix the issue, the workaround for your problem is to reference LitJson separately and use LitJson.JsonMapper instead of ThirdParty.Json.LitJson.JsonMapper.

Elvis Xia - MSFT
  • 10,801
  • 1
  • 13
  • 24
  • Did you test LitJson on Mono -- do you understand and can you explain what it means for a .NET library to be targeted for MonoAndroid10? – BlueMonkMN Jan 16 '18 at 19:21
  • Yes, I tested LitJson on Mono. And the dll I tested for LitJson is targeting .netstandard2.0 (/packages/LitJson/lib/netstandard2.0/LitJson.dll) and it works fine. So it appears to me is a issue of `AWSSDK.Core.dll` targeting MonoAndroid10. – Elvis Xia - MSFT Jan 17 '18 at 02:53
  • I have reported the issue at https://github.com/aws/aws-sdk-net/issues/837 – BlueMonkMN Jan 18 '18 at 14:38
0

Your Outpot code is totally different. And it has to deal with Arrays. Faced with that, it has as a two options:

  • Display the result of .ToString() only. In .NET that usually is the class name
  • Do a Dump of the Array contents, in whatever detail level the original programmer intended

Outputting a Array like that is only usefull for Debugging. So make you proper output code already.

As for the Birthday: What is displayed is the Raw Value stored inside DateTIme, not reinterpreted with a System selected Formating. It could be something like "the ticks/seconds since counting started". Honestly I am surprised DateTime can even display that value.

Christopher
  • 9,634
  • 2
  • 17
  • 31
  • It has nothing to do with the different code. I forgot to delete the different code and update the output after I managed to reproduce the problem by only changing the DLL reference in the original program. – BlueMonkMN Jan 16 '18 at 01:21
  • You are using AutoImplement Properties. That means there is a get function, a set function and a backing field. They are just autogenerated by the Compiler, thus do not have a normal name and you do not run the danger of using them by Accident. The 2nd example simply uses Reflection to get both the Properties AND their backing fields printed. There is no "extra garbage". This is exactly the output that should happen with the class you gave the computer. If anything, example 1 is not complete *enough*. – Christopher Jan 16 '18 at 01:24
  • My point is, the first example is what litJson shows on their web site at https://github.com/LitJSON/litjson/blob/develop/doc/quickstart/guide.md so that's the output I want and expect. – BlueMonkMN Jan 16 '18 at 01:27
  • **There is no extra data**. The first example simply does **not** go and includes the Backing Fields in the output. While the 2nd case **does**. That is fact to all my knowledge of Programming in the .NET Framework for a decade. – Christopher Jan 16 '18 at 01:40
  • I *understand* what you are saying. I have also been programming with .NET for a decade (actually 15 years, I think). But the fact remains that most seralizers have a way to suppress the duplicate data because it really doesn't make sense to seralize both the properties and the backing fields. Furthermore, since this serializer is written in .NET; it should not be behaving differently on different platforms/implementations of .NET. If you look at their documentation you can see their intent was not to output duplicate data. That results in the file being more than twice the size. – BlueMonkMN Jan 16 '18 at 01:54
  • Another problem that arises from a unexpectedly and undesirably including backing fields is that it causes errors when you change the names of backing fields, which should not have an external impact. – BlueMonkMN Feb 17 '18 at 13:36