More future proof type hints emitted in Object serialization

[domj]

Due to the SharpDX to Xenko Mathematics migration I can’t Deserialize some files that were using these types again.

In a standard case when you have a fixed type field or sequence to serialize this is not an issue. The types are not written in to the XML and the definitions in the patch are used as reference.

When serializing data contained in more generically typed fields or sequences (eg. Object, Spread, Dictionary<String, Object>) the migration becomes an issue as the types need to be written into the XML to be read back correctly.

Here’s a simple patch illustrating the behavior

SharpDXTypeHintsWithGenericSerialization.vl (8.1 KB)

It is kind of a corner case though and most of the time using such generic fields is not the best idea in general.

My current plan to fix this once I migrate to the new version is to write a script to replace all the SharpDX references with Xenko ones.

My question is if there maybe is a better more resilient way to deal with these cases or maybe a way to add a type alias for Serialization. Also looking at the serialized Spread containing another Spread you can see that the current library version also comes up and I wonder what happens when the library is just updated - will the Deserialization work still and automatically push the type to the newer version?

[tonfilm]

@domj

My current plan to fix this once I migrate to the new version is to write a script to replace all the SharpDX references with Xenko ones.

yes, this might be the easiest way, do a string replace in the files. that is also how we changed the imports.

@domj

maybe a way to add a type alias for Serialization.

this can be considered a bug in serialization, if the type is imported by VL it should probably store the VL type name instead of the .NET name… but that might be quite some work and we are not planning to switch types every other week.

for now we are very sorry that you have to spend time on it and fix it by hand, but it might not be that hard if you know the new .NET name and dll token for the xenko types…