System.Linq.Dynamic.Core 在.NET 8中的EF类型加载问题解析

问题背景

System.Linq.Dynamic.Core是一个流行的动态LINQ查询库，它允许开发者在运行时构建LINQ查询。近期有开发者报告，在将项目从.NET Core 3.1升级到.NET 8后，遇到了性能问题，特别是在使用Radzen数据网格时首次加载或排序数据时表现明显。

问题根源

问题的核心在于库中的PredefinedTypesHelper类在静态构造函数中尝试加载Entity Framework 6的类型。这些类型包括：

• System.Data.Objects.EntityFunctions
• System.Data.Objects.SqlClient.SqlFunctions
• System.Data.Objects.SqlClient.SqlSpatialFunctions
• System.Data.Entity.Core.Objects.EntityFunctions
• System.Data.Entity.DbFunctions
• System.Data.Entity.Spatial.DbGeography
• System.Data.Entity.SqlServer.SqlFunctions
• System.Data.Entity.SqlServer.SqlSpatialFunctions

在.NET Core 3.1及更早版本中，这些类型会被NETSTANDARD预处理器指令排除。但在.NET 5及更高版本中，这些指令不再适用，导致库尝试加载这些EF 6类型。

性能影响

当应用程序目录中存在大量未引用的程序集时，Type.GetType()调用会强制加载所有这些程序集到AppDomain中。对于拥有数百个程序集的大型项目，这会显著影响首次查询的性能。

解决方案

开发团队针对此问题实施了以下改进：

1. 条件加载优化：修改了PredefinedTypesHelper，仅在检测到特定EF类型时才尝试加载相关程序集。通过检查EntityFramework.DynamicLinq.EFType和Microsoft.EntityFrameworkCore.DynamicLinq.EFType类型的存在性来决定是否加载EF相关类型。

2. 程序集加载控制：新增了LoadAdditionalAssembliesFromCurrentDomainBaseDirectory配置选项，默认值为false。这可以防止自动加载应用程序目录中的所有程序集，只有当明确需要时才启用此功能。

3. 预处理器指令调整：将EF类型加载逻辑限制在.NET Framework和.NET Standard 2.1环境下，避免在.NET 5及更高版本中不必要地加载这些类型。

开发者应对建议

对于遇到此问题的开发者，可以采取以下措施：

1. 升级到最新版本：确保使用包含这些修复的最新版System.Linq.Dynamic.Core。

2. 自定义类型提供程序：如需要更精细的控制，可以实现自定义的IDynamicLinqCustomTypeProvider：

public class CustomDynamicLinqTypeProvider : AbstractDynamicLinqCustomTypeProvider, IDynamicLinkCustomTypeProvider
{
    // 实现必要的接口方法
}

然后在应用程序启动时配置：

ParsingConfig.Default.CustomTypeProvider = new CustomDynamicLinqTypeProvider();

3. 配置程序集加载行为：根据需求设置LoadAdditionalAssembliesFromCurrentDomainBaseDirectory属性：

ParsingConfig.Default.LoadAdditionalAssembliesFromCurrentDomainBaseDirectory = false;

总结

System.Linq.Dynamic.Core在.NET 8环境下的这一改进，有效解决了因不必要加载EF 6类型和额外程序集导致的性能问题。开发者现在可以更灵活地控制类型解析行为，特别是在拥有大量插件或模块化架构的应用程序中，这一改进将显著提升首次查询的性能表现。