5 ms·

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,

• reubenmorais 3y ago
  An explanation of the problem: https://github.com/dotnet/corert/blob/master/Documentation/using-corert/reflection-in-aot-mode.md https://github.com/dotnet/corert/blob/master/Documentation/u...
• dellamonica 3y ago
  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.
• MarkSweep 3y ago
  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. https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/source-generation https://learn.microsoft.com/en-us/dotnet/standard/serializat...
  • sebazzz 3y ago
    "Opt-in" is not doing this feature justice, that is full serialization code pre-generated at compile time for your types. Beautiful.
• pjc50 3y ago
  The default XML (de)serializer does a lot of code generation at runtime. Which doesn't work with AOT.