.NET 8升级后程序集加载导致WPF应用无法启动

核心根源：程序集加载机制的差异 #

在.NET Framework 4.8中，Assembly.LoadFile加载的同标识程序集会和默认加载的程序集复用实例——CLR基于程序集强名称/标识匹配，忽略加载路径差异。但到了.NET 8（属于.NET Core系列运行时），Assembly.LoadFile加载的程序集会被分配独立的加载上下文，和应用启动时默认加载的主程序集不再是同一个实例。

WPF资源查找的连锁影响 #

WPF的XAML资源URI（如/AssemblyName;component/mainwindow.xaml）是基于默认加载上下文的程序集来定位资源的。当你在OnStartup中用Assembly.LoadFile加载当前程序集的副本后：

• .NET 8运行时会将其识别为两个完全独立的程序集实例
• 主窗口XAML绑定的资源指向默认加载的程序集，但此时加载上下文被干扰，资源查找时无法匹配到正确的程序集实例，最终抛出资源未找到的异常

.NET 4.8正常的原因 #

.NET Framework采用应用程序域模型，相同标识的程序集无论通过何种方式加载，都会复用已加载的实例，不会创建新的加载上下文，因此WPF的资源查找流程不受影响。

验证方式 #

可以通过打印程序集哈希值直观验证：

// 默认加载的主程序集
var defaultAssembly = typeof(App).Assembly;
Console.WriteLine(defaultAssembly.GetHashCode());

// LoadFile加载的程序集副本
var loadedAssembly = Assembly.LoadFile(defaultAssembly.Location);
Console.WriteLine(loadedAssembly.GetHashCode());

.NET 4.8中两个哈希值相同，.NET 8中则不同，直接证明了加载上下文的差异。

内容的提问来源于stack exchange，提问作者Till