I don't know how it works, but it seems very odd that serialization/reflection wouldn't work with AOT... the information you need is there in memory either way, isn't it?
It can get really tricky: using reflection you could read a string from any input and create a generic type instantiation that never happens in the source code. How would the code for that type be present in an AOT scenario?
There are also several optimizations that can be made in AOT compiled code that are not allowed when you enable unrestricted reflection or dynamically loading code. As an example, suppose an interface is implemented by just one type in your code. If you AOT compile it, the compiler can safely assume that all calls to methods on that interface actually go to that single type implementing it, thus it can replace interface dispatches with direct calls.
You can get serialization to work, but you have to use a serialization framework that is trimming compatible. For example, to use System.Text.Json, you have to opt-in the types you want to serialize.
dellamonica|2 years ago
There are also several optimizations that can be made in AOT compiled code that are not allowed when you enable unrestricted reflection or dynamically loading code. As an example, suppose an interface is implemented by just one type in your code. If you AOT compile it, the compiler can safely assume that all calls to methods on that interface actually go to that single type implementing it, thus it can replace interface dispatches with direct calls.
MarkSweep|2 years ago
https://learn.microsoft.com/en-us/dotnet/standard/serializat...
sebazzz|2 years ago
reubenmorais|2 years ago
pjc50|2 years ago