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?