微软的集安.NET安装包，这几年越来越像一个谜。装包你从官网下载一个“Runtime”，集安装完一看，装包C盘里躺着七八个版本号各异的集安文件夹，从4.5到4.8，装包又从6.0到8.0，集安互不干涉，装包各占一块地盘。集安这不是装包微软懒，而是集安他们故意这么干的。

早期.NET Framework时代，装包事情简单得多。集安Windows XP上装个3.5，装包Vista上装个3.5，集安Win7自带3.5.1，Win10直接预装4.8。一个系统对应一个框架，程序跑不起来就装对应的包，装完万事大吉。坏就坏在版本升级太频繁，4.0刚出没多久就出4.5，4.5还没捂热又冒出4.6，每个版本还只能覆盖旧版，不能共存。开发者被迫追着版本跑，用户被“需要安装.NET Framework 4.7.2”的弹窗烦到崩溃。

微软后来总算想通了。从.NET Core开始，他们彻底改头换面，把框架做成了“可并行安装”的独立运行时。你机器上同时挂着.NET 6和.NET 8，互不干扰，每个应用自己指定用哪个版本。好处是彻底告别了“装新版本会不会搞坏老程序”的恐惧，坏处是——下载页面变得极其混乱。官方下载中心列着.NET Runtime、ASP.NET Core Runtime、Desktop Runtime、SDK，每个又有x86、x64、Arm64之分。普通用户根本分不清该下哪个，干脆把整个列表全装一遍。

我见过最极端的案例，是同事的电脑上同时存在.NET Framework 4.5、4.6、4.7、4.8，外加.NET Core 2.1、3.1、5.0、6.0、7.0，总共九个版本。磁盘空间倒不心疼，真正要命的是系统更新时，Windows Update会反复推送不同版本的补丁，装完一个又提示另一个，循环往复。后来我帮他写了个批处理脚本，把不用的版本全卸载了，只留4.8和最新的.NET 8，世界瞬间清净。

话说回来，微软把安装包做得这么碎，背后也有苦衷。老框架承载着大量企业级遗留系统，不能轻易抛弃；新框架又必须轻装上阵，支持容器和云原生。两边不能合并，只能并行。可苦了用户——每台新电脑都得手动去官网挑挑拣拣，稍不留神就下载了错误的包。好在微软后来推出了“Windows桌面运行时合集包”，把Desktop Runtime、ASP.NET Core Runtime和.NET Runtime打包成一个文件，总算降低了一点选择难度。

但真正解决问题的，还得靠应用开发者自己。如果你写的是自包含部署的应用，发布时把运行时一并打包进去，用户根本不用装任何东西。这招虽然让安装包体积暴增几十MB，但换来了“双击即用”的爽快体验。我自己的小工具就采用这种方式，发给朋友时附带一句“不用装任何环境”，对方往往一脸惊讶——这年头，能免安装跑起来的程序太稀罕了。

说到底，.NET安装包的历史浓缩了微软这二十年的挣扎与妥协。从大一统到碎片化，再从碎片化到“按需自取”，每一步都是被生态逼出来的。你没法指望微软哪天搞出一个“全版本一键安装”的终极方案，毕竟版本间的兼容性测试成本摆在那儿。与其抱怨安装麻烦，不如学聪明点：普通用户认准“最新版x64”下载，开发者尽量用自包含发布。至于那些陈年旧版，该卸就卸，别让它们躺在硬盘里吃灰了。