I think everyone has encountered the frustrating scenario where your .NET solution builds perfectly on your local machine but mysteriously fails in Azure Pipelines. Most of the time there is a mistake you made that is easy to fix but sometimes it is the build tooling itself that causes the problem. And that is unfortunately exactly the case when using NuGet Package Source mapping in Azure Pipelines.
What is Package Source Mapping?
Package Source Mapping in NuGet, introduced in version 6.0, is a security-enhancing feature that allows developers to explicitly define which package sources should be used for specific packages in a project. Traditionally, NuGet would scan all configured sources—public or private—to find and restore packages, which could pose risks by inadvertently pulling packages from untrusted locations.
With Package Source Mapping, developers can centralize and control package restoration by specifying patterns that map packages to designated sources in the nuget.config file. Here is an example:
This ensures that, for example, internal packages are only retrieved from private feeds, while public packages come from trusted sources like nuget.org, thereby strengthening the software supply chain.
The problem: The magic feed prefix
We discovered the problem when we noticed that the dotnet restore build task was ignoring the package sources configured in our nuget.config file.
When drilling deeper into the build logs we discovered that Azure Pipelines will not use the available nuget.config file but uses a copy where it first applied some changes. And it were these changes that caused the problem.
The core issue lies in how Azure Pipelines handles NuGet feed names when using package source mappings. When you define a feed in your nuget.config file, Azure Pipelines automatically adds a feed- prefix to your feed names, breaking the mapping between your package sources and their corresponding package patterns.
Here is our original nuget.config:
And here is the copy that Azure Pipelines created:
Notice how the feed name became feed-company.be in the package sources section, but the package source mapping still references company.be. This mismatch causes NuGet to ignore your private feed entirely, leading to package resolution failures.
Why this happens?
This behavior stems from how Azure Pipelines processes NuGet configurations internally. The pipeline tasks modify your nuget.config file during execution, adding prefixes to feed names to avoid conflicts. However, they don't update the package source mapping section to match these renamed feeds.
The issue has been documented in several GitHub issues:
The workaround: Embrace the ‘feed’ prefix
Since Microsoft hasn't fixed this issue, you'll need to work around it by anticipating the feed prefix in your configuration.
As a workaround I updated my nuget.config to include a package source mapping containing the feed- prefix: