已装.NET却仍打不开WPF程序，怎样分清Desktop Runtime与Framework

已安装.NET不代表WPF程序所需的运行时已经满足。先区分.NET Framework、现代.NET的基础Runtime与Windows Desktop Runtime，再看程序目标系列、架构和部署模式。SDK用于开发，安装了某个SDK也不能凭名称就推断所有旧程序都能运行。

先确定文件与环境

本文用现代.NET的runtimeconfig示例解释运行时家族，版本8.0.0是合成输入，不是今天应新部署哪个版本的建议。是否仍受支持、补丁版本和系统要求应按官方页面及产品供应方确认。自包含应用可能携带自己的运行时，Framework应用也不能直接用现代.NET列表判断依赖已齐。

操作与判断

1. 保留启动错误完整文本和程序发布说明，确认框架依赖或自包含、目标Windows版本与架构。不要只问“装了.NET没有”，应请供应方给出明确系列和要求。

2. 在程序附近读取runtimeconfig.json等声明；本例Desktop请求Microsoft.WindowsDesktop.App，控制台请求Microsoft.NETCore.App。没有这个文件不自动证明程序不依赖.NET，还需确认发布形式。

3. 分别列出当前解析到的dotnet路径与运行时列表，防止x86和x64目录混淆。只有基础Runtime条目时不能当作Desktop家族已匹配；列表也不覆盖所有Framework安装状态。

4. 按供应方支持的官方安装方式补齐后，用相同程序和输入复测。版本选择还涉及roll-forward策略，本文检查器只验证家族和架构，不擅自实现全部版本选择算法或建议无条件安装最新版。

输入对照与结果边界

请求	现有条目	结论
WindowsDesktop.App x64	NETCore.App x64	缺Desktop家族
NETCore.App	WindowsDesktop包含哪些依赖	按官方安装关系核对
.NET Framework	现代dotnet列表	不能据此判齐

verify.py实际读取合成输入，确认基础运行时不能满足此Desktop家族请求。这个反例只隔离家族维度，未验证8.0.0如何前滚到补丁版本。两个runtimeconfig文件可用于辨认字段，不是可执行WPF项目；把JSON放到任意EXE旁也不会自动把程序改成对应框架。

下载并复核

Desktop家族样例、基础Runtime样例、缺家族反例、家族匹配检查、运行时只读查询、执行结果。

下载两份配置样例、cases.json、验证脚本和只读PowerShell命令。先对照家族名，再在目标机执行列表查询并另存脱敏记录。记录命令路径、系列、版本与架构，私有安装路径可以保存在项目内部，不必公开完整用户目录。未取得供应方要求时把匹配状态列未知。

已运行家族匹配反例并解析PowerShell语法。配置文件是合成说明，不是实际WPF应用；未安装运行库、未测试目标程序启动。

失败时怎样继续

家族已经满足仍打不开，查实际选中的安装位置、缺失原生依赖、程序配置和错误事件。不要把所有WPF失败归因于中文程序集名，也不要把重新安装运行库作为唯一动作。若报错明确指向不支持的操作系统，要按产品支持范围处理，不能靠拷运行时文件硬凑部署。

交付记录应包含发布模式、目标运行时、验证过的安装包来源及恢复步骤。升级程序后重新核对声明，因为框架系列或架构可能变化。完成启动还应打开关键页面与素材流程，避免运行时加载成功就被误写为整个展项功能验收通过。

相关背景可看Win11 上 WPF 程序莫名崩溃？先看程序集名是不是中文，继续从远程运维专题查找相关流程；需要结合项目确认时可查看SoftAgent 部署能力。

一级出处

• Windows的.NET Runtime、Desktop Runtime、SDK与.NET Framework用途不同。

来源核对日期：2026-10-24。来源支持所述机制；本文合成输入与本地计算只证明所列文件及算法，不代表目标软件或现场设备已验收。