C# 文件应用缺了 DLL 仍复用缓存：用 no-cache 重建

文件应用之前能运行，后来 dotnet run --file 报 FileNotFoundException，提示找不到 NuGet.Configuration.dll；源码和包声明都没有改动。若缺的是文件应用缓存输出里的 DLL 副本，先检查是否复用了不完整的构建缓存。

.NET SDK 11.0.100-rc.2.26504.105 有一个明确复现：移除该应用输出目录中的依赖 DLL 后，普通运行仍跳过构建，直接启动并失败；使用 --no-cache 则重新构建并补回副本。这个版本是预发行 SDK，不能把结果扩大为所有 .NET 10 或 11 工具链的行为。

缺的可能是输出副本

先保留完整异常、实际 SDK 和缺失路径。Windows 文件应用输出通常位于临时目录下的 dotnet/runfile 子树；全局 NuGet 缓存保存的包还在，不代表这个应用已经拥有完整的运行文件。

不要为重现而删除真实工作目录中的 DLL，也不要一开始就清空全局 NuGet 缓存。最初副本为什么消失仍需单独调查，可能涉及本机清理或其他进程，但仅凭缺文件不能确定原因。这里能确认的是输出缺失后仍被复用的缓存判断分支。

强制当前文件应用重新构建

在原来的可信开发目录，用相同文件与环境执行：

dotnet run --no-cache --file ./repro.cs

repro.cs 是示例名称，应换成实际文件应用；保留原来需要的参数与包源。命令会构建、可能还原依赖，并执行这份代码。它不是只读检查，应该按原有开发流程运行。

--no-cache 的意思是跳过“是否已最新”的判断并始终构建。它不是永久禁用 NuGet 缓存，也不同于 --no-build；后者恰好会跳过构建，不能用来补缺失的运行产物。

确认强制重建后的运行结果，再比较随后一次普通运行是否恢复。若准备临时把 --no-cache 留在脚本中，应接受每次都构建的成本，并在 SDK 变化后重新评估。不要把暂时补回 DLL 当成已经查明文件消失原因。

恢复标准包括：原异常中的依赖副本已重新生成、实际加载路径属于预期应用输出、业务运行正常。若强制重建仍失败，继续按还原错误、包版本和原始异常定位；这时不应再把所有 FileNotFoundException 都解释成同一个缓存问题。