System.Linq.Dynamic.Core 在.NET 8中的EF 6类型加载问题分析与解决方案

问题背景

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

问题根源

经过深入分析，发现问题主要出在库的PredefinedTypesHelper类的静态构造函数中。这个构造函数会尝试加载一组来自System.Data.Objects和System.Data.Entity的类型，这些类型实际上是Entity Framework 6（EF6）的组件。

在.NET Standard环境下，由于预处理器指令NETSTANDARD的存在，这部分代码会被跳过。但在.NET 8环境中，这个指令不再适用，导致库会尝试加载这些EF6类型。更严重的是，Type.GetType(typeName)调用会强制加载当前工作目录中的所有程序集，当目录中存在大量程序集时，会造成显著的性能下降。

技术细节

问题的核心在于以下几个技术点：

1. 预处理器指令不完整：原始代码只检查了NETSTANDARD指令，没有考虑.NET 5及更高版本的情况。

2. 程序集加载机制：Type.GetType()调用会触发对当前目录下所有程序集的扫描和加载，即使这些程序集与当前操作无关。

3. 静态构造函数执行时机：这些加载操作发生在静态构造函数中，意味着它们会在类型首次使用时执行，且只执行一次。

解决方案

项目维护者提供了两个主要的解决方案：

1. 优化EF类型加载逻辑：修改PredefinedTypesHelper，使其只在检测到特定EF类型存在时才尝试加载相关程序集。这通过检查EntityFramework.DynamicLinq.EFType类型是否存在来实现。

2. 新增配置选项：添加了LoadAdditionalAssembliesFromCurrentDomainBaseDirectory配置属性，默认设为false，可以防止自动加载工作目录中的额外程序集。

实施建议

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

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

2. 自定义类型提供程序：如问题中所述，可以实现自定义的IDynamicLinqCustomTypeProvider来精确控制类型解析行为。

3. 配置调整：将LoadAdditionalAssembliesFromCurrentDomainBaseDirectory设为false以避免不必要的程序集加载。

总结

这个问题展示了在跨平台、多版本.NET环境中处理遗留组件时的典型挑战。通过合理的预处理器指令使用和灵活的配置选项，System.Linq.Dynamic.Core项目有效地解决了在.NET 8环境下不必要的EF6类型加载问题，为开发者提供了更好的性能和更可控的行为。

对于依赖此库的项目，特别是那些使用Radzen等UI组件库的项目，及时应用这些修复可以显著改善首次加载时的性能表现。