You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For EF Core 7.0, we introduced some trimming annotations to make basic scenarios work with aggressive trimming, the new default for console application (#29092). The main goal there was to prevent properties on entity CLR types from being trimmed, since EF accesses them at runtime via reflection and the linker cannot see that. For example, the T in DbSet<T> was annotated to preserve all constructors/properties; but entity types without an explicit DbSet property (e.g. discovered via navigations) would still fail, and require explicit user intervention.
We are now exploring a full AOT approach to EF, where materializers are generated as C# code into the user's project. In that world, the above partial annotations are no longer needed, since the linker can see EF's access in plain (generated) C# code. We should consider removing these annotations.
This would mean that EF's trimming story is coupled to its AOT story (EF's AOT, not NativeAOT), i.e. we don't fully support trimming without AOT; or more precisely, if the user does trimming without AOT, it's their responsibility to annotate their own types as appropriate. I think this makes sense, since we can't fully solve this problem anyway (e.g. entity types discovered via navigations).
The text was updated successfully, but these errors were encountered:
Note that these annotations potentially cause bloat, since they cause user POCOs to not get trimmed when they could be. On the other hand, they do provide a bit of assistance for trimming when AOT (precompiled queries) isn't in use. We'll discuss this in design and decide what to do.
For EF Core 7.0, we introduced some trimming annotations to make basic scenarios work with aggressive trimming, the new default for console application (#29092). The main goal there was to prevent properties on entity CLR types from being trimmed, since EF accesses them at runtime via reflection and the linker cannot see that. For example, the T in
DbSet<T>
was annotated to preserve all constructors/properties; but entity types without an explicit DbSet property (e.g. discovered via navigations) would still fail, and require explicit user intervention.We are now exploring a full AOT approach to EF, where materializers are generated as C# code into the user's project. In that world, the above partial annotations are no longer needed, since the linker can see EF's access in plain (generated) C# code. We should consider removing these annotations.
This would mean that EF's trimming story is coupled to its AOT story (EF's AOT, not NativeAOT), i.e. we don't fully support trimming without AOT; or more precisely, if the user does trimming without AOT, it's their responsibility to annotate their own types as appropriate. I think this makes sense, since we can't fully solve this problem anyway (e.g. entity types discovered via navigations).
The text was updated successfully, but these errors were encountered: