10分钟搞定 claude-desktop-buddy：M5StickC Plus 固件烧录与 BLE 配对快速入门
2026/10/2 21:36:28
1. 先弄清楚：为什么 Win10/11 上装个 .NET 3.5 要绕这么多弯
1.1 .NET 3.5 和 4.x 不是升级关系，而是两套并存的运行时
很多人第一次碰到这个问题时都会有同样的困惑：我机器上明明已经装了 .NET Framework 4.8，为什么装个老软件还提示缺少 .NET Framework 3.5？这其实是个认知偏差。.NET Framework 3.5（严格说是 2.0/3.0/3.5 这一条线）和 .NET Framework 4.x 在微软的架构里是两条平行的运行时分支，版本号大小并不代表后者包含前者。4.x 的 CLR 版本是 4.0，3.5 的 CLR 版本是 2.0，二者在注册表、GAC（全局程序集缓存）、程序集绑定策略上都是独立的一套。
这就解释了一个现象：你装了一个 2010 年前后开发的老工具，它编译时目标框架写的是 .NET Framework 2.0 或 3.5，运行时就会去加载 2.0 版的 CLR。如果系统里只有 4.x，这个加载请求就会直接失败，弹窗一般写“此应用程序需要 .NET Framework 3.5”或者更笼统的“应用程序无法正常启动”。所以这不是系统坏了，也不是软件写错了，纯粹是运行时不匹配。
我在内网环境里遇到过最典型的一类场景：一套老旧的 MES 采集客户端、某个设备厂商配套的配置工具、还有一些 ActiveX 控件依赖的老式上位机软件，它们清一色依赖 2.0/3.5 这条线。你没法让厂商重新编译，只能把 3.5 运行时装回去。这就是“离线安装 .NET Framework 3.5”这个需求长期存在、并且反复被搜索的根本原因。
1.2 按需功能机制：微软为什么把源文件从系统里抽走了
从 Windows 8 开始，微软改变了功能组件的分发方式，把 .NET Framework 3.5 从“默认随系统安装”改成了按需功能（Feature on Demand，简称 FoD）。也就是说，系统镜像里仍然保留了 3.5 的运行时代码，但只是以“存根”形式躺在组件存储（WinSxS）里，真正完整的二进制文件被抽出来单独放在安装介质的sources\sxs目录下，需要时才去取。
这么设计有两个目的。一是压缩系统体积，3.5 的完整文件包大概 200MB 出头，对企业批量部署来说这是笔不小的开销；二是强制系统从可信源获取组件，保证文件签名和版本一致性。代价就是：联网机器上你点一下“下载并安装此功能”，系统会悄悄去 Windows Update 拉文件，用户无感；但内网、断网、或者被组策略限制了更新源的机器上，这个自动下载就卡死了，你会看到进度条转半天然后报 0x800F0906 或者 0x800F081F。
理解了这一点，后面所有的操作思路就顺了：我们要做的，无非是手动把sources\sxs里的源文件喂给系统的 DISM 组件安装引擎，绕过它自己找不到源的问题。所有方法本质都是这一件事，只是喂法不同。
1.3 什么情况下你必须走离线这条路
我把需要离线安装的场景归纳成四类，你可以对号入座：
- 完全隔离的内网/工控网：机器物理上不连外网，Windows Update 走不通，装 3.5 只能本地给源。
- 企业域环境且更新源被托管：IT 把更新源指向了内部 WSUS 或 Configuration Manager，而服务器上并没有同步 .NET 3.5 的按需功能包，客户端就会报 0x800F0954。这个错误码在企业里非常高频。
- 精简版/定制版镜像：一些第三方封装的系统镜像删掉了
sources\sxs或者裁掉了组件存储，导致在线下载也失败。 - 批量部署：几十上百台机器要一次性装好，靠一台台点图形界面不现实，必须走脚本化。
2. 动手前的准备：源、权限、版本三件事缺一不可
2.1 找到和你系统版本完全匹配的 sxs 源文件
这一步是整件事的地基，也是最容易翻车的地方。sources\sxs文件夹里的组件包是和系统版本强绑定的。Win10 22H2 的 sxs 拿去装 Win11 23H2，DISM 大概率会报“源文件版本不匹配”或者直接返回 0x800F081F。这不是玄学，是因为组件包的清单文件里记录了目标系统的构建号和语言版本。
正确的做法是：
- 先在目标机器上确认版本。按
Win + R输入winver，或者用命令systeminfo | findstr /B /C:"OS Name" /C:"OS Version"，记下构建号，比如 19045（Win10 22H2）、22631（Win11 23H2）、26100（Win11 24H2）。 - 去微软官方渠道下载同版本、同语言、同架构的 ISO。中文系统就用中文 ISO，x64 系统就用 x64 镜像，别混。
- 如果你手头只有一台机器的 ISO，想给另一台不同版本的机器装，抱歉，这条路走不通，老老实实找对应版本的镜像。
注意：热词里提到的“Windows 11 专业版 Insider Preview 29667.1000 无法安装 .NET Framework 3.5 SP1”，本质就是预览版镜像的 sxs 源与已安装系统版本存在差异，或者预览版本身调整了按需功能的打包方式。遇到预览版装不上的情况，优先尝试用同构建号的官方 ISO 取源，如果仍然失败，先考虑回退到正式发布版本，别在预览版上死磕。
2.2 挂载镜像或解压 ISO 的正确姿势
拿到 ISO 之后，有两种取源方式。
第一种是双击挂载，Windows 8 以后原生支持，挂载后会在“此电脑”里出现一个虚拟光驱盘符，比如E:。这种方式的好处是随用随挂，用完右键“弹出”即可，不占额外磁盘空间。
第二种是解压。用 7-Zip 或者 WinRAR 把 ISO 里的sources\sxs整个目录解压到本地磁盘，比如D:\sxs。这种方式适合反复部署的场景，也方便放到共享目录给其他机器用。注意解压时保持目录结构，别把里面的 .cab 文件散落一地。
如果你要在脚本里自动挂载，PowerShell 会更顺手：
# 挂载 ISO $mount = Mount-DiskImage -ImagePath "D:\ISO\Win11_23H2_zh-cn.iso" -PassThru # 获取盘符 $drive = ($mount | Get-Volume).DriveLetter Write-Host "ISO 挂载到 $drive 盘" # 源路径就是 "$drive`:\sources\sxs" # 用完卸载 # Dismount-DiskImage -ImagePath "D:\ISO\Win11_23H2_zh-cn.iso"2.3 权限与前置检查清单
在敲命令之前，我习惯先过一遍这几项检查，能省掉后面一半的报错：
| 检查项 | 判断方法 | 不通过时的处理 |
|---|---|---|
| 管理员权限 | 命令提示符标题栏是否显示“管理员” | 用管理员身份运行 CMD/PowerShell |
| 源路径存在 | dir D:\sources\sxs是否有 .cab 文件 | 检查挂载是否成功、ISO 是否完整 |
| 系统版本匹配 | winver对比 ISO 版本 | 换对应版本 ISO |
| 更新源策略 | gpresult /h report.html查看是否指向 WSUS | 临时调整组策略或用 LimitAccess 参数 |
| 磁盘空间 | 系统盘剩余是否大于 2GB | 清理 CBS 临时文件释放空间 |
还有一点常被忽略：Windows Modules Installer 服务（TrustedInstaller）必须是运行状态。这个服务负责组件安装，被优化工具禁掉或者改成手动且未启动时，DISM 会直接报错。用sc query trustedinstaller看一眼，如果不是 RUNNING，就net start trustedinstaller拉起来。
3. 方案一：DISM 挂载镜像离线安装（单机首选）
3.1 完整命令流程与逐参数解释
这是我最推荐的单机方案，成功率高、可脚本化、日志清晰。完整流程如下：
:: 1. 挂载 ISO 后假设盘符为 E:，执行启用 dism /online /enable-feature /featurename:NetFx3 /All /Source:E:\sources\sxs /LimitAccess :: 2. 等待进度到 100%，查看结果 dism /online /get-featureinfo /featurename:NetFx3逐参数拆解一下，很多人出错就是没搞懂这几个参数：
/online：操作当前运行的系统，区别于/image操作离线镜像。/enable-feature：启用功能，对应这里的按需功能。/featurename:NetFx3：功能内部名就是NetFx3，不是NetFramework35，别写错。/All：启用该功能的所有父级依赖。如果不加，某些系统上会因为父功能未启用而失败。/Source:E:\sources\sxs：指定源文件路径，直指 sxs 目录。/LimitAccess：关键参数。它告诉 DISM 不要回退到 Windows Update 去联网找文件，只用你指定的本地源。不加这个参数，系统可能先尝试联网，在内网环境下会卡很久然后超时。
PowerShell 版本的等价写法：
Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source "E:\sources\sxs" -LimitAccess3.2 执行过程记录与结果验证
正常执行时你会看到这样的输出节奏：先显示“正在部署映像服务和管理工具”，然后“正在安装功能”，进度条从 0 走到 100，最后提示“操作成功完成”。整个过程视磁盘性能大概 30 秒到 2 分钟。
装完之后一定要验证，别看到“成功”就完事。验证两步：
:: 第一步，功能状态应为 Enabled dism /online /get-featureinfo /featurename:NetFx3 :: 第二步，注册表确认安装版本 reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v Install注册表里Install值为1才算真正落地。有些情况下 DISM 报成功，但注册表没写进去，那多半是组件存储有损坏，需要先修复再重装。
3.3 常见失败反馈与即时应对
如果命令返回错误，先别急着重试，看一眼错误码：
- 报0x800F081F：“找不到源文件”。九成是路径写错了，或者 ISO 版本不匹配。仔细核对
E:\sources\sxs这个路径下确实有一堆.cab文件。 - 报0x800F0906：功能文件下载失败。通常发生在没加
/LimitAccess且网络不通的情况。 - 报0x800F0954：组策略限制，系统不允许从本地源安装。这个后面第 6 章专门讲。
- 命令直接返回“拒绝访问”：没提权，重新以管理员运行。
提示：DISM 执行过程中不要中途 Ctrl+C，会留下半安装状态，后续清理很麻烦。遇到卡住，耐心等到超时提示。
4. 方案二：图形界面 + 组策略指定本地源
4.1 组策略那个开关到底改了哪里
如果你不习惯命令行，或者需要给一批机器统一配置，可以走“控制面板 + 组策略”这条路。核心开关在：
计算机配置 → 管理模板 → 系统 → 指定可选组件安装和组件修复的设置
把这个策略设为“已启用”，然后在“备用源文件路径”里填入你的 sxs 路径，比如D:\sxs或网络共享\\fileserver\sxs。下面还有个“从不尝试从 Windows 更新下载修复内容”的复选框，内网环境建议勾上。
这个策略本质上就是往注册表里写了一个键值：
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing" /v LocalSourcePath /t REG_SZ /d "D:\sxs" /f reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing" /v RepairContentServerSource /t REG_DWORD /d 2 /f其中RepairContentServerSource的值 2 表示“仅使用本地源”。理解了这一点，你就知道为什么有些企业机器上裸跑 DISM 会报 0x800F0954——因为这个键被设成了别的值，把本地源给屏蔽了。
4.2 图形化勾选的实操步骤
配置好策略之后，操作就变得很傻瓜化：
- 打开“控制面板 → 程序和功能 → 启用或关闭 Windows 功能”。
- 找到“.NET Framework 3.5 (包括 .NET 2.0 和 3.0)”这一项，勾上。
- 点击确定，系统会自动去读组策略里配置的本地路径取文件。
相比 DISM，这个方式的好处是能被批量组策略统一下发，一次配置，全域生效，用户自己点一下就行。坏处是它的报错信息非常笼统，出问题只会给一个“Windows 无法完成请求的更改”，错误码要去事件查看器或者CBS.log里翻。所以我在纯命令行环境里更倾向 DISM，图形界面适合给最终用户或桌面运维用。
4.3 两种方案怎么选
| 维度 | DISM 命令行 | 图形界面 + 组策略 |
|---|---|---|
| 适用场景 | 单机、脚本、排障 | 域环境批量、终端用户 |
| 报错信息 | 有明确错误码 | 提示模糊，需查日志 |
| 可脚本化 | 完全支持 | 策略配置可脚本化 |
| 对源路径的依赖 | 每次命令都指定 | 一次配置长期生效 |
| 学习成本 | 需要记参数 | 点几下就行 |
我个人的习惯是：排障和单机装一律用 DISM，企业批量用组策略配源 + 脚本触发，两者结合着来。
5. 方案三：企业批量部署的共享源与脚本化
5.1 搭一个只读共享的 sxs 源目录
如果域里有几十台机器要装，一台台插 U 盘不现实。标准做法是在文件服务器上放一份 sxs：
\\fileserver\deploy$\sxs把对应版本 ISO 里的sources\sxs拷进去。共享权限给Domain Computers读取即可，不要给写权限，防止误删。然后通过组策略把LocalSourcePath指向这个 UNC 路径。
这里有个细节值得说：UNC 路径在系统安装早期阶段登录会话没建立时可能访问不到，所以如果是在部署镜像阶段（比如 MDT/SCCM 的 OSD 流程里）装 3.5，更稳妥的方式是把 sxs 直接放进部署包的本地目录，由部署脚本复制到目标机本地磁盘再执行 DISM，避免依赖网络会话。
5.2 批量静默脚本与执行时机
我在实际项目里用的批量脚本大概长这样，改改路径就能用：
# 检查是否已安装 $installed = (Get-WindowsOptionalFeature -Online -FeatureName NetFx3).State if ($installed -eq "Enabled") { Write-Host "NetFx3 已安装，跳过" exit 0 } # 从共享复制到本地临时目录，避免网络中断 $src = "\\fileserver\deploy$\sxs" $dst = "C:\Temp\sxs" robocopy $src $dst /E /NFL /NDL /NJH /NJS /NP | Out-Null # 执行安装 $result = Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source $dst -LimitAccess -NoRestart if ($result.RestartNeeded) { Write-Host "安装完成，需要重启" } else { Write-Host "安装完成，无需重启" } # 清理 Remove-Item $dst -Recurse -Force这个脚本有两个设计考量：一是先复制到本地再安装，因为 DISM 读网络路径时如果网络抖动会直接失败，本地读则稳定得多；二是先检查再安装，避免重复操作浪费时间和触发不必要的重启。
5.3 通过 Intune 或配置管理工具下发
现代企业越来越多用 Intune 这类云管理平台。思路是一样的，把这个 PowerShell 脚本打包成 Win32 应用，检测规则用注册表HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5\Install = 1，sxs 源文件作为包内容一起分发。安装上下文务必选“系统”，因为 DISM 需要系统权限。
SCCM/Configuration Manager 用户的话，更简单的办法是用“运行命令行”任务序列，直接在 OSD 阶段调用 DISM，源路径指向部署包解压目录。这个在传统制造业内网环境里是最常见也最稳的做法。
6. 报错速查表与实战排查思路
6.1 常见错误码对照
| 错误码 | 含义 | 主要原因 | 解决方向 |
|---|---|---|---|
| 0x800F0906 | 无法下载源文件 | 无网络也无本地源 | 加 /Source 和 /LimitAccess |
| 0x800F081F | 找不到源文件 | 路径错、版本不匹配 | 核对路径和系统版本 |
| 0x800F0954 | 策略禁止本地源 | 更新源指向 WSUS | 改 LocalSourcePath 或组策略 |
| 0x800F0907 | 更新被策略阻断 | 同上 | 检查 Servicing 策略 |
| 0x800F0922 | 组件存储损坏 | WinSxS 异常 | DISM /Online /Cleanup-Image /RestoreHealth |
| 0x80073712 | 组件存储缺失 | 系统文件被裁 | 用 sfc /scannow 修复 |
| 0x800F0950 | 安装被中止 | 杀软拦截或磁盘满 | 关杀软临时、清磁盘 |
6.2 疑难案例：策略受限与组件损坏
我遇到最多的是0x800F0954。现象是：明明给了本地源，DISM 还是报错，说系统不允许从本地安装。原因就是前面提到的RepairContentServerSource被设成了 1（仅 Windows Update）或 3（WSUS），本地源被排除在外。解决方式是临时改注册表：
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing" /v RepairContentServerSource /t REG_DWORD /d 2 /f改完重跑 DISM 一般就通了，装完可以再改回原值。企业环境里记得跟 IT 沟通，因为这是全局策略，改了会影响其他组件的修复行为。
另一个坑是组件存储损坏。日志里会看到类似Component store is corrupted的记录。这种情况下再怎么喂源都没用，得先修存储：
DISM /Online /Cleanup-Image /CheckHealth DISM /Online /Cleanup-Image /ScanHealth DISM /Online /Cleanup-Image /RestoreHealthRestoreHealth需要联网或指定本地源。修复完成后再装 NetFx3，成功率会大幅提升。
6.3 学会看日志，比记错误码更管用
错误码只是入口，真正的根因都在日志里。两个日志位置要记住：
C:\Windows\Logs\CBS\CBS.log：组件安装过程，最详细。C:\Windows\Logs\DISM\dism.log：DISM 命令自身的日志。
看 CBS.log 的时候，用findstr过滤关键字效率最高：
findstr /c:"NetFx3" C:\Windows\Logs\CBS\CBS.log > %userprofile%\Desktop\netfx3_log.txt日志文件动辄几十兆，直接打开会卡死。过滤出和 NetFx3 相关的行，看error或者fail附近的上下文，往往能精准定位到是“源路径无权限”还是“某个 cab 包校验失败”。
7. 我踩过的坑和几条实用心得
7.1 版本、语言、架构，三样必须对齐
这个坑我踩过不止一次。有次拿英文版 Win10 的 sxs 去装中文系统，DISM 报了个含糊的 0x800F081F。当时以为是路径问题，排查半天才发现是语言包不匹配。sources\sxs里的 cab 包是按语言分组织的，中文系统必须用中文 ISO 的源。同理，x64 系统别用 x86 的源。最简单粗暴的核对办法：把 ISO 里的 sxs 和你系统C:\Windows\servicing\Packages里已经存在的 3.5 相关包版本号对比一下，看是否一致。
7.2 别用来源不明的“一键安装包”
热词里经常出现各种“纯净版 3.5 安装包下载”“一键包”。我强烈不建议在正经环境里用这些东西。原因很简单：.NET 3.5 的安装强依赖组件清单，第三方打包的所谓“万能包”往往是某个特定版本的 cab 集合，装到版本不对的机器上轻则失败，重则污染组件存储导致后续系统更新都出问题。最干净的做法永远是：用自己的官方 ISO 取源，多花五分钟下载镜像，能省掉后面几小时的排障。
7.3 装完之后注意老软件的绑定策略
装完 3.5 不代表老软件就一定能跑。有些工具还会依赖具体的 2.0 版本或者某个补丁级别。我遇到过装好了 3.5，但程序仍然报错的情况，最后发现是配置文件里supportedRuntime锁死了一个很老的补丁号。这种就得具体看程序的 config 文件，一般不用改系统，改一下应用侧的配置就行。如果程序本身是 32 位的，还要确认 32 位和 64 位两套注册表分支都写对了，可以分别查一下：
reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v Install reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\NET Framework Setup\NDP\v3.5" /v Install7.4 一份可以随身带的多版本源包
如果你管着一批版本各异的机器，我建议在移动硬盘或内网共享上按版本归档 sxs：
deploy$\dotnet35\ ├── win10_19045_x64_zh-cn\sxs ├── win10_19045_x86_zh-cn\sxs ├── win11_22631_x64_zh-cn\sxs └── win11_26100_x64_zh-cn\sxs配上前面那个 PowerShell 脚本，脚本里根据[System.Environment]::OSVersion.Version.Build自动选对应目录，基本能做到“插上就能装，不用现场找镜像”。这套东西我在几个隔离网项目里用了两年多，把原本要折腾半天的活压缩到两三分钟，后续再遇到装 .NET 3.5 的场景，直接复用就行。另外提醒一句，归档时记得同时保留对应版本的官方镜像原始文件，万一遇到组件存储修复需要源的情况，还能顶上用。