When using the type interpretation for arrays of more than 2 dimensions, on deserialization, an error is encountered.
There is a problem in the switch case that does not allow adding more than one comma between the brackets of System.xxxx [].
View issue #2591
Create an easily-inlinable method that accesses the array used
by Enumerable.Empty (and hence not just shared within this project
but likely with the client assembly or other libraries it uses)
and use it anywhere a zero-element array is used, reducing allocations.
Running a spell checker on the whole solution revealed a couple more
typos. This fixes all of those (although internal // line comments are
mostly left alone).
Additionally, convert a very few string.Format occurrences to the pre-
dominant .FormatWith pattern and fix some incorrect message strings.
Primarily where it means one fewer field-access or simplifies
event delegate invocation, though one or two cases have just the
lesser advantage of allowing an IL stack dup rather than local access.
-Added TypeNameAssemblyFormatHandling properties to JsonSerializer and JsonSerializerSettings
-Changed TypeNameAssemblyFormat properties on JsonSerializer and JsonSerializerSettings to obsolete
-Added SerializationBinder properties to JsonSerializer and JsonSerializerSettings
-Changed Binder properties on JsonSerializer and JsonSerializerSettings to obsolete
GetValueOrDefault() is an easily-inlined access to a field as this
will hold the correct value for both HasValue and !HasValue cases.
The Value property in comparison contains a branch on a check that the
Nullable<T> has its internal hasValue flag to decide whether to throw
InvalidOperationException or not.
Hence when a nullable type is known to have a value (not be null) and
one wants the value, rather than to possibly trigger the exception-throw
GetValueOrDefault() has a slight performance benefit over Value.
Accordingly, replace calls to the Value property with calls to
GetValueOrDefault() when previous checks or assignments guarantee the
value is not null.
Due to difference in mono vs .net (see https://bugzilla.xamarin.com/show_bug.cgi?id=36305),
MethodInfo.GetBaseDefinition() does not actually return base class (it returns partially-instantiated
generic class) in mono when overriding property from generic base class. Because of this, lookup
of matching property in ReflectionUtils.GetChildPrivateProperties() fails to find
already added property and adds the same property multiple times. Comparing GetBaseDefinition()'s
compensates for this: since the same function is applied to both PropertyInfo's, matching property
will be found.
This fixes issue #726.
James Newton-King