简介：VS平台工具集.zip是一份面向Visual Studio开发者的工具集整合包，主要解决IDE自带MSBuild组件缺失或版本不匹配导致的构建报错问题。包体共2000个文件，压缩后112.25MB，其中1158个dll、270个pdb、167个targets、158个props等构成编译与构建核心，502个xaml和177个xml用于界面与配置，48个exe包含MSBuild.exe等可执行程序，适合需要自定义构建流程或修复VS编译环境的初中级开发者使用。安装时需将解压内容放置到C盘Program Files (x86)\MSBuild目录，覆盖后重启VS即可生效。已有6418人学习/下载，说明其在构建问题排错场景下有较高参考价值。通过这份工具集，读者可以获得完整的MSBuild构建组件、调试支持文件及项目模板配置，快速定位编译失败原因并恢复VS的构建能力，适合在离线环境或版本更新后作为补充工具包使用。
1. VS平台工具集：把新机器开发环境重建从两小时压到十分钟
VS平台工具集这个压缩包，装的不是某一个插件，而是一个 VS 开发者在日常开发里反复手动配置的东西的合集：离线扩展安装包、项目模板、代码片段、环境脚本、NuGet 源配置和公共编译属性文件。它的价值在换机器或者给团队新成员配环境时最明显——以前要一个个找插件、一个个调设置，现在解压后按脚本走一遍，开发环境基本就恢复原样了。
适合三类人：经常在多台机器之间切换的开发者，想把团队开发环境统一起来的负责人，以及还在手工重建环境的初学者。这篇直接带你拆包、部署、排错，最后给出一套自检方法，让工具集真正成为你的开发底座，而不是桌面上一堆用完就忘的压缩文件。
2. 拆包看结构：工具集的三个层次分别解决什么问题
拿到压缩包，先别急着双击，先把里面的结构看一遍再动手。我见过不少开发者把整个压缩包解压到桌面就开始点，点完发现扩展装了、模板没进去，最后还得重新对路径。一套合格的 VS 工具集一般分三层：扩展层、模板层、脚本配置层。先搞清楚每层放在哪个目录、解决什么问题，后面的部署才不会乱套。
2.1 扩展层：离线 VSIX 把版本漂移这个问题锁死
扩展层对应压缩包里 01_Extensions 目录，里面放着一批 .vsix 文件。.vsix 是 VS 扩展的离线安装包，双击可以装，命令行也能装，但同一个包在 VS 2022 和 VS 2019 上不一定通用，因为扩展的 manifest 里声明了它兼容的版本区间。离线包最大的价值是版本锁定：团队所有人都装同一个版本，而不是各自在扩展市场里点更新，这能挡掉大量「我这边行你那边不行」的玄学问题——大部分时候不是代码差异，是扩展版本差异。
| 扩展类别 | 解决的问题 | 部署注意 |
|---|---|---|
| 代码格式化扩展 | 团队代码风格不统一 | 装完要确认快捷键能触发，不然等于没装 |
| 单元测试运行器 | 测试跑不起来、看不到覆盖率 | 需要和测试框架版本匹配 |
| 静态分析规则集 | 编译期暴露常见问题 | 规则过严会变成噪音，要按团队情况裁剪 |
| 效率增强类扩展 | 导航、重构、批量生成代码 | 这类最容易出现功能互相冲突 |
表格里的分类是这类工具集最常见的搭配，具体装了哪些以压缩包里的打包清单.txt 为准。我一般建议扩展层控制在十个以内，超过这个数，启动变慢是小事，两个扩展同时改同一个菜单才是真麻烦。判断扩展装没装成功，不要只看安装器提示，要看 VS 菜单里对应功能的入口是否出现。
2.2 模板层：把重复写三遍的代码固化成一次点击
模板层是工具集里最有长期价值的部分，包含项目模板和项模板两类。项目模板是一个 zip 包，里面有一个 .vstemplate 描述文件和若干源文件；项模板是新建项时出现的模板，比如属性变更通知、日志包装器、依赖注入注册这类每个项目都要写的样板代码。VS 识别模板的方式很简单：把 zip 包放进 Templates 目录，重启后新建项目的向导里就能看到。除了模板，代码片段同样属于这一层，只不过它针对的是单文件里的局部代码——模板解决「新建一个类」，片段解决「在类里插入一段约定写法」。
<?xml version="1.0" encoding="utf-8"?> <CodeSnippet Format="1.0.0" xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet"> <Header> <Title>属性变更通知</Title> <Shortcut>notifyprop</Shortcut> <Description>生成实现 INotifyPropertyChanged 的属性</Description> <Author>某开发者</Author> <SnippetTypes> <SnippetType>Expansion</SnippetType> </SnippetTypes> </Header> <Snippet> <Declarations> <Literal> <ID>TypeName</ID> <Default>string</Default> <ToolTip>属性类型</ToolTip> </Literal> <Literal> <ID>PropertyName</ID> <Default>MyProperty</Default> </Literal> </Declarations> <Code Language="CSharp"> <![CDATA[ private $TypeName$ _$PropertyName$; public $TypeName$ $PropertyName$ { get { return _$PropertyName$; } set { _$PropertyName$ = value; OnPropertyChanged(nameof($PropertyName$)); } } ]]> </Code> </Snippet> </CodeSnippet>这段片段的工作方式：在 C# 编辑器里敲 notifyprop 再按两下 Tab，$TypeName$ 和 $PropertyName$ 这两个字面量会变成可编辑的占位符，逐个按 Tab 填完，代码就插入到光标位置。Format="1.0.0" 是片段格式版本号，保持默认；Shortcut 是触发词，别和已有的片段或关键字冲突；CDATA 区里被插入的代码会原样进入编辑器，所以缩进和换行在写 .snippet 时就要排好。文件名的后缀必须是 .snippet，放到对应的代码片段目录后，VS 会做一次索引，重启或新建会话就能触发。
模板层看起来只是几个 zip 和 xml，但它解决的是很贵的一类问题：团队里每个人写出来的样板代码长得不一样。用模板固化之后，新人第一次建项目就能按团队约定来，而不是等代码评审时被逐个挑刺。注意模板 zip 内部不能嵌套一层同名文件夹，VS 要求 .vstemplate 位于压缩包根目录。
2.3 脚本配置层：环境变量、NuGet 源和编译属性一次对齐
第三层是 04_Scripts 和 05_Configs 两个目录。脚本负责搬运和检查，配置文件负责约定。这一层在刚拿到工具集时最容易被忽略，但恰恰是决定工具集能不能跨机器复用的关键。扩展和模板解决的是「装什么」，脚本配置层解决的是「每台机器上装完后行为是否一致」。
| 文件 | 作用 | 生效范围 |
|---|---|---|
| NuGet.config | 包源列表与 fallback 文件夹 | 当前目录及子目录 |
| Directory.Build.props | 公共编译属性，所有子项目自动继承 | 解决方案根目录及子目录 |
| .editorconfig | 缩进、换行、命名规则 | 目录树 |
| global.json | 锁定 .NET SDK 的大版本 | 当前目录及子目录 |
这四个文件是 VS/.NET 项目最常见的约定层，不需要进入 VS 的设置界面，把文件放进仓库根目录或工具集的 Configs 目录，打开项目时就自动生效。脚本层的作用是把前面两层的安装动作串起来，并且做前置检查和结果校验，后面第 3 章会逐个讲。这里先记一个原则：脚本里能用相对路径推导出来的位置，就不要写死绝对路径，否则换一台机器就废。
3. 部署实操：从解压到 VS 能识别，四步完整流程
这一章按我实际部署的顺序来：校验文件、定位 VS 实例、装扩展、放模板、下发配置。每一步都给出可复制的脚本和参数说明，遇到失败时先看脚本里哪一步退出，再回第 4 章对现象。
3.1 第一步：校验文件并定位 VS 实例
拿到压缩包第一件事是校验哈希。不是多疑，而是这类工具集文件在传输过程中一旦损坏，解压可能正常，某几个 vsix 或模板中途坏了，排查起来非常痛苦。压缩包的打包清单.txt 里一般会记录 SHA256，解压前先对一次。
$archive = "D:\Downloads\VS平台工具集.zip" $hash = (Get-FileHash $archive -Algorithm SHA256).Hash Write-Host "SHA256: $hash" # 和打包清单.txt 里记录的值对比，不一致就重新下载，不要继续解压Get-FileHash 是 PowerShell 自带的文件哈希计算命令，-Algorithm 指定算法，-Hash 属性输出大写十六进制字符串。对比时直接用文本比较即可，不需要转小写。哈希对不上就重新下载，省得后面花几个小时查一个坏文件造成的问题。
哈希没问题后，下一步是定位 VS 实例。很多部署脚本失败是因为把 VS 路径写死了，换个机器路径就不同。我一般用 vswhere 动态拿：
# 通过 vswhere 获取最新 VS 实例的安装路径，避免写死路径 $vswhere = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe" $vsPath = & $vswhere -latest -products * ` -requires Microsoft.VisualStudio.Workload.ManagedDesktop ` -property installationPath if (-not $vsPath) { Write-Host "没有找到可用的 VS 实例，先确认装过桌面开发工作负载" -ForegroundColor Red exit 1 } $env:VS_TOOLSET_HOME = "D:\DevTools\VS平台工具集" Write-Host "VS 实例路径: $vsPath"vswhere 是 VS 安装器自带的实例探测程序，-latest 表示取最新安装的实例，-requires 指定必须包含的工作负载 ID，这里用的是桌面开发工作负载；-property installationPath 只输出安装路径。拿不到路径就退出，避免后续脚本在一个不存在的路径上继续执行。$env:VS_TOOLSET_HOME 是自定义环境变量，只对当前会话生效，后续脚本都用它定位工具集根目录，换目录只改这一处。
3.2 第二步：用一条命令批量装完所有扩展
手动双击 vsix 一个个装，装完还要确认，太慢了。我把 01_Extensions 目录里的所有 vsix 交给 VSIXInstaller 批量处理：
$vsixInstaller = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\VsixInstallerService\x86\VSIXInstaller.exe" if (-not (Test-Path $vsixInstaller)) { Write-Host "找不到 VSIXInstaller，在 VS 安装器目录下搜索" -ForegroundColor Yellow Get-ChildItem "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer" -Recurse -Filter VSIXInstaller.exe exit 1 } $vsixFiles = Get-ChildItem "$env:VS_TOOLSET_HOME\01_Extensions\*.vsix" # 逐个静默安装，并根据退出码打印结果 foreach ($file in $vsixFiles) { & $vsixInstaller /quiet $file.FullName if ($LASTEXITCODE -eq 0) { Write-Host "已安装: $($file.Name)" -ForegroundColor Green } else { Write-Host "失败: $($file.Name) 退出码 $LASTEXITCODE" -ForegroundColor Red } }/quiet 参数表示静默安装，不弹任何向导；$LASTEXITCODE 是 PowerShell 里上一个原生程序退出后的返回值，0 表示成功，非 0 需要按 VSIXInstaller 的返回码表去查具体原因。不同 VS 版本的 VSIXInstaller 路径略有差异，所以脚本先做一次 Test-Path，找不到就递归搜索一次并把结果打印出来，这是我处理路径问题时的常规做法。
注意：静默安装不会弹错误对话框，失败时一定要看脚本输出的退出码，别只看「好像装完了」。
3.3 第三步：模板和代码片段落位到用户目录
模板类文件和扩展不同，没有安装过程，本质是文件拷贝，VS 会扫描固定的目录，把 zip 和 snippet 放对位置就生效。落位目标可以参考下表，实际版本差异以打包清单.txt 为准：
| 要放置的内容 | 目标目录 |
|---|---|
| 项目模板 zip | 文档\Visual Studio 2022\Templates\ProjectTemplates |
| 项模板 zip | 文档\Visual Studio 2022\Templates\ItemTemplates |
| 代码片段 .snippet | 文档\Visual Studio 2022\Code Snippets\Visual C#\My Code Snippets |
$docs = Join-Path $env:USERPROFILE "Documents" $tplRoot = Join-Path $docs "Visual Studio 2022\Templates" # 模板和片段都是整包拷贝，-Force 覆盖同名文件 Copy-Item "$env:VS_TOOLSET_HOME\02_Templates\ProjectTemplates\*.zip" "$tplRoot\ProjectTemplates" -Force Copy-Item "$env:VS_TOOLSET_HOME\02_Templates\ItemTemplates\*.zip" "$tplRoot\ItemTemplates" -Force Copy-Item "$env:VS_TOOLSET_HOME\03_Snippets\*.snippet" "$docs\Visual Studio 2022\Code Snippets\Visual C#\My Code Snippets" -Force Write-Host "模板和片段已落位，重启 VS 后生效"这里的 Documents 用了 Join-Path 拼出来，是为了兼容文档目录被重定向的情况。如果机器开了 OneDrive 备份，实际路径可能是重定向后的目录，直接写死 C:\Users\xxx\Documents 会在没重定向的机器上报错。Copy-Item 的 -Force 表示覆盖同名文件，脚本在覆盖前会把现有文件备份，这一点在第 5 章展开。落位后必须重启 VS，模板扫描发生在启动阶段。
3.4 第四步：下发 NuGet 源与公共编译属性
扩展和模板装完，还差环境约定。NuGet.config 决定项目从哪里拉包，Directory.Build.props 决定所有子项目共享哪些编译属性。工具集里这两个文件从 05_Configs 复制到解决方案根目录即可：
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <clear /> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" /> <add key="team-feed" value="http://packages.example.local/v3/index.json" /> </packageSources> </configuration>是这里最关键的一行，它把上层目录继承下来的所有包源先清空，再依次添加公共源和团队内部源，避免旧机器上残留的源干扰。内部源的地址按团队实际情况替换，示例里用的是占位地址。NuGet.config 对当前目录及所有子目录生效，不会污染其他项目，所以放在解决方案根目录最合适。
<Project> <PropertyGroup> <LangVersion>latest</LangVersion> <Nullable>enable</Nullable> <TreatWarningsAsErrors>false</TreatWarningsAsErrors> </PropertyGroup> </Project>Directory.Build.props 放在解决方案根目录后，所有子项目在编译时自动继承这三个属性，不需要逐个改 .csproj。LangVersion 指定 C# 语言版本，Nullable 启用可空引用类型，TreatWarningsAsErrors 控制警告是否升级为错误。团队如果刚启用可空类型，建议先保持 false，等存量代码处理完再收紧，避免新人一上来就被警告挡住。
注意：NuGet.config 是分层合并的，机器级、用户级、项目级共存。下发后先执行 dotnet nuget list source 确认实际生效的源列表，再开始 restore。
4. 避坑指南：工具集装上没反应的五个高频场景
这一章写的是部署工具集时的血泪经验。前面第 3 章是理想流程，实际机器上总有各种意外，下面五个场景我基本每部署三台机器就能遇到一个。遇到安装没生效的问题，先按「VS 版本 → 目录落位 → 执行策略 → 配置合并 → 机器依赖」的顺序排查，别一上来就重装 VS，重装往往解决不了问题，还浪费两小时。
4.1 扩展装了，菜单和功能面板里就是找不到
**现象：**安装过程没报错，甚至提示成功，但打开 VS 后菜单、右键菜单、工具栏都没有对应入口。**原因：**最常见是 .vsix 的兼容版本区间和当前 VS 主版本不匹配，静默安装在部分版本上不弹错误；其次是装完没重启 VS，扩展服务还没加载；还有一类是旧版本残留和新版本冲突，加载被静默跳过。**解决：**先重启 VS 再看；不行就打开扩展管理界面，看列表里是已安装还是已禁用；再不行用 VSIXInstaller 带日志手动装一遍，看输出的版本区间。我一般会把扩展名和适用 VS 版本区间写进打包清单.txt，避免下一个部署的人重复踩。
4.2 模板向导能跑，生成的项目一编译就报错
**现象：**通过模板新建项目时向导一切正常，项目生成到磁盘也有模有样，一编译就报文件找不到或命名空间错误。**原因：**模板 zip 内部的源文件里写了绝对路径，或者写死了旧 GUID、旧项目格式；也可能是 .vstemplate 里的 ProjectType 和实际项目类型不一致，向导走完生成出来的 .csproj 是残缺的。**解决：**把模板 zip 解压，搜一遍 D:\ 开头的绝对路径和写死的 GUID，用 $safeprojectname$、$guid1$、$rootnamespace$ 这类替换参数换掉。改完重新打成 zip，注意 .vstemplate 必须在压缩包根目录，不能外层再套一个文件夹。
4.3 PowerShell 脚本被系统拦住，提示禁止运行脚本
**现象：**双击脚本没反应，命令行里执行报「无法加载，因为在此系统上禁止运行脚本」。**原因：**Windows 默认执行策略是 Restricted，脚本文件不允许运行；部分公司环境还用组策略锁死了执行策略，改了当前用户也不生效。**解决：**先运行 Get-ExecutionPolicy 看当前策略；如果允许修改，执行 Set-ExecutionPolicy -Scope CurrentUser RemoteSigned，只影响当前用户；如果组策略锁死，用 powershell -ExecutionPolicy Bypass -File xxx.ps1 显式绕过。工具集脚本做的是文件复制和调用 exe，用 Bypass 不会带来额外风险。
4.4 NuGet restore 还在往旧源发请求，然后超时
**现象：**NuGet.config 里明明写了新源，restore 还是会访问一个连不上的旧地址，最后报一堆超时错误。**原因：**NuGet.config 分层合并，机器级、用户级、项目级三份配置叠加。项目级配置文件里没有 ，上层继承的旧源就一直保留，尤其是那台机器以前配过内网源。**解决：**先执行 dotnet nuget list source 看实际生效的源列表，确认旧源来自哪一层；在工具集下发的 NuGet.config 里用 清掉继承源，再逐个 add。改完重新 dotnet restore，不需要重启 VS。
4.5 同一套工具集，A 机器顺利、B 机器缺这缺那
**现象：**同一个压缩包，A 机器半小时装完一切正常，B 机器装完编译器报 SDK 找不到、模板不出现、扩展加载不完整。**原因：**工具集只管文件和配置，管不了机器本身的差异。B 机器可能没装对应版本的 .NET SDK，或者 VS 安装时没勾选对应工作负载，模板用到的组件在目标机器上不存在。**解决：**在入口脚本里加前置检查，先跑 dotnet --list-sdks 和 vswhere 确认 SDK 与工作负载齐全，缺失就报错并提示装哪个工作负载，而不是继续往下跑。检查写进脚本之后，环境差异问题能在 30 秒内定位。
5. 团队化落地：从 U 盘拷贝进化到一键标准化
单机部署用手点没问题，团队落地就不能依赖某一个人记得所有步骤。工具集要发挥长期价值，得把它变成可重复执行的命令、有版本记录、有回滚手段，还要有交接文档。这一章就是把第 3 章的散装步骤升级成一套团队可用的规范。
5.1 入口脚本参数化：把安装动作封装成可重复的命令
我一般会把 3.2 到 3.4 的脚本串进一个入口脚本，做成带参数的命令。新机器上一条命令跑完，CI 环境也能复用，不会出现「上次是我手动装的所以没问题」这种黑匣子操作。入口脚本只做调度，不做具体安装逻辑，具体动作留在 04_Scripts 下各自的子脚本里，排错时可以单独调子脚本。
param( [string]$ToolsetHome = "D:\DevTools\VS平台工具集", [ValidateSet("once","incremental")][string]$Mode = "once", [switch]$SkipExtensions, [switch]$SkipTemplates ) # 入口脚本只调度子脚本，具体安装逻辑留在各自文件里 if (-not (Test-Path $ToolsetHome)) { Write-Host "工具集目录不存在: $ToolsetHome" -ForegroundColor Red exit 1 } if (-not $SkipExtensions) { & "$ToolsetHome\04_Scripts\Install-Vsix.ps1" } if (-not $SkipTemplates) { & "$ToolsetHome\04_Scripts\Install-Templates.ps1" if ($Mode -eq "incremental") { Write-Host "增量模式：覆盖前已备份现有模板" } } & "$ToolsetHome\04_Scripts\Set-NuGetSource.ps1" & "$ToolsetHome\04_Scripts\Verify-Toolset.ps1"$ToolsetHome 是工具集解压后的根目录，默认值写死方便单机用，团队里可以改成从参数传入；$Mode 用 ValidateSet 限定 once 和 incremental 两个值，once 是全量安装，incremental 用于已装过一半、需要补量的场景；$SkipExtensions 和 $SkipTemplates 是 switch 参数，机器上已有同版本扩展时跳过扩展安装，能省掉一半时间。每个子脚本内部都要定义自己的退出码，入口脚本拿到非 0 退出码就中断并打印是哪一步失败的，这样 CI 集成时日志一看就知道卡在哪。入口脚本最后总是调用 Verify-Toolset.ps1，也就是第 6 章的自检脚本，把验证变成安装流程的最后一步，而不是可选动作。
5.2 变更记录与回滚：让工具集自己也有一份后悔药
工具集也是软件，要有版本管理。我在团队里的做法：压缩包里固定放一个打包清单.txt，记录每个文件的作用、适用 VS 版本区间、更新日期。每次增删扩展或模板，在清单里加一行，而不是默默替换文件。有人反馈装了工具集之后出现奇怪问题，第一件事就是对照清单看最近改了什么，这一步能省掉大量排查时间。
| 回滚对象 | 处理手段 | 注意事项 |
|---|---|---|
| 扩展 | VSIXInstaller /uninstall 卸载到旧版本 | 先确认旧版本安装包还在本地 |
| 模板与配置 | 脚本覆盖前自动备份到 backup<时间戳> | 备份目录放在工具集内部，随 Git 走 |
| 整个工具集 | Git 打 tag，出问题 checkout 上一个 tag 重新打包 | 禁止在 tag 上直接修改 |
回滚原则只有一个：任何覆盖操作发生前，先把旧状态留一份。模板覆盖这个动作最容易出问题，所以 Install-Templates.ps1 里在 Copy-Item 之前先把目标目录里同名文件复制到 backup 目录，文件名带时间戳，出问题能精确回到上一次的版本。整个工具集放在 Git 仓库时，scripts、templates、configs 全部提交，.vs 目录、bin、obj、*.user 这些用户级临时文件加进 .gitignore，不要提交。
5.3 交接文档：把工具的用法也装进压缩包
工具集最后应该包含一份使用说明，放在 06_Docs 目录。内容写三件事：这套工具集装了哪些东西、每个脚本入口做什么、已知的坑有哪些。新人不至于拿到压缩包还要来问模板怎么用、脚本会不会破坏现有环境。文档不用长，把第 4 章五个高频问题精简成半页放进文档，比写十页原理都有用。我见过太多工具集因为只有脚本没有文档，半年后连打包的人自己都忘了某个参数的含义，最后只能重新翻代码。
6. 装完别急着写代码：用自检脚本验证环境再开工
部署走到最后，最怕的是「感觉都装了，一跑项目才发现少东西」。我习惯在工具集里放一个自检脚本，安装流程结束前强制跑一遍，把环境状态打印出来。这样环境问题在写第一行业务代码之前就暴露，而不是等编译报错时再来排查。
$vswhere = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe" $vsPath = & $vswhere -latest -products * -property installationPath # 用有序哈希表组织检查项，结果为布尔值，最后统一输出 $checks = [ordered]@{ "VS实例" = [bool]$vsPath "项目模板" = (Get-ChildItem "$env:USERPROFILE\Documents\Visual Studio 2022\Templates\ProjectTemplates\*.zip" -ErrorAction SilentlyContinue).Count -gt 0 "代码片段" = (Get-ChildItem "$env:USERPROFILE\Documents\Visual Studio 2022\Code Snippets\Visual C#\My Code Snippets\*.snippet" -ErrorAction SilentlyContinue).Count -gt 0 "内部NuGet源" = (dotnet nuget list source) -match "team-feed" } $failed = $false foreach ($key in $checks.Keys) { if ($checks[$key]) { Write-Host "[通过] $key" -ForegroundColor Green } else { Write-Host "[失败] $key" -ForegroundColor Red; $failed = $true } } if ($failed) { exit 1 } else { Write-Host "自检全部通过，可以打开 VS 开始干活" -ForegroundColor Green }这段脚本用 [ordered] 有序哈希表存储检查项，每一项的结果都是布尔值，最后统一遍历输出。Get-ChildItem 加了 -ErrorAction SilentlyContinue，目录不存在时不会抛红字，而是返回空集合，Count 为 0 自然判为失败。dotnet nuget list source 的输出是字符串数组，-match 做包含匹配，只要源列表里出现 team-feed 就算通过，源地址变了但源名不变也能识别。exit 1 让脚本可以直接嵌入 CI 流程，自检失败就中断后续步骤。如果要扩展检查项，在 $checks 里加一行就行，比如检查 .editorconfig 是否存在于解决方案根目录、检查指定工作负载是否安装。
如果你正准备重建开发环境，把这份 VS平台工具集下载下来，按 3.1 到 3.4 的顺序部署，再用这个脚本收尾，能少踩我踩过的那些坑。从那以后，我每次给新机器部署工具集，都强制先跑一遍自检再开项目。跑完能分清是环境没装到位还是代码本身有问题，省掉的不只是排查时间，还有对着「我明明装了」这种错觉较劲的耐心。希望帮到你。
本文还有配套的精品资源，点击获取
