如何亲手构建 .NET Windows Desktop RuntimeWindows 桌面应用部署的完整指南【免费下载链接】windowsdesktop项目地址: https://gitcode.com/gh_mirrors/wi/windowsdesktop在用户电脑上看到缺少 .NET 桌面运行时的报错是每个 Windows 桌面开发者都不愿面对的瞬间。你本地运行完美的 WinForms 程序一到用户手里就水土不服。问题往往不在代码而在那个用户没有、也说不清是什么的运行时环境。而这个运行时从哪来、如何被组装成安装包正是 .NET Windows Desktop Runtime 这个开源仓库要回答的问题。这篇文章不打算复述官方文档而是带你沿着安装包这条线索一路追到它的源码现场。看完你会明白Windows 桌面应用部署这件事远比想象中更可控。 一次部署事故逼我追查安装包的身世事情要从一次客户现场说起。对方电脑是 Windows 10 精简版双击我们的安装包引导程序弹了一行提示然后静默退出。群里一片慌乱最后排查结果是目标机器上残留了一个旧版本的运行时与安装包版本不一致。那一刻我突然意识到自己天天分发这个运行时却从没搞清楚它内部长什么样。于是我把安装包逆向拆开顺着蛛丝马迹找到了它的源码仓库——wi/windowsdesktop。它镜像自 .NET 官方仓库代码基于 MIT 许可证完全开源。仓库的 README 第一句话就交代了身份这里存放着为所有受支持平台构建 .NET Windows Desktop Runtime 的代码。换句话说它不是 WinForms 或 WPF 框架本身而是把这些框架的成果组装成可安装运行时的地方。这个仓库到底在构建什么很多人以为装到用户机器上的运行时是某个团队闭门造出来的二进制其实它的每个零件都在开源仓库里可见。整个仓库的核心交付物可以分成四块模块路径干什么用安装包bundlesrc/windowsdesktop/src/bundle/用 WiX 制作带引导程序的 .exe 安装包含多语言界面运行时包sfxsrc/windowsdesktop/src/sfx/产出 Targeting Pack 与 Runtime Pack 两类 NuGet 包兼容包src/Microsoft.Windows.Compatibility/把 .NET Framework 时代的 API 带到 .NET 与 .NET Standard自动化测试src/windowsdesktop/tests/校验打包产物的完整性与可安装性顺着这张表看下去你会发现部署并不是玄学而是一条可以被构建、被测试、被审计的流水线。从源码到安装包一条完整的构建链路为了讲清楚我们给这个安装包写一份人生简历。它的一生大致经历四个阶段框架源码WinForms 与 WPF 的代码分别维护在各自的仓库里持续编译产出程序集组装成包sfx 模块把程序集按约定整理成两类包——编译期用的 Targeting Pack和运行期用的 Runtime Pack打成安装包bundle 模块登场用 WiX v5 把上述内容连同引导程序一起压缩成一个自解压安装包落地用户机器用户双击后引导程序检查架构、探测已有安装、弹出对应语言的界面完成全新安装或版本升级。有意思的是最后一步。bundle.wxs 里定义了固定的 UpgradeCode并声明了与旧版本的升级关系从而支持从预览版到 RC、再到正式版及后续服务版本的平滑升级路径。客户那台机器的问题本质上就是升级关系没被正确满足。5 分钟跑通本地构建理解到这里你大概率想亲手验证一把。整个过程并不复杂只需两步。第一步克隆仓库git clone https://gitcode.com/gh_mirrors/wi/windowsdesktop第二步准备构建环境。仓库采用 .NET Arcade 统一构建体系你只需要安装对应版本的 .NET SDK版本要求见仓库根目录的 global.json然后调用构建脚本即可——Windows 下是 eng/common/CIBuild.cmdLinux 与 macOS 下是 eng/common/cibuild.sh。如果想跳过全量构建、只盯着某个产物也可以直接查看具体工程安装包对应 src/windowsdesktop/src/bundle/bundle.wixproj运行时包对应 src/windowsdesktop/src/sfx/ 下的两个 sfxproj 工程。bundle 与 sfx两个模块的分工如果说整条流水线是一场接力赛sfx 和 bundle 就是最后两棒各管各的绝活。sfx把程序集装进标准容器。它同时产出引用包与运行时包并明确声明支持 win-x64、win-x86、win-arm64 三种安装架构。WinForms 的打包与校验逻辑被抽成了独立的 WindowsForms.Packaging.targets方便单独维护与复用。bundle决定用户的第一印象。这是离用户最近的一层细节也最讲究。安装界面内置 14 种语言的本地化文件theme 目录下 14 个语言文件夹简体中文、繁体中文、英语、日语、韩语、德语、法语等都在其中安装时会做架构检测防止同一台机器上 x86 与 x64 运行时路径互相覆盖还带软件识别标签方便企业做资产盘点。一句话总结分工sfx 负责装得对bundle 负责装得顺。谁应该关心这个仓库也许你不是微软的工程师但只要你的处境符合下面任意一条这个仓库就值得你花半小时逛一逛。做 Windows 桌面应用分发你终于可以解释清楚用户机器上那个运行时到底是什么以及升级策略为何重要需要定制安装体验bundle.thm 与 theme 目录就是给你准备的改文案、换界面都是可编程的维护企业内网镜像理解构建链路后为离线环境制作内部运行时包不再是黑盒操作想深入 .NET 打包机制Arcade 构建体系、WiX 工程、NuGet 包校验这里就是活教材。顺带一提仓库里还有一套 NuGetArtifactTester 测试体系专门验证打包出来的产物。对发布即翻车深有体会的团队这套思路值得抄作业。你可能还想问的三个问题它和 .NET Framework 是什么关系两者是完全不同的运行时。这个仓库构建的是 .NETCore 时代起的统一版本支持与旧版 .NET Framework 并存安装互不干扰。它支持哪些框架核心面向 Windows Forms 与 WPF。另外 Microsoft.Windows.Compatibility 兼容包还补充了大量此前仅在 .NET Framework 中提供的 API让迁移老项目的成本进一步降低。我自己能改它吗可以。代码基于 MIT 许可证开源贡献规范写在 CONTRIBUTING.md 里安全漏洞有专门的提交通道。它和 WinForms、WPF 仓库一起构成了完整可审计的桌面技术栈。从用运行时到懂运行时回到开头那次部署事故。如果当时我就了解 UpgradeCode 与升级路径的含义排查会快得多如果早点读过 bundle.wxs 里的架构检测逻辑也不会在精简版系统上栽跟头。这就是这个仓库最大的价值它把部署从一门玄学变成了一门手艺。当你亲手克隆、构建、翻看那一行行打包逻辑之后再回看用户机器上那个熟悉的安装界面你会知道——它不再是一个神秘的黑盒而是一条你全程走过的路。动手吧clone 下来跑一次构建或者在 issue 里记录你的发现。下一次部署出问题时你将是团队里第一个说出我知道为什么的人。【免费下载链接】windowsdesktop项目地址: https://gitcode.com/gh_mirrors/wi/windowsdesktop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
