简介：Windows Server 2012 R2与云服务器安装.NET Framework 3.5时，经常出现“找不到源文件”或需要手动指定“源”选项的报错，导致后续SQL Server等应用无法正常部署。这份资源针对该场景整理了一套完整的离线修复方案，内含1568个文件，压缩包约99.19MB。文件以动态链接库、可执行程序、配置文件、资源文件以及XML、SQL等类型为主，覆盖了功能启用所需的组件与依赖项，可直接将包内目录指定为源路径完成安装。其中大量dll和exe构成了核心运行组件，resx与config等负责语言资源和参数配置，sql、xml文件则对应数据库及服务清单，整体结构较清晰。目前已有10317人学习下载，亲测有效；在云主机或断网环境中尤其适用，配置好角色和功能向导后，指向本包即可跳过源文件提示，也便于IT运维人员快速定位缺失项、开展批量离线部署。 .NET 3.5 这个话题，估计每个做过 Windows 部署和软件兼容的老鸟都头疼过。看到这个settled_.net3.5install.zip文件名，我第一反应就是：又是一个被“在线安装失败”逼到墙角的人，最后用离线包 + DISM 硬生生把 .NET 3.5 塞进了系统。这个 zip 包说白了就是一套免联网的 .NET 3.5 安装资源，解压后通过系统自带的部署工具完成安装，专治各种“启用 Windows 功能失败”“错误代码 80244007”之类的疑难杂症。
这篇文章我会把这个 zip 包的用法、背后的安装原理、以及我在实际部署中踩过的坑一次讲清楚。如果你正被 .NET Framework 3.5 的安装折磨，或者只是想在 Windows 10/11 和 Server 系统上批量部署老环境，这篇内容应该能帮你少走很多弯路。
1. 认准这个 zip 包：.NET 3.5 离线安装的真实场景
1.1 为什么你需要一个离线安装包
.NET Framework 3.5 和普通的软件不一样，它不是一个能双击 Setup.exe 就直接装完的东西。在 Windows 10/11 和 Windows Server 2016 之后的系统里，它被设计成了“按需安装”的 Windows 功能组件。理论上，你只需要去“控制面板 - 启用或关闭 Windows 功能”里勾选 .NET Framework 3.5，然后等它联网下载。
但问题恰恰出在这个“联网下载”上。国内网络环境访问微软更新服务器经常不稳定，我在部署时就反复遇到过80244007、0x800F0906、0x800F081F这类错误码，都是系统在尝试连接 Windows Update 拉取组件时失败的典型症状。更麻烦的是，某些企业内网机器根本不允许访问外网，或者系统镜像被精简过，这时候在线安装基本就是死路一条。
所以社区里就有人把 .NET 3.5 的安装源文件打包成 zip 分发，比如这个settled_.net3.5install.zip。它的核心价值就是：把系统需要的那部分安装文件提前准备好，安装过程中完全不依赖网络。文件名里的settled_大概率是发布者自己加的版本标记，代表“已整理/已解决”的意思，本质内容是一样的——解压后通过 DISM 指向这些文件完成离线安装。
1.2 zip 包里到底装了什么
我下载过好几个类似的包，也自己从官方 ISO 里提取过组件。一个规范的 .NET 3.5 离线 zip 包，里面通常包含这些东西：
sxs文件夹：这是最关键的部分，里面放着那堆microsoft-windows-netfx3-ondemand-package~31bf3856ad364e35~amd64~~.cab格式的 cab 文件。sxs（side-by-side）是 Windows 组件存储的专用目录名，DISM 离线安装时指定的Source路径就是指向这个文件夹。install.bat或安装说明.txt：发布者准备的自动化脚本或操作指引，核心都是帮你执行 DISM 命令。- 可能会有
dotnetfx35.exe之类的引导程序：这是微软官方 .NET 3.5 SP1 的安装器，适合 Windows 7 时代的老系统，但在 Win10/11 上不推荐直接用。
拿到包之后先别急着双击，你首先要搞清楚的是：这个包是用来给当前正在运行的系统安装，还是用来集成到 Windows 镜像（WIM）里做批量部署。两种用法对应的操作路径完全不一样，这直接关系到后面的命令选择。
提示：解压 zip 后如果发现找不到
sxs文件夹，而是散落着一堆.cab文件，也可以直接用Source指向解压后的根目录，DISM 会递归查找。我自己更喜欢保持sxs目录结构，避免路径解析出幺蛾子。
2. 安装前的准备：先确认你的系统状态
2.1 三步判断 .NET 3.5 是否真的缺失
很多时候你觉得“没装”，其实是系统里有残留但没启用，或者装反了版本。在动手之前，我建议你先做三个检查：
第一，看功能状态。打开 PowerShell（管理员），执行：
Get-WindowsOptionalFeature -Online -FeatureName NetFx3 | Select State如果返回State : Disabled，说明组件存在但没启用，这时不需要下载任何东西，一条Enable-WindowsOptionalFeature就能解决，这也是最快的方式。如果返回State : Enabled或者提示找不到这个 FeatureName，那才需要考虑用 zip 里的源文件修复或安装。
第二，看注册表或安装目录。直接检查C:\Windows\Microsoft.NET\Framework下有没有v3.5和v2.0.50727文件夹。如果连v2.0.50727都没有，说明 .NET 3.5 组件存储是空白的，必须走完整安装流程。
第三，跑一下系统组件检查。这个步骤容易被忽略，但对稳定性很有帮助：
DISM /Online /Cleanup-Image /RestoreHealth上面这条路跑完，会先把系统组件存储里已有的文件修复或填充好。你之后再启用 .NET 3.5，成功率会高很多，而且可以排除“系统文件本身损坏导致安装失败”的干扰项。
2.2 权限和源文件的硬性要求
离线安装 .NET 3.5，权限是硬门槛。无论是 DISM 命令还是启用 Windows 功能，都必须在管理员权限下执行。我见过不少人直接在普通 CMD 窗口敲命令，报错后一脸懵，其实只是权限不够。正确姿势是：开始菜单搜“命令提示符”或“PowerShell”，右键选择“以管理员身份运行”。
另外，你需要确保 zip 包解压后没有被杀毒软件“误杀”或隔离。尤其是那些包含install.bat的包，部分安全软件会直接拦截，导致你执行安装时莫名其妙地提示找不到文件。如果你在解压后运行脚本失败，先去隔离区翻一翻。
还有一个容易被忽略的点：解压路径尽量不要带中文或空格。比如放D:\dotnet35\sxs比放D:\软件安装包\dotnet35\sxs更稳妥，后面写 DISM 命令时不容易因为转义问题报错。
3. 三种主流安装方式实操对比
3.1 首选：用 DISM 指定 sxs 源离线安装
这是我最推荐的方式，稳定、干净、可追溯。假设你已经把 zip 解压到了D:\dotnet35，并且里面有sxs文件夹，那么执行：
dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\dotnet35\sxs /LimitAccess解释一下参数含义：
/online：操作当前正在运行的操作系统。/enable-feature：启用指定的功能。/featurename:NetFx3：功能名固定是NetFx3，注意大小写无关，但别写成.NET3.5之类的。/All：启用所有父功能（依赖项），这个参数加上能避免一些连带错误。/Source：指定功能源文件的位置，指向解压后的sxs目录。/LimitAccess：限制 DISM 只从本地源获取文件，禁止它去访问 Windows Update 联网下载。这个参数是离线安装的核心，不加的话，DISM 可能在本地没找到合适文件时又跑去联网，然后把问题带回来。
命令执行后，你会看到进度条，正常情况下大概 30 秒到几分钟就完成，提示“操作成功完成”。之后重启一次系统，让环境变量彻底生效。
3.2 PowerShell 等效方案
如果你更习惯 PowerShell，也可以用下面的命令达到同样的效果：
Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source "D:\dotnet35\sxs" -LimitAccess这条命令和 DISM 版本质上是同一套底层实现，只是封装成了 cmdlet。我更推荐你把两条命令都存一下，因为有些精简版系统对 PowerShell 模块支持不全，这时回退到 DISM 反而更省事。
另外，PowerShell 里还有一种基于 Windows Capability 的写法：
Add-WindowsCapability -Online -Name "NetFx3~~~~"不过这个方式更多用在 Server 系统或较新的 Windows 11 镜像上，且它有时会忽略-LimitAccess参数去联网，反而容易触发错误。在通用性上，我还是那句老话：DISM 那条 yyds。
3.3 备用：把 cab 文件手动放入组件存储
有一个场景比较特殊：如果你不是给当前系统安装，而是想把 .NET 3.5 集成到一个 WIM 镜像里（比如批量装机时做自定义 ISO），上面的命令就不适用了。这时候需要用到 DISM 的镜像挂载功能，大致流程是：
dism /mount-wim /wimfile:D:\install.wim /index:1 /mountdir:D:\mount dism /image:D:\mount /enable-feature /featurename:NetFx3 /All /Source:D:\dotnet35\sxs /LimitAccess dism /unmount-wim /mountdir:D:\mount /commit注意第二个命令的/image参数指向挂载目录，而不是/online。这个操作是纯离线对镜像进行操作，适合系统封装、企业批量部署的场景。我自己做模板机时就是这么干的，装完系统直接自带 .NET 3.5，省去了每台机器单独装的痛苦。
如果你拿到的 zip 里没有sxs文件夹，只有单独的 cab 文件，理论上你也可以解压后用上面同样的/Source指向那个解压目录。只要里面能找到microsoft-windows-netfx3-ondemand-package...cab，DISM 就能识别，不一定非要完整的sxs结构。但前提是解压路径别带空格，否则部分版本的系统解析 Source 时会翻车。
提示：
.NET 3.5安装失败时，最直接的排查办法是查看 CBS 日志，路径在C:\Windows\Logs\CBS\CBS.log。用记事本打开后搜NetFx3关键字，错误原因会记录得很详细，比盲猜靠谱得多。
4. 常见错误与排查技巧实录
4.1 错误 80244007、0x800F0922、0x800F081F 怎么破
这三个是 .NET 3.5 安装失败时的高频错误码，我挨个说下原因。
80244007几乎就是“无法连接 Windows Update”的代名词，常见于服务器系统（尤其是 Server Core 模式）或启用了 WSUS 的企业机器。解决办法就是老老实实用离线包，DISM 命令里必须带/LimitAccess，强制不走网络。
0x800F081F表示系统在指定的Source路径里找不到可以用的源文件。遇到这个，先检查路径对不对、cab 文件是不是完整的。我踩过一次坑：从国内某个镜像站下载的包，cab 文件本身是损坏的，DISM 执行到一半就报这个错。排查方式很简单，用命令手动检查 cab 是否能正常读取：
dism /get-packageinfo /packagepath:D:\dotnet35\sxs\microsoft-windows-netfx3-ondemand-package~31bf3856ad364e35~amd64~~.cab如果这条命令报错，说明源文件有问题，重新下载解压即可，别在系统层面死磕。
0x800F0922通常和系统分区空间不足有关，或者是在 WinRE 环境下安装导致的。解决思路就是清理磁盘空间，并确保你是在完整 Windows 系统下操作，而不是用了恢复环境。
4.2 zip 包本身的问题：解压失败和密码保护
settled_.net3.5install.zip说到底是个压缩包，所以它也会遇到 zip 文件最常见的两类问题：解压失败和带密码。
先说解压失败。如果你用系统自带的“全部解压”一直提示“无法完成解压”，或者报invalid zip archive错误，八成是下载不完整。我建议下载完先看文件大小，然后校验压缩包的哈希值，和发布者给的 MD5 或 SHA-256 对比一下。没有哈希值的话，就用 7-Zip 打开测试一下，它会明确提示“有损坏的文件头”之类的信息。
再说带密码。有些发布者会把包加密，密码一般会写在原始分享页或释义文档里，注意区分“打开密码”和“解压密码”。这类 zip 密码移除工具网上搜得到，但我想多说一句：遇到加密包，最好的方式是回到源出处找密码，而不是花时间暴力破解。原因很简单，你拿到一个加密的 .NET 3.5 安装包，无法确认里面的文件是否被篡改，万一附加了不明脚本，运行起来就是给自己找麻烦。
4.3 安装成功后程序还是提示缺少 .NET 3.5
这个场景估计不少人都遇到过：DISM 明明提示成功了，结果打开某个老软件还是弹窗说缺少 .NET Framework 3.5。我一开始也困惑，后来发现原因出在“功能启用不等于运行环境完整”上。
解决办法分两步。第一步，确认.NET Framework 3.5包含的 WCF 和 WF 子功能是否也一起启用了。DISM 命令里我特意加了/All参数，就是为了带上这些子功能。如果你之前是用控制面板勾选的方式安装，记得检查：
dism /online /get-featureinfo /featurename:NetFx3看一下WCF-HTTP、WCF-NonHTTP这些子功能是否处于“已启用”状态。如果没启用，单独执行：
dism /online /enable-feature /featurename:WCF-HTTP /All dism /online /enable-feature /featurename:WCF-NonHTTP /All第二步，检查系统是否正确识别了 .NET 3.5 的运行时。在“控制面板 - 程序和功能 - 已安装更新”里，或者用命令行：
reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v Install如果看到Install的值为1，说明系统层面已经认可。这时候程序还报错，就要考虑是不是程序本身引用了更老版本的运行库（比如 ASP.NET 的独立安装文件），那属于另一个话题了。
4.4 延长话题：WSL 安装慢和 pip 离线安装的启发
这次搜索热词里带了不少wsl --install 太慢、pip install 离线包之类的内容，虽然它们和 .NET 3.5 安装不是一件事，但背后的思路惊人的一致：能离线就不要在线。WSL 安装慢同样是因为网络无法稳定访问微软源，解决办法就是下载离线包、手动wsl --install或导入已下载的发行版 tar 包。pip 装包失败时也是一样，换成pip install 本地whl文件，加--no-index --find-links指定本地目录，逻辑和 DISM 的/Source+/LimitAccess如出一辙。
所以说白了，Windows 生态里这类“在线安装器卡死”的问题，离线包 + 手动指定源就是通用解药。你把 .NET 3.5 这个安装原理吃透了，以后再遇到 WSL、pip、甚至 Linux 的yum install源问题，都会本能地想到同一个解法。
5. 安装完成后的验证与收尾细节
5.1 如何确认安装真的成功了
安装完别急着关命令行，花 30 秒验证一下。最直观的方式：
reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v Install reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v SP如果Install是1，SP是1，说明 .NET 3.5 SP1 已经就位。不放心的话，再用 .NET Framework 自带的版本检测工具或者直接打开一个依赖 3.5 的软件试试。我习惯上把这一步叫做“确认收尾”，因为任何一个部署环节，验证永远是最容易被跳过但最不该跳过的。
5.2 系统更新前后的注意事项
如果你是在系统更新之后才安装的 .NET 3.5，我提醒一句：安装完成后最好再执行一次。
DISM /Online /Cleanup-Image /RestoreHealth这条命令会把新安装组件与当前系统文件做一次完整性校验，把潜在的冲突提前清掉。另外，如果你后续打算用系统自带的“重置此电脑”或封装镜像，建议先把 zip 包里的sxs文件夹保留到本地（比如C:\dotnet35\sxs），下次重建环境时直接原地操作，比重新下载快得多。
5.3 小技巧：把离线包变成你的装机标配
最后分享一个我的个人习惯。每装完一台 Windows 机器，我会把settled_.net3.5install.zip这类包解压后和install.wim、常用运行库一起放进一个“装机工具箱”文件夹。这样做的好处是：下次不管遇到什么环境，我都有一套不依赖外部网络的部署方案。遇到他人的电脑出问题，拿 U 盘就能解决，不用临时翻网页、下工具、等下载。
提示：任何 .NET 3.5 离线包，建议只从可信渠道获取，拿到后先解压看一眼文件列表。正常的包里只应该有微软官方 cab 文件、可选的 bat 脚本和说明文档。如果发现任何可疑的 exe 或不明脚本，先别执行，用杀毒软件扫一遍再决定。
我在实际部署中体会最深的一点是：很多 .NET 3.5 安装失败，根本不是技术难度问题，而是对“功能组件安装”这件事理解错了。它不是一个软件安装，而是一次系统功能扩展。把思维切换过来，记住“离线源 + DISM + 看日志”这套组合拳，你就能解决 90% 的 .NET 3.5 安装问题。剩下那 10%，就交给 zip 包的完整性和网络环境去背锅吧。
本文还有配套的精品资源，点击获取
