Package source mapping cannot route version ranges of the same package ID to different feeds

Version Routing Limitations in NuGet

There is no supported configuration or extension point in NuGet to add version constraints to package source mapping. The packageSourceMapping logic operates exclusively on the package identifier (ID). Once a package ID pattern is mapped to a specific feed, NuGet will only query that feed for all versions of that package, regardless of whether they are stable, pre-release, or hosted on a different configured source.

The Impact on Transitive Dependencies

Because mapping applies to the entire dependency graph, the lack of version routing creates a strict boundary. If Package.A is mapped to a public feed, but a transitive dependency Package.B (required by a specific version of A) is only available in a private feed and is not explicitly mapped, the restore process will fail. NuGet will not "fall back" to other feeds to find a missing version if a mapping pattern for that ID exists elsewhere or if the ID is unmapped.

Recommended Design Patterns

To separate pre-release and stable feeds without resorting to a catch-all * pattern—which eliminates the security benefits of source mapping—consider these two architectural approaches:

• Distinct Package IDs (Suffixing): Use a naming convention to differentiate builds. For example, use Company.Project.Core for stable releases and Company.Project.Core.Beta or Company.Project.Core.Dev for pre-releases. This allows you to map the .Beta pattern to your internal feed and the stable pattern to your public feed.
• Unified Internal Feed (Upstream Sources): Instead of splitting feeds at the client level, use a package manager (like Azure Artifacts, Artifactory, or ProGet) that supports Upstream Sources. You map the package ID to a single internal feed; the server then handles the logic of whether to serve a local pre-release version or proxy a stable version from the public gallery.

Verification and Compatibility

To verify your current mapping behavior, you can run a restore with detailed logging to see which feeds are being queried:

dotnet restore --verbosity detailed

Ensure you are using NuGet 5.7 or later (or the corresponding .NET SDK). Versions prior to 5.7 ignore the packageSourceMapping section entirely, which may lead to "silent" successes that are actually bypassing your security constraints.

Diagnostic Detail: Are you using a package manager with upstream capabilities (e.g., Azure Artifacts), or are you relying solely on a nuget.config file with multiple raw HTTP endpoints?