dotnet pack 成功却只有工具配置：检查多 RID 与打包开关

dotnet pack 返回成功，工具的 .nupkg 却只含 tools/any/any/DotnetToolSettings.xml，没有程序 DLL，也没有对应的 RID 子包。SDK 10.0.402 下，先检查是否同时设置了 PackAsTool=true、多个 RuntimeIdentifiers 和 CreateRidSpecificToolPackages=false。

这组设置原本可能只是为了让依赖锁文件覆盖多个发布目标，同时继续产出一份框架依赖工具包。但该版打包逻辑从 RuntimeIdentifiers 得到用户指定 RID 集合，再据此决定主包是否只作为子包入口；关闭子包生成并没有同时强制主包带上实现，结果两边都没有程序。

分开检查还原与打包的求值

核对真正执行 pack 的 SDK、项目属性及 CI 传入值。RuntimeIdentifier 是单个目标，RuntimeIdentifiers 是目标集合，不要为了让条件分支变真，随意填一个单 RID 后仍声称产物与平台无关。

先在本地查看包内清单：预期的工具 DLL、依赖和入口配置是否齐全，入口配置指向的文件是否实际存在。包文件存在、版本号正确或打包退出码为零，都不能证明它可安装运行。

如果设计就是一份 RID 无关工具包，应让这个 pack 求值不再携带只为其他 RID 发布准备的集合，并单独维护那些 RID 的还原与发布流程。可以使用项目自有的明确开关，把相应 RuntimeIdentifiers 声明限制在确实需要它的构建入口；修改后要同时核对锁文件和各个发布目标，避免打包恢复了，RID 依赖覆盖却丢了。

不把内部属性当长期接口

强行设置 _ToolPackageShouldIncludeImplementation=true，或依赖 _IsPacking 编写条件，都涉及 SDK 内部属性。它们能影响这版目标，但不是稳定的跨版本契约；若用于受控临时绕行，应绑定 SDK 版本、保留条件差异，并在后续升级时重新核对。

如果应用实际需要 RID 专用工具包，则应保留相应分发结构，确认主包引用的每个子包都已经生成且可取得。不要一边关闭子包，一边发布只有路由配置的主包。

验收使用独立输出目录打包，检查每份 .nupkg 的实现与入口，再从受控本地源安装到隔离工具目录并执行项目原有功能检查。确认无误后才走正式包发布；已经上传的错误版本需要按包仓库规则处理，不能靠本地覆盖同名文件修复远端用户。