Azure DevOps中PackageReference项目执行dotnet pack报NU5019找不到文件错误

结合报错信息、环境差异和实际现象，问题的核心触发逻辑完全可以复现，不存在模糊的排查空间：

• 从自动生成的nuspec文件看，打包步骤硬编码要找的dll路径是bin\Production\netstandard2.0\下的文件，但实际构建产物的存放位置和这个路径不匹配，自然会报NU5019找不到文件的错。
• 为什么本地能跑？本地开发机之前手动切到过Production配置构建过项目，本地项目缓存里记的输出路径刚好和nuspec里的路径对得上，不管是build还是pack都在同一个Production目录下找文件，自然不会报错。但Azure DevOps的构建工作目录是干净的，没有本地的缓存记录，两边SDK版本又不一样，路径计算逻辑就错位了：
  • 第一种常见错位：项目csproj里写死了无差别的<OutputPath>bin\Production\</OutputPath>，完全覆盖dotnet默认按配置区分输出目录的逻辑。但Azure DevOps默认的构建配置是Release，build步骤实际把dll生成到了bin\Release\netstandard2.0\，pack步骤读到csproj里硬编码的Production路径，去对应的空目录找dll，直接报错。
  • 第二种常见错位：服务器上的.NET SDK版本和本地不一致，不同版本SDK对pack步骤的输出路径解析规则有差异，比如旧版SDK执行pack时不会自动关联前序build的产物路径，而是沿用项目里残留的旧路径配置，哪怕build在Release目录输出了dll，pack还是会去之前缓存的Production目录找文件。

完全不需要切换回不支持PackageReference的NuGet.exe流程，按以下步骤调整即可：

• 统一构建和打包步骤的配置上下文，不要依赖Azure DevOps的默认值
  • 给dotnet build任务显式传参--configuration $(BuildConfiguration)，在流水线变量里把BuildConfiguration的值设置为你实际要打包的配置（不管是Production还是Release）
  • 给对应的dotnet pack任务传完全相同的--configuration $(BuildConfiguration)参数，强制打包步骤和构建步骤用同一套路径规则找dll
• 清理csproj里的硬编码路径
  • 打开GenericDataAccess.csproj，删掉所有没有加配置判断的固定输出路径（也就是那种不管什么配置都把输出指到bin\Production的全局配置）。如果确实需要给Production配置单独指定输出目录，一定要加上配置条件，不能全局覆盖：

    <OutputPath Condition="'$(Configuration)' == 'Production'">bin\Production\</OutputPath>
    

• 对齐服务器端的.NET SDK版本
  • 在流水线最开头加.NET SDK安装任务，指定和本地开发机完全一致的SDK版本，消掉因为版本差导致的路径解析逻辑不一致。别让服务器用和本地不一样的SDK版本跑相同的命令，这是本地能跑服务器炸的核心环境诱因。
• 切断打包步骤的独立路径计算
  • 如果排查下来还是有路径错位的问题，直接在dotnet pack的参数里加--no-build，明确告诉打包步骤：不要自己重新计算路径找dll，直接拿前序build步骤已经生成好的产物打包就行，从根源上避免pack自己算错路径。

内容的提问来源于stack exchange，提问作者Peter Villani