nuget.config breaks Nuget packages from private repositories

[cdbrown2018]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The nuget.config file that's generated by the Aspire CLI breaks building in CI environments. I have packages hosted in a private GitLab package repository, and when running dotnet build or dotnet restore in a CI environment, it fails with the following error:

/redacted/path/to/my/CsProj.csproj: error NU1101: Unable to find package REDACTED. No packages exist with this id in source(s): https://api.nuget.org/v3/index.json. PackageSourceMapping is enabled, the following source(s) were not considered: DEPOT. [/redacted/path/to/my/APIsln]

Expected Behavior

I believe the point of nuget.config is to allow nuget to know where to pull packages from, whether that's a local hive, pre-release repositories, or public stable repositories(?). This should not disable the discovery of packages from private repositories.

Steps To Reproduce

1. Reference a package from a private repository. (My reference is in a C# project that's registered with the AppHost, though I believe the same effect can be achieved by referencing the package in the AppHost's project)
2. Create a nuget.config using the Aspire CLI (I believe this is done by installing a local hive or by changing the channel from stable to daily)
3. Attempt to build the project in a CI environment.

Exceptions (if any)

No response

Aspire doctor output

No response

Anything else?

No response

[joperezr]

🤖 Aspire triage pass — 2026-05-11 23:00 UTC

Area: area-cli
Kind: bug
Repro: partial — steps describe shape (private package + generated nuget.config + CI build) but no concrete nuget.config snippet or exact CLI invocation is included; error message quoted verbatim shows packageSourceMapping excluding the private feed DEPOT
Affected version(s): not stated — needs clarification (CLI build / channel used)
Severity: S2 — breaks dotnet build / dotnet restore in CI for any user with Aspire.* packages routed via packageSourceMapping plus a private feed for non-Aspire packages; workaround = hand-edit nuget.config after Aspire generates it

Urgency: 🟡 vNext — recommend milestone 13.4
Reason: real CI-blocker for a known scenario (private package feeds are common), but with a manual workaround. The generated packageSourceMapping should leave non-Aspire.* patterns flowing to user-defined sources rather than implicitly restricting them.

Suggested owner(s): @JamesNK (score 43), backup @mitchdenny (score 2)
Evidence:

• JamesNK authored 43/50 recent merged area-cli PRs in the last 90d
• CODEOWNERS lists @mitchdenny @JamesNK @davidfowl for /src/Aspire.Cli

Confidence: medium
Needs human?: yes — triage:needs-human — affected version is not stated; please confirm whether this reproduces against the latest 13.3 stable CLI or only the daily/local-hive channels (the issue mentions installing a local hive or switching to daily)

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[cdbrown2018]

Reading through the triage reports, I can verify this bug is on the latest stable release of aspire - 13.3.0 with all of the latest packages obtained by aspire update —channel stable

[joperezr]

Thanks for logging this @cdbrown2018. I'm not sure I'm following the scenario here, (a minimal repro project would be very helpful!). Are you saying that you already have a nuget.config that references your private feed, and that running aspire update is overriding this and removing your feed?

[cdbrown2018]

I'm trying to make a repro project, but finding it difficult due to needing to reference a private repository. Here is a simple repro of a .csproj file in a brand new Aspire app.

<Project Sdk="Aspire.AppHost.Sdk/13.3.1">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <UserSecretsId>edd2d111-4cb4-4c7a-8418-44216ba64c4a</UserSecretsId>
    <RestoreAdditionalProjectSources>
      https://my.private.package.repository/index.json
    </RestoreAdditionalProjectSources>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\aspire-playground.Server\aspire-playground.Server.csproj" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Aspire.Hosting.JavaScript" Version="13.4.0-local.20260514.t030048" />
    <PackageReference Include="Aspire.Hosting.Kubernetes" Version="13.4.0-local.20260514.t030048" />
    <PackageReference Include="Aspire.Hosting.Redis" Version="13.4.0-local.20260514.t030048" />
    <PackageReference Include="My.Custom.Package" Version="1.0.0" />
  </ItemGroup>
</Project>

I believe the key item here is the RestoreAdditionalProjectSources tag. When a nuget.config file is generated, dotnet restore stops respecting the source, presumably because of the wildcard in the config file. I'll see if I can track down some logs

[cdbrown2018]

Example error from logs:

/path/to/ci/project/Api.Database.csproj : error NU1101: Unable to find package IMOM.JSON. No packages exist with this id in source(s): https://api.nuget.org/v3/index.json. PackageSourceMapping is enabled, the following source(s) were not considered: DEPOT. [/path/to/ci/project/MySolution.slnx]

DEPOT is a nuget source that was added using dotnet nuget add source

This is the nuget.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="https://api.nuget.org/v3/index.json" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceMapping>
    <packageSource key="https://api.nuget.org/v3/index.json">
      <package pattern="*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

This config was created when running aspire update --channel stable (13.3.5 at the time of writing).

And here is a .csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Aspire.Npgsql.EntityFrameworkCore.PostgreSQL" Version="13.3.5" />
    <PackageReference Include="IMOM.JSON" Version="1.14.3" /> <!-- This is the problem package -- it's hosted privately -->
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="10.0.5">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Microsoft.Extensions.Hosting" Version="10.0.6" />
    <PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="10.0.0" />
    <PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL.Design" Version="1.1.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\Path\To\Proj.Common.csproj" />
  </ItemGroup>

</Project>

[cdbrown2018]

Sorry for spamming this issue. I just realized what the difference is between local and CI environments. In CI I have to run dotnet nuget source add prior to running tests/building so that we can use the runner's credentials when authenticating with the package repository.