Visual Studio
同一个 solution，为什么有人能编译、有人连模板都找不到
新成员打开仓库，Solution Explorer 能列出全部 project，构建却提示 targeting pack 缺失；另一台机器同样选择 Debug | x64，实际调用了不同 MSVC toolset；第三台机器只在 IDE 中成功，进入 CI 后 NuGet 源、SDK resolver 和生成步骤全部失效。继续在项目属性里点选直到“本机能跑”，只会把环境漂移藏得更深。
Visual Studio 不是一个下载后功能固定的编辑器。Edition 决定使用权和能力集合，Installer 用 workload 表达开发场景，再展开成实际 component、SDK 与 toolset；solution 组织 project，MSBuild 评估 project 及其导入文件；debugger 最后附加到真实进程并加载与二进制匹配的符号。新机器必须能从仓库中的 .vsconfig 补齐组件，用确定的 solution、configuration、platform 与 SDK 构建，升级或扩展失效后还要能回到已验证实例。
Visual Studio 2026 版本是 Windows 桌面 IDE，x64 与 ARM64 机器的 workload / component 支持并不完全相同，应先按系统要求核对代表项目。安装通常需要管理员权限和足够磁盘；企业还要决定组件从公网还是受控 network layout 获取。把主版本、Edition 和组件来源留给个人选择，最终一定会出现同一 solution 调用不同工具链的局面。
Visual Studio 与 VS Code 的项目模型、扩展体系和安装方式不同。MSBuild、NuGet、依赖缓存或私有源故障可沿包管理、构建与任务脚本专题继续定位；调试协议与路径映射进入任务、运行与调试配置治理；VSIX 的来源和执行权限则与扩展与插件供应链治理联动。
Edition 先选对：Community 免费不等于企业免费
Visual Studio Community 官方使用说明允许个人开发者创建自己的免费或付费应用，这条权利不能直接外推为“公司里每个人都能免费用”。组织使用必须同时判断活动类型、组织是否属于 enterprise、使用人数和合同约束。课堂、学术研究和开源贡献是明确例外；其他组织场景受人数和 enterprise 定义约束，最终以目标版本许可条款与组织合同为准。
Professional 适合需要商业许可、标准 IDE 与订阅权益的个人或团队。Enterprise 面向需要其高级测试、调试、分析、架构与企业管理能力的团队。不要用“公司规模大所以全员 Enterprise”替代需求验证：先拿代表项目验证哪些能力只有 Enterprise 提供，再按角色分配。Build Tools 是无完整 IDE 的构建工具集合，适合受许可和支持策略约束的构建节点；它不是给开发者省掉本地 IDE 许可的迂回方案。
账号与产品密钥也要分层。开发者使用工作或学校账号获取组织分配的订阅，许可证管理员维护分配、回收和审计；离线环境按合同允许的产品密钥或订阅方式激活。不要共享账号、把产品密钥写进脚本，或在工单截图中暴露订阅身份。
安装模型：workload 是场景包，component 才是实际依赖
Visual Studio Installer 先用 workload 表达“我要做什么”，再用 component 表达“具体装哪些 SDK、编译器、targeting pack 和工具”。例如 .NET desktop development 对应托管桌面项目，ASP.NET and web development 面向 Web 项目，Desktop development with C++ 提供原生 C++ 核心工具。workload 的推荐和可选组件会随版本演进，所以团队不能只在文档里写一句“勾选 C++”。
在联网开发机上，从官方安装入口下载目标 Edition bootstrapper，启动 Installer，选择 workload，再在 Installation details 与 Individual components 中核对项目需要的 SDK、Windows SDK、MSVC toolset、CMake 或测试工具。安装或修改通常需要管理员权限；企业可通过 AllowStandardUserControl 策略有限委派 Installer 操作，但静默参数仍有权限限制。
安装后先打开 Help | About 记录 Edition、主版本与 build number，再打开 Developer PowerShell，执行：
$env:VSCMD_VER
dotnet --info
msbuild -version
cl 2>&1 | Select-Object -First 1.NET 开发机不一定安装 cl，纯 C++ 机器也不一定有目标 .NET SDK。预期结果取决于 .vsconfig：需要的命令可被解析，版本落在团队基线内，不需要的 workload 不应为了“保险”全部安装。安装位置、共享组件位置和 package cache 最好在首次安装前确定；部分位置安装后不能直接搬动。
用 .vsconfig 把安装需求放回仓库
在 Visual Studio Installer 的产品卡片选择 More | Export configuration，导出当前实例，再删掉与项目无关的 workload、component 和 extension。官方的安装配置导入导出说明支持把 .vsconfig 用于新装、修改现有实例和 layout；配置放在 solution 根目录时，IDE 还能提示缺失组件。把精简后的文件纳入代码评审。一个同时支持 .NET 桌面与原生 C++ 的示意配置如下：
{
"version": "1.0",
"components": [
"Microsoft.VisualStudio.Workload.ManagedDesktop",
"Microsoft.VisualStudio.Workload.NativeDesktop"
]
}这只是结构示例，不是所有项目的推荐全集。真实配置应由目标版本 Installer 导出，因为 workload 的推荐组件集合会变化；如果项目依赖具体 Windows SDK、旧 MSVC toolset、MFC 或测试组件，就显式添加对应 component ID，并记录保留原因和移除条件。
新机器打开包含 .vsconfig 的 solution 时，Visual Studio 可以提示安装缺失组件。已安装实例也可以从 Installer 导入，或由管理员执行：
& "$env:ProgramFiles(x86)\Microsoft Visual Studio\Installer\setup.exe" modify `
--installPath "C:\VS\Enterprise" `
--config ".\.vsconfig"这里必须使用 modify。update 只更新已安装内容，不会按 .vsconfig 补齐缺失 workload。预期结果是 Installer 完成后，目标模板、SDK 和 toolset 可见；再用项目构建证明配置有效。清理多余组件也应从 Installer 修改，并在试点机确认其他 solution 不受影响后推广。
.vsconfig 可以包含 Marketplace VSIX 信息，但扩展比 workload 风险更高。自动导出的“我机器上装了什么”不等于“项目必须装什么”；团队应只保留有 owner、有版本策略、有回滚包的扩展。
solution 与 project：先分清组织视图和构建事实
Visual Studio solution 用 .sln 或 .slnx 组织一个或多个 project、solution folder、构建配置和启动关系；.csproj、.vcxproj 等 project 文件描述各自的源码、引用与构建属性。Microsoft 的solution 与 project 说明明确 solution 是容器，MSBuild project 才携带编译所需输入；.suo 和 .vs 下的状态通常属于用户级窗口、断点和缓存，不应提交。.NET 10 SDK 的 solution 模板变更让 dotnet new sln 默认生成 .slnx，需要传统 .sln 时要显式传 --format sln，团队脚本不能依赖 SDK 默认值悄悄变化。
打开现有仓库时，优先打开团队维护的 solution。若 solution 只是一个陈旧导航壳，而 CI 直接构建 project 或仓库脚本，应先修复这层漂移，不要在每个人机器上手工 Add Existing Project。多 project solution 还要核对 project dependency、configuration / platform 与 startup project；“Solution Explorer 里都看见了”不代表 Release、x64 或测试配置真的参与构建。
团队基线应让 solution 可以被 IDE 和命令行共同构建。Visual Studio 的 Developer PowerShell / Developer Command Prompt 会初始化 MSBuild、MSVC 等环境，适合验证 IDE 外的工具链；普通 PowerShell 中找不到 msbuild 或 cl，不一定代表组件缺失，也可能只是未加载开发者环境。
MSBuild 如何把项目文件变成一次构建
MSBuild 先评估 XML 项目及其所有 .props、.targets、SDK 和 NuGet 生成导入，得到 property、item 与 target 图，再执行目标。property 是有覆盖顺序的标量，后出现的定义通常覆盖前值；item 是带 metadata 的输入集合；target 描述有依赖关系的任务。Visual Studio 的设计时构建也会调用这套模型来提供 IntelliSense 和项目系统信息，所以“编辑器正常”与“命令行目标成功”是两条相关但不相同的证据。
排查属性为什么没有生效时，不要继续点属性页。对具体 project 生成预处理文件，可以看到导入展开后的最终定义：
msbuild .\App.csproj /pp:artifacts\App.evaluated.xml
msbuild .\App.csproj /t:Build /p:Configuration=Debug /bl:artifacts\App.binlog/pp 适合追踪 property 最后由谁赋值，/bl 则记录评估与执行事件、task 输入输出和时序。官方 MSBuild 故障日志说明同时提醒：binary log 可能包含导入项目文本、环境变量值和完整路径。它是高价值诊断制品，也是潜在敏感制品；外发前必须检查 token、私有源 URL、用户目录和签名材料，处理结束后按工单保留策略清理。
当 IDE 与 CLI 结果不同，分别记录 Configuration、Platform、SDK、环境和实际 target，再比较两个 binlog。不要先把 IDE 的隐藏参数复制到 CI；目标是把必要 property 固化在 project、Directory.Build.props、Directory.Build.targets 或仓库任务中，并让本机与 CI 消费同一输入。
普通 PowerShell 找不到 msbuild 时，先用 Visual Studio Installer 自带的 vswhere 定位实例，不要把某台机器的绝对安装路径写进团队脚本。下面的实验建立一个只有 property、import 和 target 的 MSBuild 项目，不依赖 .NET SDK：
$vswhere = Join-Path ${env:ProgramFiles(x86)} `
"Microsoft Visual Studio\Installer\vswhere.exe"
$msbuild = & $vswhere -latest -products * `
-requires Microsoft.Component.MSBuild `
-find "MSBuild\**\Bin\MSBuild.exe" |
Select-Object -First 1
$lab = Join-Path $env:TEMP "visual-studio-msbuild-lab"
Remove-Item -Recurse -Force $lab -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path (Join-Path $lab "artifacts") | Out-Null
@'
<Project>
<PropertyGroup><Layer>base</Layer></PropertyGroup>
<Import Project="override.props" />
<Target Name="Show">
<Message Importance="High" Text="layer=$(Layer)" />
</Target>
</Project>
'@ | Set-Content -Encoding utf8 (Join-Path $lab "Probe.proj")
@'
<Project>
<PropertyGroup><Layer>team</Layer></PropertyGroup>
</Project>
'@ | Set-Content -Encoding utf8 (Join-Path $lab "override.props")
Push-Location $lab
& $msbuild .\Probe.proj /pp:artifacts\Probe.evaluated.xml /nologo
& $msbuild .\Probe.proj /t:Show /bl:artifacts\Probe.binlog /nologo
Rename-Item .\override.props override.props.off
& $msbuild .\Probe.proj /t:Show /nologo
$negativeExit = $LASTEXITCODE
Rename-Item .\override.props.off override.props
& $msbuild .\Probe.proj /t:Show /nologo
"negative_exit=$negativeExit"
Pop-Location
Remove-Item -Recurse -Force $lab正向运行应输出 layer=team，预处理文件里也应出现覆盖后的 property，并生成 binlog。移走导入文件后应以退出码 1 和 MSB4019 失败；恢复文件后再次输出 layer=team。这条证据链说明缺失 import 是项目评估失败，不是 debugger、缓存或源码错误，也演示了修复后如何回到同一构建结果。
用不存在的 SDK 复现项目模型失败
安装了 .NET SDK 的机器可以用下面的临时实验区分“solution 可见”和“project 可构建”。它先建立一个可成功构建的最小 solution，再写入一个本机不存在的 SDK 版本，观察 resolver 在项目评估前终止。
$lab = Join-Path $env:TEMP "visual-studio-sdk-lab"
Remove-Item -Recurse -Force $lab -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path $lab | Out-Null
Push-Location $lab
dotnet new sln -n SdkLab --format sln
dotnet new console -n App --no-restore
dotnet sln .\SdkLab.sln add .\App\App.csproj
dotnet build .\SdkLab.sln
@'
{
"sdk": {
"version": "99.0.100",
"rollForward": "disable"
}
}
'@ | Set-Content -Encoding utf8 .\global.json
dotnet build .\SdkLab.sln
$negativeExit = $LASTEXITCODE
"negative_exit=$negativeExit"
Remove-Item .\global.json
dotnet build .\SdkLab.sln --no-restore
dotnet clean .\SdkLab.sln
Pop-Location
Remove-Item -Recurse -Force $lab第一次和删除 global.json 后的构建应成功；中间一次应以非零退出码报告找不到兼容 SDK。Visual Studio 中 project 显示不兼容、模板消失或 design-time build 大量报错时，这类 resolver 证据比清 .vs 更接近根因。真实仓库应把所需 SDK 写成可安装、受支持的版本基线，而不是删除 global.json 来迁就开发机。
.NET 最小构建与调试
选择安装 .NET desktop development 或项目需要的 Web / Azure workload 后，先在仓库终端验证 SDK。若仓库有 global.json，它是 SDK 选择事实，不要为了让本机能跑就随意改成最新版。
dotnet --info
dotnet restore .\YourSolution.sln
dotnet build .\YourSolution.sln --no-restore
dotnet test .\YourSolution.sln --no-build把占位 solution 替换为项目文件。预期结果是 restore 成功，build 输出 0 Error(s)，test 全部通过且进程退出码为 0。然后在 Visual Studio 打开同一 solution，设置正确 startup project，在入口或测试中按 F9 设置断点，按 F5 启动。命中后检查 Locals 与 Call Stack，按 Shift+F5 停止；停止后确认应用子进程和本地端口都已释放。debugger 的边界是目标进程，不是 solution：多启动项目、IIS Express、容器或测试宿主可能生成多个 PID，停止动作是否回收子进程必须单独验证。
如果 dotnet build 成功而 IDE 失败，比较 IDE 使用的 configuration、platform、startup project、环境变量和 target framework。如果 IDE 成功而 CLI 失败，检查是否依赖 Visual Studio 自动恢复、用户级 NuGet 源、未声明的 SDK 或本机生成文件。修复目标是让仓库命令与 IDE 调用收敛，而不是继续堆用户级设置。
清理最小项目时使用 dotnet clean 或删除项目明确可再生的 bin / obj，不要删除 solution、project、lockfile 或迁移文件。对真实仓库，先查看 Git 状态，防止 generated source 实际属于受控产物。
C++ 最小构建与调试
原生 C++ 至少安装 Desktop development with C++，并核对项目要求的 MSVC toolset、Windows SDK、CMake tools、MFC / ATL 或旧版兼容组件。Visual Studio 2026 版本可提供多个 v14.x toolset 组件用于迁移旧项目，但“能装旧 toolset”不等于可以永久不升级；团队应记录旧 ABI / SDK 依赖和淘汰计划。
对 .vcxproj / .sln 项目，在 Developer PowerShell 中执行：
msbuild .\NativeApp.sln /m /p:Configuration=Debug /p:Platform=x64预期结果是 build succeeded，输出目录出现目标可执行文件和调试符号。Visual Studio 中选择 Debug | x64，在 main 或业务函数调用前设置断点，按 F5；断点命中后检查 Locals、Autos 和 Call Stack，再停止进程。
对 CMake 项目，仓库的 CMakePresets.json 应成为生成器、架构和缓存变量的共享事实。先在 Developer PowerShell 运行项目既有 preset：
cmake --preset windows-debug
cmake --build --preset windows-debug
ctest --preset windows-debug然后让 Visual Studio 消费同一 preset。若断点显示为空心，先在 Modules 窗口确认目标 DLL / EXE 是否真的加载、实际路径是什么、PDB 状态如何，再核对源码与二进制是否来自同一次构建。PDB 必须与目标二进制匹配；不要通过关闭优化或复制 DLL 的临时动作掩盖 configuration / platform 选错。
C++ 清理要按构建模型执行：MSBuild 项目可运行 Clean，CMake 项目删除明确的 out-of-source build 目录或使用 preset 对应 clean。共享源码目录中的手工删除风险很高，尤其是生成代码与第三方库混放的旧仓库。
VSIX：扩展是与 IDE 同权限运行的供应链
开发者可以在 Extensions | Manage Extensions 从 Marketplace 安装扩展，也可以双击可信 .vsix 离线安装。多数 VSIX 是 per-user，通常位于用户本地 Visual Studio 扩展目录；MSI 类扩展可能是机器级并有不同卸载方式。扩展安装后常需关闭 Visual Studio 才完成变更。
企业不应把“Marketplace 能搜到”当作批准。至少核对发布者、签名、目标 Visual Studio 版本、依赖、权限、更新历史和数据外发；保存批准版本的 VSIX 与哈希，先在试点组验证。官方文档说明 VSIX 程序集并非必须签名才能运行，因此签名是重要证据但不能单独证明安全。
Visual Studio 支持私有 extension gallery，当前官方文档将组织专有私有 gallery 能力标为 Enterprise 功能。.vsconfig 从较新的 Visual Studio 2022 版本起可导出部分 instance-wide Marketplace 扩展，但不能假定所有 per-user、网络共享或 MSI 扩展都会被捕获。--allowUnsignedExtensions 会放宽安装边界，除非隔离环境和安全评审明确批准，否则不要加入通用部署脚本。
回滚扩展时先禁用并重启验证，再卸载；若 IDE 无法启动，可用安全模式或从受控方式移除扩展。回滚后重新完成 solution load、build、test、debug，不能只看 IDE 能打开。
企业内网与离线 layout
受限网络中，正确做法不是让每台开发机反复访问公网，而是在联网准备区按网络安装布局为目标 Edition 创建并维护 layout。不同 Edition 要分别创建 layout；layout 还要按语言、workload 和 component 控制体积，并把 channel manifest、证书和更新节奏纳入运维。
下面示例使用 Enterprise bootstrapper 和仓库 .vsconfig 创建部分布局：
.\vs_enterprise.exe --layout C:\VSLayout `
--config .\.vsconfig `
--lang zh-CN en-US下载完成后在准备区校验 layout：
.\vs_enterprise.exe --layout C:\VSLayout --verify--verify 会报告缺失或无效包；它只适用于对应次要版本的最新布局，旧固定布局的长期可复现性还依赖固定 bootstrapper、manifest 与归档策略。验证通过后，把整个目录通过受控介质或内网共享分发，离线客户端从 layout 执行：
C:\VSLayout\vs_enterprise.exe --noWeb --wait `
--config C:\VSLayout\team.vsconfig命令中的路径只是占位。正式方案应使用短而稳定的受控路径、匹配 Edition 的 bootstrapper、固定 channel / version，并按官方 layout 文档维护 response.json 和更新源。layout 根路径过长会造成问题，官方建议路径少于 80 个字符；完整单语言 layout 可能需要数十 GB，部分 layout 若缺少后来新增 component，客户端离线修改会失败。
企业 CA 和 layout 签名验证不能省略。若安全软件或 TLS 检查替换包、manifest 或 WebView2 安装受策略阻断，Installer 可能失败。此时收集 %TEMP% 下以 dd_ 开头的安装日志、bootstrapper 返回码和 layout 验证结果，修复源或策略后重试，不要从未知网盘补单个安装包。
升级、回滚与 2022 / 2026 版本并存
Visual Studio 2026 版本发布历史区分当前通道与固定发布入口，Visual Studio 2022 版本仍有自己的生命周期和 17.x 服务基线。Visual Studio 2026 版本安装器可以迁移 Visual Studio 2022 版本配置，但应把迁移看作一次显式变更：先导出 .vsconfig 和 .vssettings，盘点扩展与旧 toolset，再在独立实例验证代表 solution。
不要同时升级 Visual Studio 主版本、Windows SDK、MSVC toolset、.NET SDK 和 VSIX。试点顺序应是：新 IDE 并存安装，按 .vsconfig 补组件，构建测试，调试，验证安装/打包产物，最后才切默认入口。旧实例保留到所有关键项目通过，而不是刚能打开 solution 就卸载。
Visual Studio Installer 的 rollback 只撤销最近一次更新，回到紧邻的先前已安装版本。例如从某一版本直接更新到另一个版本，rollback 不提供任意中间版本选择。回滚还可能撤销安全修复，企业可通过 DisableRollback 策略禁止用户操作。因此正式回退方案应同时包含：保留旧主版本实例、固定版本 bootstrapper / layout、.vsconfig、扩展归档和项目构建证据。
若升级后业务项目失败，先用旧实例和相同源码重建；若旧版成功、新版失败，再比较 MSBuild binary log、SDK resolver、toolset、extension 与 environment。不要为了让新版通过就修改 solution 或 project 并立即合并，这会把 IDE 兼容问题变成仓库变更。
常用提效：让 IDE 与命令行共享入口
Visual Studio 的 Solution Explorer、Test Explorer、Error List、Output、Diagnostic Tools、Developer PowerShell 和 debugger windows 应围绕同一证据链使用。先在 Output 选择正确来源，构建失败看第一处真实错误而不是 Error List 的连锁项；测试失败从 Test Explorer 重跑单例，同时保留 CLI 测试命令；调试命中后用 Locals、Watch、Call Stack 确认状态，不以“按 F5 没崩”作为验证。
大型 solution 可以使用 solution filter、按需加载和分项目构建改善日常体验，但 CI 仍需构建完整受影响范围。开发者的 .suo、窗口布局和断点是个人状态；团队共享的是 solution、project、.runsettings、.editorconfig、.vsconfig 和仓库任务。共享文件中不能出现用户目录、真实服务地址和凭证。
常见失败：现象、判断、原因、修复、再验证
模板或 SDK 在一台机器上消失
solution 能打开，但 project 显示不兼容，创建项目时没有模板，或提示 targeting pack / toolset 缺失。
在 Installer 对比已安装 workload / component 与仓库 .vsconfig，再用 dotnet --info、msbuild -version 或 Developer PowerShell 中的 cl 查看实际工具链。
只安装了核心编辑器、导入 .vsconfig 时执行了 update 而非 modify，或目标组件在当前架构 / 主版本不受支持。
用 Installer Import configuration 或 setup.exe modify --config 补齐；若组件已不受支持，回到受支持 IDE / toolset 或启动迁移，不要下载来路不明的 SDK。
重新加载 solution，完成 CLI 与 IDE build/test，并记录 Installer 导出的新配置差异。
.NET 在 IDE 成功、命令行失败
F5 能运行，普通终端执行 dotnet build 或 msbuild 失败。
区分普通 PowerShell 与 Developer PowerShell，检查 global.json、SDK 列表、NuGet 配置和 configuration。
IDE 自动选择了 Visual Studio 附带工具、用户级源或隐式恢复，普通 shell 没有相同环境。
让仓库声明 SDK 和依赖源，使用标准 dotnet 或明确初始化 Developer PowerShell；不把 IDE 私有环境当 CI 前提。
干净终端、Developer PowerShell、IDE 三处构建同一 solution，产物和测试一致。
C++ 链接失败或断点不绑定
出现 unresolved external、machine type 冲突，或断点为空心并提示没有加载符号。
核对 Configuration / Platform、MSVC toolset、Windows SDK、运行二进制路径和 Modules 窗口中的 PDB 状态。
x86 / x64 / ARM64 混用，Debug 启动了 Release 产物，旧库 ABI 不匹配，或 CMake cache 仍指向旧 compiler。
切回一致平台和 toolset，清理可再生 build 目录后重建；加载匹配 PDB，不把旧 DLL 手工复制进输出目录。
MSBuild / CMake CLI 成功，F5 命中源码断点，Call Stack 与实际二进制路径正确。
Installer 或离线 layout 失败
下载卡住、包校验失败、--noWeb 时提示找不到 package，或修改实例要求访问公网。
查看 dd_ 安装日志、layout channel manifest、证书、代理、磁盘和 .vsconfig 是否引用 layout 未包含的 component。
partial layout 不完整、layout 未维护到目标版本、代理 / CA 拦截、路径过长或 Edition 不匹配。
在联网准备区更新并验证 layout，补齐 component 与语言，重新分发；不要在离线客户端混用另一个 Edition 的 bootstrapper。
断网测试机从 layout 完成安装、modify、repair 和代表项目构建。
升级后扩展导致 IDE 不稳定
启动慢、solution load 崩溃、菜单异常或调试器行为改变。
禁用非必需 VSIX，以安全模式或干净实例复现；比较扩展兼容范围、签名、版本和 ActivityLog。
扩展 API 不兼容、自动更新跨过验证版本，或 per-user 扩展未被企业基线管理。
回滚 / 卸载扩展，恢复批准 VSIX；必要时 rollback 最近 IDE 更新或暂回旧主版本实例。
无扩展、批准扩展两组分别完成 solution load、build、test、debug，确认责任边界。
代理、权限、凭证与敏感信息
Visual Studio 安装修改默认需要管理员权限，IDE 本身通常以普通用户运行。不要为了让某个扩展访问文件而长期以管理员身份启动 IDE；官方默认在管理员运行时不加载 per-user extension，正是为了缩小高权限进程的扩展面。
NuGet 凭证、Azure / Microsoft 账号、Git token、代码签名证书、调试环境变量和服务连接不能进入 .vsconfig、solution、.vs、.runsettings 或截图。.vsconfig 只描述组件与受控扩展，真实凭证由操作系统凭证库、企业身份平台或 secrets 工具注入。离职时回收订阅席位、组织账号、私有 gallery 和制品源权限，而不只是卸载 IDE。
企业代理和 CA 需要同时覆盖 Installer、Marketplace、账号登录、NuGet、Git 和项目运行时。某一层联网成功不代表其他层成功。排障时分别记录请求入口和证书错误，不要全局关闭 TLS 验证或把代理密码写入仓库。
企业部署与落地工程深水区
第一，workload 漂移会让构建不可复现。仓库维护最小 .vsconfig，每次 component 变化都走评审；定期在干净虚拟机从配置安装并构建，而不是只在资深开发者的累积环境上验证。
第二，旧 SDK、toolset 和 out-of-support component 会形成安全债。为每个保留组件记录依赖项目、owner、支持终止日和迁移计划。企业策略可在更新时移除 out-of-support component，但启用前必须试点，否则可能让旧项目瞬间无法构建。
第三，网络 layout 不是一次性压缩包。它需要容量预算、更新窗口、manifest 与包校验、共享权限、版本保留和灾备。partial layout 的 component 集合必须与 .vsconfig 联动；删除旧 layout 前先确认回滚和旧分支构建不再需要。
第四，Community 误用是许可风险，不是技术问题。采购或法务维护组织分类与使用场景，许可证管理员按角色分配 Professional / Enterprise；审计应能回答谁在什么设备上使用哪个 Edition、对应什么权利。不要让开发者自行解释“非商业”。
第五，扩展和更新通道会扩大供应链面。通过 Intune、ADMX / Group Policy 或受控注册表策略管理可见通道、管理员更新、标准用户控制、package cache 和 rollback；私有 gallery 与 VSIX allowlist 由明确 owner 维护。Stable / LTSC / Insiders 的选择要按项目风险分组，不允许生产关键团队全员跟随预览通道。
第六，回滚能力容易被高估。Installer rollback 只能回紧邻版本，也可能撤销安全修复；项目回退还依赖旧 SDK、toolset、extension 和 layout。季度演练应从保留的旧实例或固定 layout 重建代表项目，并记录平均恢复时间。
团队自检必须形成可复查证据
安装前确认 Windows 架构、目标 Visual Studio 主版本、Edition 使用权、workload / component、磁盘、管理员权限、代理、CA 和下载来源。企业项目不得用模糊的“Community 免费”结论代替许可审查。
安装后记录 Edition、build number、channel 和 Installer 导出配置；在 Developer PowerShell 验证 .NET / MSBuild / MSVC 工具链。把精简 .vsconfig 放入仓库并从干净机器验证 modify 能补齐组件。
项目接入时确认 solution、project、configuration、platform、startup project 和 SDK / toolset。至少完成一次 CLI build/test 与一次 IDE 断点调试，并确认停止后进程、端口和临时资源已清理。
提交前扫描 .vsconfig、solution 配置、.runsettings、扩展列表和日志，排除真实路径、账号、token、内网 URL、证书和产品密钥。.vs、.suo、缓存和个人窗口状态不进入版本库。
推广前完成代表项目试点、VSIX 准入、layout 断网安装、更新与紧邻版本 rollback 演练，明确 Installer、许可证、扩展、项目工具链和安全事件的 owner。任何升级都应保留旧实例或固定 layout，直到 .NET 与 C++ 项目都通过构建、测试、调试和打包验收。