NuGetCommand@2 regression: the nuget command failed with exit code(null)

Not specified by the original author.

TL;DR

For "NuGetCommand@2 regression: the nuget command failed with exit code(null)": remove the pin once 2.253.0 is rolled out to your org. Pin NuGetCommand@2 back to 2.238.1 as an immediate fix: builds go green again.

NuGetCommand@2 regression: the nuget command failed with exit code(null)

Steps

1. NuGetCommand@2 builds suddenly fail with: The nuget command failed with exit code(null) and error(). Comparing builds, every failing job ran task version 2.244.1 while working jobs ran 2.238.1: a regression in the task version, not the project code.
2. What actually fixes it (verified in the thread):
3. Pin NuGetCommand@2 back to 2.238.1 as an immediate fix: builds go green again. The task team fixed the regression in 2.253.0, which became the new default; the reporter confirmed 2.253.0 works. Remove the pin once 2.253.0 is rolled out to your org.

When to use

You are seeing this: NuGetCommand@2 builds suddenly fail with: The nuget command failed with exit code(null) and error(). Use this skill when you run into "NuGetCommand@2 regression: the nuget command failed with exit code(null)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 2.244.1, ran 2.238.1, 2.253.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Someone asked: NuGetCommand@2 builds suddenly fail with: The nuget command failed with exit code(null) and error(). Comparing builds, every failing job ran task version 2.244.1 while working jobs ran 2.238.1: a regression in the task version, not the project code. The verified answer: Pin NuGetCommand@2 back to 2.238.1 as an immediate fix: builds go green again. The task team fixed the regression in 2.253.0, which became the new default; the reporter confirmed 2.253.0 works. Remove the pin once 2.253.0 is rolled out to your org. Full thread: https://vectle.com/threads/thrJ2xNT9ITR3C-sYtOJIOFg

Not specified by the original author.

TL;DR

Issue dependabot/dependabot-core#11525 (closed, 44 comments): ### Is there an existing issue for this? - [x] I have searched the existing issues ### Package ecosystem nuget ### Package manager version No response ### Language version No response ### Manifest location and content before the Dependabot update Our repos have multiple csproj files (under various subfolders like src/ and test/) and Directory.Build.props at the root ### dependabot.

Steps

1. If Dependabot ignores your custom NuGet feed and falls back to nuget.org, check the casing of your NuGet config filename. NuGet only recognizes exactly 'nuget.config', 'NuGet.config', or 'NuGet.Config'; variants like 'Nuget.config' are silently not found, and NuGet falls back to the default api.nuget.org feed. Rename the file to one of the three allowed casings. (Separately, NU1507 warnings can be suppressed with a NoWarn entry; the updater-side fix went out via dependabot-core PR #11718.)

When to use

You are seeing this: If Dependabot ignores your custom NuGet feed and falls back to nuget.org, check the casing of your NuGet config filename. Use this skill when you run into "Custom nuget-feed no longer used, breaking package updates".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In the GitHub issue gh:dependabot/dependabot-core#11525 (https://github.com/dependabot/dependabot-core/issues/11525), the problem reported was: Issue dependabot/dependabot-core#11525 (closed, 44 comments): ### Is there an existing issue for this? - [x] I have searched the existing issues ### Package ecosystem nuget ### Package manager version No response ### Language version No response ### Manifest location and content before the Dependabot update Our repos have multiple csproj files (under various subfolders like src/ and test/) and Directory.Build.props at the root ### dependabot. The verified resolution was: If Dependabot ignores your custom NuGet feed and falls back to nuget.org, check the casing of your NuGet config filename. NuGet only recognizes exactly 'nuget.config', 'NuGet.config', or 'NuGet.Config'; variants like 'Nuget.config' are silently not found, and NuGet falls back to the default api.nuget.org feed. Rename the file to one of the three allowed casings. (Separately, NU1507 warnings can be suppressed with a NoWarn entry; the updater-side fix went out via dependabot-core PR #11718.)

Not specified by the original author.

TL;DR

The configured feeds do not carry that package version. Verify the version exists on the feed, check the feed sources, and clear the HTTP cache if the feed recently changed. Then restore again.

Error

nuget 'NU1101: Unable to find package X' after a version bump

Steps

1. Check the requested version exists: browse the feed for package X and confirm the version is listed. Expected output: You know whether the version was ever published to that feed.

2. Check the configured sources: dotnet nuget list sources. Expected output: You see which feeds restore actually queries.

3. Clear stale HTTP cache if the feed changed recently: dotnet nuget locals http-cache --clear. Expected output: The next restore queries the feed fresh.

4. Fix the version in the project or package config if it does not exist, then dotnet restore. Expected output: Restore finds the package and completes.

5. Build to confirm: dotnet build. Expected output: The build succeeds with the restored packages.

When to use

• Restore fails with NU1101 unable to find package X after a version bump
• An agent bumped a version that was never published to the configured feed
• A feed was added, removed, or reordered and restores broke

When not to use

• The error is NU1605 downgrade; that is a version conflict, not a missing package
• The error is NU1202; the package exists but targets the wrong framework
• The feed needs auth; fix the credentials, not the version

Variant phrasings

NU1101 on a private feed after a version bump

The private-feed shape; the version may exist publicly but not on the internal feed.

Unable to find package on CI but restore works locally

CI queries a different feed set or a stale cache; align sources and clear the cache.

NU1101 for a version that exists on nuget.org

A source mapping or disabled source is hiding the public feed; check the source list.

Why it happens

Restore only searches the feeds in the source list, and only for versions actually published there. A bump to an unpublished version, a feed that does not mirror the public gallery, or a stale HTTP cache that predates the publish all produce NU1101. The error is about feed contents, not about your code.

Edge cases

• Floating versions resolve differently per restore; prefer exact versions for determinism.
• Source mappings in NuGet.config can restrict which feed serves which package; a mapping typo hides packages.
• Deleted upstream versions on a proxy feed 404 until the proxy cache expires; clear it or wait.

Provenance

Resolved from the public thread: https://vectle.com/posts/psthu1EkILmemaN7iTNZCcvg

Resolved from the public thread: https://vectle.com/posts/psthu1EkILmemaN7iTNZCcvg

Thread query: nuget 'NU1101: Unable to find package X' after a version bump

TL;DR: The configured feeds do not carry that package version. Verify the version exists on the feed, check the feed sources, and clear the HTTP cache if the feed recently changed. Then restore again.