dotnet publish --no-build 漏了项目 DLL：按应用项目发布

解决方案发布成功，应用启动时却报 FileNotFoundException，发布目录里少了自己的项目依赖 DLL；.deps.json 又明确列着该依赖。若命令是解决方案级 dotnet publish --no-build -m:1，还要检查是否有测试项目先引用并发布了这个应用项目。

具体组合包含 App、Lib 和 App.Tests：App 通过 ProjectReference 引用 Lib，App.Tests 又引用 App，并在解决方案中排在 App 前。单独发布 App 能得到 Lib.dll，而同一节点上的解决方案发布遗漏它。这条表现涉及 SDK 8.0.426、9.0.102、10.0.402 的 Linux 容器，以及 10.0.302 的 Windows 环境；不能把所有缺 DLL 都归到这个顺序条件。

先确认漏的是发布复制，不是构建或加载名称

保留失败命令、SDK、Configuration、目标框架、RID 和项目引用图，比较构建输出、发布输出及 deps.json。若构建阶段本来就没生成 Lib，或应用引用的程序集名称不匹配，应先处理那些错误。

这条路径中，其他项目先向 App 请求发布项目列表，可能让项目引用拆分目标在配置还没准备齐时先执行。之后真正 Publish 又复用该目标的已完成状态，遗漏引用文件。10.0.402 的正式发布目标确实会在 GetCopyToPublishDirectoryItems 中调用引用拆分，但其直接依赖列表没有 AssignProjectConfiguration。

这段目标依赖能解释需要核对的执行顺序，不能单独证明任意工程一定触发。诊断时应在自己的构建日志里查目标首次执行时的引用项目列表；不要仅凭发布退出码为 0 就认定目录完整。

按实际部署的应用项目发布

不需要发布测试项目时，让发布入口指向应用项目，继续使用与既有构建一致的配置。例如下面仅演示没有额外 RID 参数的 Release 工程：

dotnet build Repro.sln -c Release -m:1
dotnet publish App/App.csproj -c Release --no-build -m:1

Repro.sln、App/App.csproj 都是占位路径。若原流程指定目标框架、RID、自包含或其他构建属性，两步必须对齐；不能先构建一组产物，再让 no-build 发布另一组条件。多个可部署应用分别走自己的项目入口，不把所有项目输出混进同一目录。

也可在原发布流程允许时移除 --no-build，让 publish 正常执行构建。它会增加实际构建与恢复行为，应评估 CI 资源、网络和原有离线要求。仅调整解决方案项目顺序可以用于验证触发条件，不宜成为依赖图不断变化时的长期保证。

不要把缺失 DLL 随意从旧发布目录补进去。那可能混合不同源码、版本和 RID 的文件；也不要直接编辑安装目录中的 SDK targets 来改变所有工程。此处未承诺某个后续正式 SDK 已修正这条顺序路径。

验收发布目录和真正启动结果

使用干净、属于本次任务的输出目录重新生成产物，检查 App、Lib 和必要运行配置的文件集合，再在项目原有的隔离部署环境启动应用，覆盖实际用到 Lib 的调用。还应保留测试项目引用 App 的组合，确认后续加入测试不会再次改变部署文件集合。

.deps.json 包含名字、发布命令返回成功、或者开发目录能运行，都不足以证明部署目录可用。回退时恢复项目入口和构建/发布参数的配套配置，并保留失败产物清单用于对照；不要将已经漏文件的镜像重新标成可发布版本。