Visual Studio 解决方案筛选通过 /donotloadprojects 参数跳过全量加载，支持选择性加载项目、依赖项及保存为 .slnf 文件共享配置，显著提升大型解决方案打开、构建与协作效率。
大型解决方案打开慢、构建卡顿、依赖混乱——根本原因不是项目太多，而是默认全量加载和编译。Visual Studio 的解决方案筛选（Solution Filtering）和配置控制才是关键突破口，不是靠“升级硬件”或“等它加载完”。
怎么快速打开一个 50+ 项目的解决方案
别再双击 .sln 文件直接等十分钟。用 /donotloadprojects 启动参数跳过所有项目加载：
devenv /donotloadprojects MyBigSolution.sln
打开后，解决方案资源管理器 里全是卸载状态的项目。此时你可以：
- 右键单个或 Ctrl+多选项目 → “重新加载项目”（只加载你当前要改的模块）
- 右键已加载项目 → “加载直接依赖项”（自动补上它引用的类库，避免编译报错）
- 右键解决方案节点 → “显示卸载的项目”（随时切换视图，避免误点）
注意：/donotloadprojects 只在 Visual Studio 2019 v16.1+ 有效；旧版本只能手动卸载项目，且不保存状态。
为什么“生成解决方案”总漏编译，而“重新生成”才对
因为 生成解决方案（Ctrl+Shift+B）是增量编译：它只检查源文件时间戳和中间文件（obj/）哈希，一旦底层项目（如 CoreLib.csproj）的公共接口变了但没改文件时间戳（比如 NuGet 包更新、Directory.Build.props 全局注入），VS 就不会触发依赖项目重编译。
重新生成解决方案 强制清空 obj/ 和 bin/ 再全量跑一遍 MSBuild，所以能绕过缓存陷阱。但代价是耗时——尤其在 CI 或本地频繁切分支时。
Visual Studio 18.8.1 官方固定版本安装引导程序，当前条目使用微软发布历史中的 Professional Web Installer，适合旧项目兼容、环境回退、复现特定构建链和排查版本差异等场景。
更稳妥的做法是：
- 改了公共 API 后，手动右键被依赖的项目 → “重新生成”
- 在
Configuration Manager中确认该依赖项目确实在当前解决方案配置中被勾选（否则生成解决方案根本不会碰它） - 避免在
Directory.Build.targets里用<target name="BeforeBuild"></target>修改输出路径，这会让增量判断失效
如何让团队共用一套“常用项目子集”
靠口头说“你只开 A、B、C 三个项目”不可靠。要用 .slnf（Solution Filter）文件固化配置：
- 加载好你需要的项目后，右键解决方案 → “另存为解决方案筛选器…” → 生成
MyTeamDev.slnf - 把这个
.slnf提交到 Git，团队成员双击它，VS 就只加载预设项目（连未加载项目都不可见） -
.slnf是纯 JSON，可手动编辑，例如添加新项目只需往"projectList"数组里加一行"path/to/Project.csproj"
注意：.slnf 不替代 .sln，它只是加载指令；如果项目路径变更或 .csproj 被删除，打开 .slnf 会报错且无法自动恢复。
启动项目和解决方案配置容易被忽略的细节
粗体显示的“启动项目”只决定 F5 运行时哪个项目先起，**不影响生成行为**。真正控制哪些项目参与构建的是 Configuration Manager 里的勾选状态。
常见掉坑场景：
- 你在
Debug配置下开发，但Configuration Manager里把某个类库的勾选取消了 → 它永远不会被编译，即使其他项目引用它 - 新建了一个
Staging解决方案配置，但没给每个项目配对应的Staging项目配置 → 构建时该项目会 fallback 到默认配置（通常是Debug），导致发布包混入调试符号 - 多个启动项目时，F5 启动顺序由解决方案中项目出现顺序决定（不是资源管理器里拖拽顺序），改顺序得编辑
.sln文件本身
最隐蔽的问题：某些 SDK（如 MAUI）会在项目加载时动态修改 Configuration Manager 勾选状态，导致你手动取消的项目下次打开又被勾上——这时必须关掉自动加载功能或改用 .slnf 锁定。
