不用 dotnet build：一条规则走 Visual Studio 链路
背景：同样的代码，为什么 VS 能编、命令行不行？
不少公司电脑装了透明加密、防泄密或终端管控软件。表现往往是：
- 在 Visual Studio 里点「生成」或按 F5 调试，一切正常；
- 在 PowerShell / Cursor 终端里跑
dotnet build，却随机报错：访问被拒绝、文件被占用、超时、复制失败等。
这通常不是项目坏了，而是策略按进程、父进程或写盘路径 区分对待：dotnet.exe 拉起的构建链不在白名单 里，而 devenv.exe、VS 调起的 MSBuild 被放行。路径上若还叠加网络盘、同步目录，CLI 与 VS 使用的临时目录不一致，差异会更明显。
只要确认「VS 能稳定生成」，就可以把「验证编译」这件事也改走同一条工具链 ，避免 AI 或脚本习惯性调用 dotnet。
思路：用 Cursor 规则把偏好固定下来
Cursor Rules 会在对话里给模型持久化的指令。我们要写的是：
- 不要 在默认流程里用
dotnet build/dotnet test/dotnet run做验证（除非用户点名或环境根本没有 VS）； - 要 用
devenv.com编解决方案 ，或MSBuild.exe编单个项目，路径与配置和本机 Visual Studio 安装一致。
这样无论是你自己敲命令，还是 Agent 在终端里替你跑编译，都会优先走「和 VS 一致」的方式，减少被加密软件拦截的概率。
规则正文（可直接用于 User Rules 或 .mdc）
下面这段是规则的核心说明；若用 项目规则 或 带 frontmatter 的 .mdc 文件，可在文件开头加上 YAML（见下一节）。
说明性正文（适合粘贴到 Cursor → Settings → Rules → User Rules）：
本机企业加密软件会拦截
dotnet build/dotnet test/dotnet run，Visual Studio 生成正常。在终端做编译或验证时：不要用 dotnet CLI 作为默认方式；优先用devenv.com编.sln，或用C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\MSBuild.exe编.csproj（配置名与 sln 一致，如Debug|Any CPU）；需要还原时对同一 sln/csproj 先 MSBuild-t:Restore再 Build。若无 VS（仅 Linux/macOS/SDK）再用 dotnet。
带元数据的 .mdc 示例（适合放在 .cursor/rules/ 或用户目录下的规则文件夹）：
markdown
---
description: Windows 本机勿用 dotnet CLI 做编译验证；改用 devenv.com 或 VS 自带 MSBuild
alwaysApply: true
---
# .NET 编译与验证（本机 Windows）
本机企业加密/管控软件常拦截 **dotnet build、dotnet test、dotnet run** 等 CLI，而 **Visual Studio 内生成正常**。
在需要通过**终端编译或验证**时：
1. **不要**默认使用 dotnet CLI（除非用户明确要求，或项目文档/CI 明确仅支持 CLI 且当前环境无 VS）。
2. **优先使用**与 VS 一致的链路：
- **整个解决方案**：
`devenv.com` + `.sln` + `/Build "Debug|Any CPU"`（路径按本机 VS 版本填写 Community / Professional / Enterprise）。
- **单个 .csproj**：
VS 安装目录下 `MSBuild\Current\Bin\MSBuild.exe`，并传入 `-p:Configuration=Debug -p:Platform="Any CPU"`；需还原时先 `-t:Restore`，再 `-t:Build`。
3. 配置字符串须与解决方案里一致；Release 用 `Release|Any CPU`。
4. 若当前为 Linux/macOS 或仅有 SDK、无 VS，再改用 dotnet CLI。将 alwaysApply: true 设为「始终应用」，可避免模型在「验证一下编过没有」时又回到 dotnet build。
命令示例（PowerShell）
整解决方案生成（控制台输出用 devenv.com）：
powershell
& "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.com" "D:\path\YourSolution.sln" /Build "Debug|Any CPU"单个项目：
powershell
& "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\MSBuild.exe" "D:\path\YourProject.csproj" -p:Configuration=Debug -p:Platform="Any CPU"在解决方案里只编某一个项目（/Project 为 sln 中的项目显示名）：
powershell
& "...\devenv.com" "D:\path\YourSolution.sln" /Build "Debug|Any CPU" /Project YourProjectNameVS 版本或 SKU 不同，只需替换 Community 以及盘符路径即可。
规则放在哪里：项目级 vs 用户级
| 方式 | 作用范围 | 说明 |
|---|---|---|
| Cursor Settings → Rules → User Rules | 本机所有仓库 | 官方推荐的「全局」入口，内容存在应用数据中。 |
仓库内 .cursor/rules/*.mdc |
当前仓库 | 可版本管理，团队共享；适合写成团队规范。 |
用户目录下的 .cursor/rules/*.mdc |
视 Cursor 版本而定 | 便于备份与同机多仓库共用；若发现未生效，请以 User Rules 为准再贴一份。 |
本项目作者曾在本机使用：C:\Users\宋恒\.cursor\rules\dotnet-build-vs-toolchain.mdc，与上表规则内容一致。
例外与边界
- CI / Linux 容器 / 无 VS 的环境 ：仍应使用
dotnet，规则里已写明「无 VS 再用 CLI」。 - 加密策略若按目录拦截 ：仅换进程仍可能失败，需要 IT 对工程目录、
obj/bin、临时目录做策略调整。 - User Rules 与 Inline Edit ：按 Cursor 文档，User Rules 主要作用于 Agent（聊天），不作用于所有 AI 功能；若某场景仍出现
dotnet，可在该次对话里口头强调或@引用规则文件。
小结
「VS 能编、dotnet build 不行」在很多企业环境下是策略差异 而不是代码问题。把编译验证 写进 Cursor 规则、固定为 devenv / MSBuild 路径，可以让日常开发和 AI 辅助构建都更稳。若你希望规则对全仓库、全团队生效，把 .mdc 放进各项目的 .cursor/rules/ 并提交到 Git，是比单机 User Rules 更长久的做法。
本文基于实际环境整理，命令中的 VS 路径请按本机安装调整。