JetBrains Rider
Solution 加载成功，只证明 Rider 能看见目录
Rider 打开 .sln 或 .slnx 后，Solution Explorer 能展示全部 project，代码也可能正常跳转。点击 Build 时才出现目标框架不可用、SDK 不匹配或条件导入缺失；另一位开发者则构建成功，却运行了错误 startup project。团队若只交换 .sln 截图，很难发现一台机器通过 global.json 选择 SDK，另一台使用最新系统 SDK，第三台依赖 Visual Studio 安装的 targeting pack。
Solution 是多个 project 的组织和协作视图，真正的编译输入仍来自 project 文件、Directory.Build.props/targets、NuGet 资产、target framework 与 SDK/MSBuild 工具链。Rider 项目与 solution 文档也区分 solution 内项目和 Rider 自己附加显示的外部文件。后者方便浏览，却不会自动进入构建图。
安装模型要服从目标项目与许可
个人开发机可以通过 JetBrains Toolbox 安装稳定 Rider，并保留一个旧实例用于回退。受管设备可用官方 standalone 包纳入软件分发。安装 IDE 之前先盘点项目需要的 .NET SDK、Windows targeting pack、C++/游戏引擎组件与目标 OS；Rider 跨平台不意味着每种项目和设计器都跨平台。
首次启动从 Help | About 记录 Rider build、IDE runtime、OS 和架构，检查许可、代理、企业 CA 与批准插件。个人非商业许可、试用和商业订阅有不同条件，公司业务按实际用途分配席位。Unity、Unreal 或专用插件还可能有自己的版本、下载源与合同，不能用 Rider 许可替代整条工具链许可。
升级时固定项目工具链，只替换 Rider。代表 solution 依次完成 restore、build、test、运行、断点、停止与重启；通过后再考虑升级 .NET SDK、引擎或插件。旧实例保留期间要计算磁盘，但它是真实回退入口。删除缓存并不能回到旧的项目模型实现。
先从命令行证明 solution 的工具链
打开 IDE 前先运行：
dotnet --info
dotnet --list-sdks
dotnet --list-runtimes
Get-ChildItem global.json,Directory.Build.props,Directory.Build.targets,NuGet.config -ErrorAction SilentlyContinue
dotnet sln .\YourSolution.sln list
dotnet restore .\YourSolution.sln
dotnet build .\YourSolution.sln --no-restore
dotnet test .\YourSolution.sln --no-build把占位 solution 替换为仓库入口。输出要说明实际 SDK、MSBuild、RID/架构、项目集合和测试结果。若仓库使用 .slnx 或只维护 project/自定义任务，就使用正式入口，不为了适配示例另造 solution。
global.json 可以选择 SDK 版本和 roll-forward 策略，却不会安装缺失 SDK。Rider 的 Toolset 设置必须能解释最终调用哪个 .NET CLI/MSBuild。IDE 终端与 Run Configuration 再打印 dotnet --info；不同路径只有在远程、容器或明确的 Visual Studio toolset 场景下才合理。
目标框架出现在新建项目下拉框，取决于机器实际安装的框架/SDK。看到模板不代表现有项目可构建，加载现有 solution 成功也不代表所有条件 target 都被执行。必须以完整 build/test 的退出码为准。
用缺失属性导入稳定暴露项目模型问题
MSBuild 的导入链很适合证明“IDE 看到项目”与“项目模型完整”不是一回事：
$lab = Join-Path $env:TEMP "rider-msbuild-lab"
Remove-Item -Recurse -Force $lab -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path $lab | Out-Null
@'
<Project>
<PropertyGroup><TeamLayer>team</TeamLayer></PropertyGroup>
</Project>
'@ | Set-Content -Encoding utf8 (Join-Path $lab "Team.props")
@'
<Project Sdk="Microsoft.NET.Sdk">
<Import Project="Team.props" />
<Target Name="Verify">
<Message Importance="high" Text="layer=$(TeamLayer)" />
<Error Condition="'$(TeamLayer)' != 'team'" Text="team-layer-missing" />
</Target>
</Project>
'@ | Set-Content -Encoding utf8 (Join-Path $lab "Lab.csproj")
dotnet msbuild (Join-Path $lab "Lab.csproj") -t:Verify
Rename-Item (Join-Path $lab "Team.props") "Team.props.off"
dotnet msbuild (Join-Path $lab "Lab.csproj") -t:Verify
$negativeExit = $LASTEXITCODE
Rename-Item (Join-Path $lab "Team.props.off") "Team.props"
dotnet msbuild (Join-Path $lab "Lab.csproj") -t:Verify
"negative_exit=$negativeExit"
Remove-Item -Recurse -Force $lab正例打印 layer=team。隐藏导入文件后，MSBuild 返回非零并指出缺失路径；恢复后再次通过。在 Rider 中打开 Lab project，删除/恢复 import 应触发项目模型重新加载。若编辑器仍显示旧属性，先 Reload Project/Solution 并查看设计时构建日志；清索引之前先证明命令行已经恢复。
真实仓库中的 Directory.Build.props/targets、SDK resolver 与 NuGet props/targets会形成更长导入链。遇到条件属性异常时，可生成预处理项目或 binary log；日志可能含路径、包名和环境信息，分享前脱敏，不上传带 token 的 NuGet 源配置。
Solution、project 与 startup configuration 各有责任
Solution 负责把多个 project 组织在一起，solution folder 可以只是视图。Project 文件声明目标框架、引用、编译项和 build 属性；源码、测试数据或脚本即使显示在 Rider Explorer，也不一定属于任何 project。新增文件后应通过 CLI build 确认它真正进入编译，而不是只看语法高亮。
Rider 一次会话以一个 solution 为中心，额外目录可以显示但不会写回 .sln/project。monorepo 选择入口时，优先团队维护的 solution 或统一任务，而不是为个人方便新建并提交一份不完整 solution。solution filter 或 smaller solution 可以提升大型仓库加载速度，但团队要明确哪些项目未进入当前验证范围。
Startup project/Run Configuration 决定实际进程、参数、工作目录和环境。多服务 solution 还可能有 compound 配置；停止语义要覆盖子进程与容器。共享配置只保存相对路径和环境变量名，数据库连接、云凭证、内部 URL 与用户目录留在本机 secret 层。
NuGet 恢复必须与构建证据相连
Rider 的 NuGet 窗口便于搜索和升级包，但仓库依赖主源是 project/central package management、lock file 与 NuGet.config。GUI 安装包会修改 project；提交前审查版本、传递依赖、source 与许可证。不要让个人全局 NuGet.config 中的源和凭证成为唯一成功条件。
私有 feed 的诊断要分 DNS/TLS、source mapping、身份与包版本。dotnet nuget list source 只证明配置存在，dotnet restore --no-cache 才能在减少旧缓存影响后验证。凭证进入受控 provider、系统凭证或 CI Secret，NuGet.config 只保存无秘密的源定义。关闭签名/证书校验或在日志中输出授权头都不接受。
离线 layout 需要 SDK、targeting pack、NuGet 包和插件/引擎依赖的完整闭包。只复制全局 packages 目录无法解释来源、保留与撤销。组织可使用受控 feed 或制品仓库，记录 restore 解析、缓存命中与退出路径。
测试与调试要绑定实际进程
Rider 测试窗口应复用 solution/project 和目标框架。先运行 dotnet test，再在 IDE 运行同一集合；多 TFM 项目要明确测试的是哪一个 target。若 IDE 测试通过而 CLI 失败，检查 adapter、working directory、环境与被过滤测试；不要只提交 Rider 私有 filter。
调试最小链包括：选择正确 startup project/TFM，设置断点，确认调用栈中的模块来自当前输出目录，检查 PID 与环境，停止后进程和端口退出。热重载、IIS Express、Kestrel、Docker、Unity 或 Unreal 会引入宿主/子进程，断点不命中时先找实际加载程序集和 PDB，不把 Restart Rider 当作第一步。
Attach 到远程或生产进程会扩大权限与风险。调试协议、端口、符号和源码可能暴露敏感数据；生产接管由部署运维流程控制。开发侧远程调试应使用临时环境、短期凭证和明确清理动作。
Unity/Unreal 项目还要把 editor/engine 版本、生成 solution、插件和平台 SDK 放进兼容矩阵。Rider 能打开生成文件不代表引擎构建链一致；修改工程入口后回到引擎与 CLI 重新生成和构建。
Rider 与 Visual Studio 的选择不能只比编辑器
Rider 的跨平台 .NET、ReSharper 分析和 JetBrains 平台体验是明显优势。Visual Studio 则在 Windows workload、特定设计器、诊断器、MSVC 与 Microsoft 生态上可能更直接。团队用代表项目比较：安装体积、所需 workload/SDK、构建一致性、调试/诊断能力、扩展治理、许可证与离线部署，而不是凭快捷键投票。
存量 .NET Framework、COM、Windows 驱动、特定 UI designer 或 C++ 混合 solution，要逐项验证平台约束。跨平台 ASP.NET、服务与 Unity 项目也不能默认 Rider 总是更合适，仍要量化索引、内存、引擎插件与调试稳定性。
两个 IDE 可以并存，但仓库构建事实必须唯一。EditorConfig、分析规则、MSBuild 属性和测试入口优先共享；个人窗口、缓存和扩展留在本机。若两边格式化器持续制造噪声，应固定语言 formatter/检查任务，而不是要求开发者手工避免保存。
派生状态的清理要分层
bin/obj、NuGet global packages、Rider project model/index、IDE system 目录与引擎缓存都可被称为缓存，但恢复成本不同。排障先从 dotnet clean、删除明确 project 的 bin/obj 和干净 restore 开始；不要递归删除整个用户 NuGet cache，离线机器可能失去唯一依赖副本。
CLI 构建成功但 Rider 红线时，Reload Solution/Project，比较 SDK/toolset、条件属性和生成目录。输入一致后才重建索引。Rider Local History 不是备份，清 system 目录前保存未提交编辑。卸载 IDE 与撤销账号席位、私有 feed、引擎许可、SSH/云凭证是不同动作，离职流程要覆盖全部身份。
升级或插件问题用干净 Rider 实例、最小插件集和代表 solution 隔离。旧版能通过、新版失败时保留 build、project model 与 debugger 日志，先回滚版本再分析；不要在新版配置上叠加多次迁移后才报告。
故障分型从 SDK、导入链和进程开始
目标框架不可用先看 dotnet --info、global.json 和 targeting pack。不要为了匹配本机 SDK 在 IDE 中改项目 TFM；安装受支持组件或按升级计划迁移，随后 CLI 与 Rider 一起复验。
Rider 构建与 CI 不一致，先比较执行命令、MSBuild 版本、Directory.Build.*、NuGet.config、环境和 conditional property。生成 binary log 找到属性最后被谁覆盖，再修事实源。
断点不命中先确认 startup project、TFM、PID、程序集与符号。启动成功并不证明调试的是新构建；清理正确 project 输出、重新 build，再检查模块窗口比反复打断点有效。
Restore 失败按 source、TLS、身份、版本分开；登录 JetBrains 账号成功与 NuGet feed 无关。修复后用受控缓存或 --no-cache 重试，并确认凭证没有进入日志与仓库。
可支持基线必须让没有 Rider 的仓库仍然成立
团队验收 Rider 时，应留下安装 build 与商业许可、.NET SDK/toolset、solution/project 入口、restore/build/test 退出结果、实际调试进程、批准插件、升级与回退证据。大型 solution 额外测量加载、项目分析、内存、磁盘与 binary log 大小；优化前先确定哪些项目和 generated 内容真正属于当前视图。
Rider 不是项目的唯一操作面。取消订阅、更换 IDE 或在 CI 中都应能通过仓库任务恢复、构建、测试和发布。.idea 与个人 Run Configuration 只能补充体验，不能持有唯一 SDK 路径、秘密或构建参数。能保持这条退出路径，团队才是在使用 Rider，而不是被某台开发机的隐藏状态绑住。