Dotnet pack with projectstyle PackageReference on Azure Devops fails with "NuGet Error NU5019: File not found"

Question

I'm trying to produce a NuGet package from a C# project on Azure DevOps. I've set up a 'dotnet pack' task in a build pipeline for generating the package. The project is targeting netstandard20. The projectstyle is PackageReference. It has some dependencies, but only ones available on nuget.org.

The build task fails with error NU5019: File not found

Here's the output from the build task:

Build log

NU5019 means that the nuspec file "...contained files that do not exist": https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu5019

The extracted .nuspec file which is generated by the build task contains this <files> section:

  <files>
    <file src="C:\agent\_work\23\s\GenericDataAccess\bin\Production\netstandard2.0\Sparinvest.GenericDataAccess.dll" target="lib\netstandard2.0\Sparinvest.GenericDataAccess.dll" />
  </files>

It seems to me, the build step builds the .dll and then immediately is unable to find it for packing. However, the .dll is produced.

When I execute the same commandline (seen in the build log) locally on my machine, there's no problem.

I notice, however, that .Net versions are not the same on my machine vs. the build server (see build log): My machine

Can anyone help me to figure out what the problem is with the build step and how I can make it work?

NOTE: I would prefer to use 'dotnet pack' rather than NuGet.exe, because dotnet is able to include dependencies in the pack (NuGet doesn't support PackageReference style).

Answer 1

This appears to be an issue solved with newer Tooling versions (I see your msbuild version is 16.3 - at the time of writing recent SDKs carry 16.9 or a 16.10 preview).

Use the Use .NET Core task to install a more recent dotnet SDK version either through the pipeline UI or for YAML pipelines use something like:

- task: UseDotNet@2
  displayName: 'Install .NetCore 5.0.x'
  inputs:
    packageType: 'sdk'
    version: '5.0.x'

Answer 2

Thank you, Martin, for leading me in the right direction.

I don't know exactly what it was, the older dotnet SDK version was unable to do, but a newer version solved the problem.

What I did to make the build work:

To see which version I had on my machine where the pack command worked without issues:

dotnet --info

(You could do the same command in a build task in you pipeline to see the versions installed on the build server) On my machine the newest SDK version was 5.0.101.

I added the ".NET Core SDK/runtime installer" task before the pack task and specified Version 5.0.101. Note: I had to select a newer Task version (2.* (preview)) in order to install version 5.0.101 of the SDK.

Use .NET 5.0.101 task

The output from the first build run after that, was much nicer:

##[section]Starting: dotnet pack
==============================================================================
Task         : .NET Core
Description  : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version      : 2.153.3
Author       : Microsoft Corporation
Help         : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
[command]C:\Windows\system32\chcp.com 65001
Active code page: 65001
[command]C:\agent\_work\_tool\dotnet\dotnet.exe pack C:\agent\_work\23\s\GenericDataAccess\GenericDataAccess.csproj --output C:\agent\_work\23\a /p:Configuration=Production /p:PackageVersion=1.0.1678

Welcome to .NET 5.0!
---------------------
SDK Version: 5.0.101

Telemetry
---------
The .NET tools collect usage data in order to help us improve your experience. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

----------------
Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
Learn about HTTPS: https://aka.ms/dotnet-https
----------------
Write your first app: https://aka.ms/dotnet-hello-world
Find out what's new: https://aka.ms/dotnet-whats-new
Explore documentation: https://aka.ms/dotnet-docs
Report issues and find source on GitHub: https://github.com/dotnet/core
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli
--------------------------------------------------------------------------------------
Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored C:\agent\_work\23\s\GenericDataAccess\GenericDataAccess.csproj (in 4,06 sec).
  GenericDataAccess -> C:\agent\_work\23\s\GenericDataAccess\bin\Production\netstandard2.0\Sparinvest.GenericDataAccess.dll
  Successfully created package 'C:\agent\_work\23\a\Sparinvest.GenericDataAccess.1.0.1678.nupkg'.
##[section]Finishing: dotnet pack

Answer 3

From your provided snapshots, the dotnet pack command is pack ***.csproj --output ***/a /p:Configuration=Production /p:PackageVersion=1.0.1675 in Azure pipeline but in your local command is pack ***.csproj --output ***/a /p:Configuration=Production /p:PackageVersion=1.0.0.

Do you specify the variable PackageVersion in Azure pipeline resulting in it uses different package version? If you use the .NET Core CLI task, please check its parameter settings.