Windows 桌面应用总在用户电脑上装不起来？.NET Windows Desktop Runtime 把运行时直接塞进安装包
【免费下载链接】windowsdesktop项目地址: https://gitcode.com/gh_mirrors/wi/windowsdesktop
一个再熟悉不过的场景
你把 WinForms 或 WPF 应用开发完、测试通过、打包上传，满心期待用户双击运行。结果对方发来一张截图：安装程序运行到一半，提示缺少Microsoft.WindowsDesktop.App运行库。接下来就是一连串熟悉的操作——让用户去官网下载对应版本的运行时、远程协助、反复确认系统是 32 位还是 64 位。一周下来，光是"装不上"就占了你技术支持工作量的三分之一。
这不是你的应用写错了，而是 Windows 桌面应用独有的困境：你的程序依赖特定版本的桌面运行时，而用户机器上恰好没有，或者版本对不上。解决这个问题的关键，是你能否在发布应用时，同时交付一个"装上就能跑"的运行时安装包。这正是 .NET Windows Desktop Runtime（windowsdesktop 仓库）在做的事情：把 WinForms 与 WPF 所需的全部运行时组件，构建成一个开箱即用的离线安装程序。
一句话结论：把"让用户装环境"变成"随包交付环境"
与其让每个用户手动排查缺失的依赖，不如在发布时就把运行时和你的应用一起交付。windowsdesktop 仓库就是这套运行时安装包的"生产工厂"：它把 WPF 的PresentationFramework、WinForms 的核心程序集、以及两者共享的运行时组件，统一打包为官方风格的安装程序。用户拿到的是一个双击即可完成配置的文件，而不是一串下载链接和安装教程。
动手构建：从源码到安装包
上手体验这个项目并不复杂，你只需要一台安装了 .NET 9 SDK 的 Windows 机器。
第一步，获取源码：
git clone https://gitcode.com/gh_mirrors/wi/windowsdesktop第二步，了解仓库结构。核心内容集中在src/windowsdesktop/下：
src/bundle/——WiX 安装包工程，负责生成最终的离线安装程序；src/sfx/——运行时与目标包工程，产出windowsdesktop-runtime与windowsdesktop-ref；tests/——自动化测试套件，负责校验生成的 NuGet 包结构是否完整。
第三步，触发构建。项目基于 Arcade 构建体系，仓库根目录的Build.proj会串联整个流程。构建完成后，你会得到名为windowsdesktop-runtime-<版本>-<架构>.exe的产物——这就是可以直接发给用户的离线安装包。整个过程中你不必手动配置任何环境变量，SDK 会从eng/common中自动拉起所需工具链。
三个值得深入了解的特性
1. 自包含的安装包：一次交付，随处安装
这是整个项目价值最大的部分。src/windowsdesktop/src/bundle/bundle.wxs定义了一个 WiX Bundle——它把运行时全部组件压缩进单个可执行文件，用户在无网络环境下也能完成安装。更重要的是，它内置了版本升级策略：RelatedBundle声明允许旧版本（preview、RC、GA 以及历次 servicing）被新版本平滑替换，避免"装了新版装不了旧版"的冲突。你可以把它理解成"运行时版的更新管理器"——用户永远只看到一次安装，版本演进在后台悄悄完成。
2. 多语言与品牌化安装界面
安装包长什么样，直接决定了用户的第一印象。项目在src/windowsdesktop/src/bundle/theme/下内置了 14 种语言的本地化文件（涵盖中、英、日、德、法、西等常用语言），界面布局由bundle.thm主题文件统一控制。如果你在构建企业级产品，可以修改主题中的字体、配色，替换默认的dotnet.ico与DotNetLogo_256x.png，让安装界面带上自家品牌标识——不用改任何业务代码。
3. 分架构的环境探测与兼容性防护
桌面应用最头疼的架构混装问题，项目也替你处理了。bundle.wxs中的检测逻辑会分别检查 x86、x64、ARM64 三个维度的已安装路径：如果发现同一路径被不同架构占用，安装程序会直接给出提示而不是默默覆盖；注册表搜索（如SOFTWARE\dotnet\Setup\InstalledVersions）则能精确定位既有安装位置，避免重复安装或错误升级。对要部署到混合架构办公环境的团队来说，这个细节能省掉大量排障时间。
使用前后对比：一个真实的分界线
| 维度 | 依赖用户手动装环境 | 随包交付运行时 |
|---|---|---|
| 安装步骤 | 下载→安装→重启→回装 | 双击→下一步→完成 |
| 版本冲突风险 | 高，用户环境不可控 | 低，安装包自带升级策略 |
| 技术支持介入 | 频繁，需远程协助 | 极少，错误信息指向明确 |
| 离线/受限网络 | 基本不可用 | 完全可用 |
这不是一个抽象的承诺。正因为运行时被打包进安装程序，用户侧的安装流程从"多步骤的依赖排查"收敛为"一次点击"，你也能把从"帮用户装环境"中省下来的时间还给业务开发。
常见疑问速答
只装这个运行时，还需要单独装 .NET Runtime 吗？需要分清定位：Microsoft.WindowsDesktop.App是在 .NET Runtime 之上的桌面层。windowsdesktop 仓库负责构建桌面运行时本身；如果用户是首次安装，官方安装流程会把基础运行时一并处理，你通常无需分别交付两个安装包。
应用升级后，老版本运行时还要保留吗？不必。bundle.wxs的升级关系支持"新版替换旧版"，同时项目遵循 .NET 的并行版本策略，新旧版本可以共存而不互相干扰——你的旧应用不会因为升级而突然启动失败。
这个仓库能定制自己的安装界面吗？可以。改src/windowsdesktop/src/bundle/bundle.thm调整布局与配色，替换theme/下的语言文件，或在构建时指定Lang参数。对大多数团队来说，改主题文件已经足够满足品牌化需求。
ARM64 设备支持吗？支持。构建参数可按目标架构切换，bundle.wxs中还专门为 ARM64 场景写了路径隔离检查，防止与 x86/x64 的安装路径互相污染。
我只用 WinForms 或只用了 WPF，包会很大吗？运行时包是按"共享组件 + 各框架专属组件"组织的（见src/sfx/下的工程定义），但你交付的安装包面向的是所有用户，运行时本身是完整的；如果你追求极致体积，更合适的路线是考虑自包含发布（single-file），这与本项目解决的是两个不同问题。
开始行动
你的 Windows 桌面应用之所以"装不上"，99% 的情况是运行时缺失或版本错配——而这个仓库把"补运行时"这件事封装成了标准化的构建产物。与其在售后群里一遍遍复制粘贴下载链接，不如现在就把https://gitcode.com/gh_mirrors/wi/windowsdesktop克隆下来，跑一次构建，把那个离线安装包放进你的发布清单里。你会发现，部署这件事，值得被认真对待一次。
【免费下载链接】windowsdesktop项目地址: https://gitcode.com/gh_mirrors/wi/windowsdesktop
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
