为何在控制台应用中引用WPF程序集必须配置<UseWPF>true</UseWPF>？

这本质是.NET Framework和.NET Core/.NET 5+在项目构建模型与运行时依赖管理上的核心差异导致的：

1. .NET Framework的全局依赖模型 #

在.NET Framework 4.8中，WPF是全局安装的框架组件，所有WPF程序集都放在GAC（全局程序集缓存）里。当你手动引用PresentationCore等dll时，系统会自动从GAC加载对应版本的兼容程序集，而且.NET Framework的构建系统默认就支持WPF的编译、运行逻辑——哪怕你是控制台项目，只要引用了WPF程序集，构建系统会自动适配必要的配置，不需要额外开关。

2. .NET Core/.NET 5+的SDK模块化模型 #

.NET Core之后改用了SDK风格项目，默认模板（比如控制台）只会加载对应类型的构建目标和运行时配置，不会默认启用WPF相关的逻辑。此时手动引用WPF的dll会触发两个关键问题：

• 缺少WPF专属的MSBuild任务：比如XAML编译为BAML、资源嵌入、程序集版本匹配等逻辑都没有启用，导致构建出的程序无法正确加载WPF组件。
• 运行时环境未初始化：WPF需要特定的Windows运行时环境，以及Application对象的初始化逻辑。没有true的话，SDK不会设置正确的平台目标（比如强制匹配Windows位数，避免AnyCPU跨位数加载错误），也不会注入WPF运行时启动的必要代码，最终抛出System.BadImageFormatException——本质是程序集加载时的格式、环境不匹配。

3. true的实际作用 #

这个配置是告诉MSBuild：

• 启用WPF专属的构建流水线，自动处理XAML编译、资源嵌入等任务；
• 自动引入官方的WPF NuGet包（比如Microsoft.WindowsDesktop.App.WPF），替代手动引用零散dll，确保版本兼容性；
• 配置运行时环境，强制应用在Windows平台运行，设置正确的位数匹配逻辑；
• 注入WPF运行时初始化代码，确保Application对象正确启动，让WPF组件能正常加载运行。

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