Fix default serialization

[vsmalladi]

Closes #659

[MattMcL4475]

The current change looks like it will just not serialize default properties... but won't resolve #659

Seems like to resolve #659 something like this is needed:

opts.SerializerSettings.Converters.Add(new StringEnumConverter());

This also needs a unit test.

[BMurri]

The current change looks like it will just not serialize default properties... but won't resolve #659

The 0 is the default value of the TesFileType enumeration, which value does not actually exist (look at the code). That zero was written by the StringEnumConverter. Adding another one won't do anything (one was already added by the attribute in that code file).

I agree with unit tests, though.

@MattMcL4475

[vsmalladi]

@BMurri should the default be 1 then if not provided or null since it is not required on until runtime from the server to update FileType

[BMurri]

My understanding is that the server is expected to only provide missing types on outputs, per the discussions associated with the removal of the requirement to provide type when submitting the task to the server (a change in 1.1), but maybe I'm recalling that discussion incorrectly. Note also that determination of type when it's missing can only be done with certain kinds of source storage locations, e.g. generic web URLs is one case where directory inputs are not possible to implement.

If the default is changed to 1, then there'll be no way for the server to know it wasn't set in the first place. Making it nullable would be a possibility, but with the proposed fix the entire property will not be written in the JSON when clients retrieve the task when its value is the default (of 0) (along with all other properties that are missing values). Note that arrays that are present but empty will be written with this fix (to prevent writing them would require them to be null).

[vsmalladi]

I think if its not provided it should be null.

[BMurri]

I think if it's not provided it should be null.

In C# it's an enumeration. Our choices are:

1. if it's not provided it's completely missing when retrieving the task and its value is 0 when accessing it inside of the server
2. We explicitly make it a Nullable<>

1. is what the current state of this fix does.

[vsmalladi]

I think if it's not provided it should be null.

In C# it's an enumeration. Our choices are:

1. if it's not provided it's completely missing when retrieving the task and its value is 0 when accessing it inside of the server
2. We explicitly make it a Nullable<>

1. is what the current state of this fix does.

So the JSON resturned would be still 0 or null from the API

[BMurri]

So the JSON resturned would be still 0 or null from the API

In the JSON it is entirely missing. In the POCO model, it is 0.

[vsmalladi]

In the JSON it is entirely missing. In the POCO model, it is 0.

That seems reasonable to me.