LiveCharts2在.NET Framework 4.8下的GLWpfControl加载异常分析

问题背景

在使用LiveCharts2图表库的WPF控件版本时，部分开发者遇到了一个棘手的运行时异常。当应用程序基于.NET Framework 4.8平台运行时，系统会抛出FileLoadException异常，提示无法加载GLWpfControl程序集。这个问题的特殊性在于它只影响.NET Framework环境，而在.NET Core/.NET 5+平台上则不会出现。

异常现象

开发者在使用LiveChartsCore.SkiaSharpView.WPF 2.0.0-rc5版本时，无论是全新项目还是已有项目，只要在XAML中添加CartesianChart控件并运行，就会立即触发以下异常：

Failed to load file or assembly "GLWpfControl, Version=3.3.0.0, Culture=neutral, PublicKeyToken=null" or one of their dependencies. An assembly with a strict name is required. (HRESULT exception: 0x80131044)

值得注意的是，尽管GLWpfControl程序集确实存在于应用程序的生成目录中，系统仍然无法正确加载该程序集。

根本原因

经过深入分析，这个问题与SkiaSharp库的一个已知问题直接相关。在.NET Framework环境下，特定版本的SkiaSharp存在程序集加载机制的问题，导致依赖它的GLWpfControl无法被正确识别和加载。这种强名称(strong name)验证失败的情况通常发生在程序集版本不匹配或签名验证失败时。

解决方案

LiveCharts2的开发团队迅速响应了这个问题，他们采取了以下措施：

1. 识别出问题根源在于SkiaSharp的特定版本存在.NET Framework兼容性问题
2. 发布了LiveChartsCore.SkiaSharpView.WPF 2.0.0-rc5.1版本
3. 在新版本中移除了对有问题的SkiaSharp版本的依赖

开发者只需将项目中的LiveChartsCore.SkiaSharpView.WPF包升级到2.0.0-rc5.1或更高版本，即可解决这个加载异常问题。

经验总结

这个案例为我们提供了几个重要的经验教训：

1. 跨平台兼容性问题需要特别关注，特别是当依赖链中存在原生组件时
2. 程序集强名称验证在.NET Framework中更为严格，容易成为兼容性问题的源头
3. 及时更新依赖库版本是解决此类问题的有效方法
4. 开源社区的快速响应机制对于解决紧急问题至关重要

对于仍在使用.NET Framework的开发者来说，保持依赖库更新至最新稳定版本是避免类似问题的好习惯。同时，这也提醒我们在选择技术栈时需要考虑长期维护和跨平台兼容性因素。