.NET RC1 Package broken, installation fails

BREAKING ISSUE

It appears that you folks used AI to complete a migration to Centralized Package Management and Package Pinning.

Instead of specifying the EFCore packages as an 11.- or something similar, they are pointed to a package version (11.0.0-rc.1.26431.118) that does not actually exist.

Each package should be pointing to its own version because it's entirely possible that the EFCore team will post an out-of-band release between cycles if they find a problem.

In the meantime, 11.0.0-rc.1.26425.128 is the correct version.

SOLUTION FOR DEVELOPERS IMPACTED

The solution for now is to directly reference transitive packages.

        <PackageReference Include="Microsoft.EntityFrameworkCore" Version="11.*-*" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="11.*-*" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="11.*-*" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="11.*-*" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="11.*-*" />

HTH!

Can confirm:

2>Ogma3.Data.csproj: Error NU1102 : Nie można znaleźć pakietu Microsoft.EntityFrameworkCore.Relational w wersji (= 11.0.0-rc.1.26431.118)
  - Znalezione wersje w nuget.org: 295 [ Najbliższa wersja: 11.0.0-rc.1.26425.128 ]
  - Wersje z davidfowl-aspire nie zostały uwzględnione
  - Wersje z NpgSQL Nightly nie zostały uwzględnione
2>------- Finished building project: Ogma3.Data. Succeeded: False. Errors: 1. Warnings: 0

(god I wish I could change the language of those messages to English)

Looks like Copilot, or whatever was used to slop the migration together, hallucinated a nonexistent version. The latest version from the CI feed, https://www.myget.org/F/npgsql-vnext/api/v3/index.json, has the same issue.

Just added a solution to the post. See above.

Doesn't work with CPM, getting NU1011 errors.

Then you need to point to the correct version I specified in my post instead of the wildcard.

Another workaround, add the .net 11 nuget feed.

<Project>
    <PropertyGroup>
        <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
        <EntityFrameworkNugetPackageVersion>11.0.0-rc.1.26431.118</EntityFrameworkNugetPackageVersion>
        <MicrosoftNugetPackageVersion>11.0.0-rc.1.26431.118</MicrosoftNugetPackageVersion>
    </PropertyGroup>
   <ItemGroup>
       <PackageVersion Include="Microsoft.EntityFrameworkCore" Version="$(EntityFrameworkNugetPackageVersion)"/>
       <PackageVersion Include="Microsoft.EntityFrameworkCore.Design" Version="$(EntityFrameworkNugetPackageVersion)"/>
       <PackageVersion Include="Microsoft.EntityFrameworkCore.Relational" Version="$(EntityFrameworkNugetPackageVersion)"/>
       <PackageVersion Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="11.0.0-rc.1"/>
       <PackageVersion Include="Npgsql.EntityFrameworkCore.PostgreSQL.NodaTime" Version="11.0.0-rc.1"/>
   </ItemGroup>

nuget.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <add key="dotnet11" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet11/nuget/v3/index.json" />
        <add key="npgsql-vnext" value="https://www.myget.org/F/npgsql-vnext/api/v3/index.json" />
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    </packageSources>

    <packageSourceMapping>
        <packageSource key="nuget.org">
            <package pattern="*" />
            <package pattern="Npgsql" />
            <package pattern="Npgsql.*" />
        </packageSource>
        <packageSource key="npgsql-vnext">
            <package pattern="Npgsql" />
            <package pattern="Npgsql.*" />
        </packageSource>
        <packageSource key="dotnet11">
            <package pattern="*" />
        </packageSource>
    </packageSourceMapping>

</configuration>

Just updated to the rc and everything builds in ci for me.

@joseftw

@joseftw That just means that my downstream customers also have to take that dependency.

It's fine if you are the end product but not fine if you're a library that uses this library.

feat: retarget the 11.x line to net11.0 and EF Core 11

chore(release): open the 11.x line on net11.0 as 11.0.0-preview.1

same as/to/with me ,sorry my english is rabbish

I made a fork for my own usage from the GH feed, until it's fixed. Maybe someone will find it useful: https://github.com/Atulin/efcore.pg

preview-7 skipped for some reason, release-candidate-1 unusable due to wrong version pin, CI/DI to change to add another feed in the way to maybe use "next" version. Currently companies which use EFCore.Npgsql can't test dotnet11.rc-1 because of this. The workaround described above force us to add a lot of copy-paste "TODO REMOVE" (we haven't a single project with one ref to this package) and even with that fix some test throws because of "MissingMethod". In 4 days no a rc-1.xxxx has been deployed to fix this, I suppose will be delayed directly to the rc-2, hoping in a usable version.

@roji

@roji FYI

@Dona278

@Dona278 i beleive preview 7 was skipped because of a problematic breaking change in EF itself (see the comment in #3898 and #3897 (comment))

@ChrisJollyAU

@ChrisJollyAU oh I missed the issue and the comment, thanks. But I think that this is a +1 point to "make a version that work"! People were waiting for preview7, never released but with a hope into rc1, then rc1 is released but pinned to a non public version of efcore rc1 and nothing was released in the meanwhile to make it work again (maybe another rc1 with correct version?). Preview and rc are window to test and collect bugs and feedback but in this way it is hard to maintain in large applications

@roji

Is there any update on this @roji ?

Sorry, missed this in the flurry of issues. I'll take a look over the weekend.

AI Triage

The below is an AI-generated analysis and may contain inaccuracies.

Confirmed: this is a packaging regression in Npgsql.EntityFrameworkCore.PostgreSQL 11.0.0-rc.1. With a fresh package cache and only nuget.org configured, restore fails with NU1102 for the exact EF Core and EF Core Relational dependency 11.0.0-rc.1.26431.118. The previous published provider, 11.0.0-preview.6, restores successfully. Microsoft's SQL Server provider 11.0.0-rc.1.26425.128 also restores successfully from nuget.org alone; this is an Npgsql release-dependency problem, not a general EF Core restore failure. No likely upstream duplicate was found.

The dependency version does exist on the public dotnet11 daily feed, but is not published on nuget.org. It was selected by the RC1 dependency update. Exact pinning is intentional for previews because provider-facing APIs can change between builds; the problem is the chosen daily version, not Central Package Management itself. The public RC1 version is 11.0.0-rc.1.26425.128.

CI missed this because the repository's NuGet configuration includes the daily feed. Builds, tests, and packing therefore resolve the dependency successfully. The release job had no consumer restore check restricted to nuget.org before publication.

A local fix has been prepared to align EF Core and Microsoft.Extensions dependencies to the public RC1 build, retaining exact EF pinning, and to add a pre-publication nuget.org-only restore check for the three provider source projects, with a fresh package cache. The simplified check rejects the original daily EF dependency and accepts the corrected core, NodaTime, and NetTopologySuite projects. Separately, the corrected generated packages were also verified with a clean consumer restore. The solution builds; 491 unit tests and 584 representative query/JSON functional tests pass, with 6 existing unit-test skips. The corrected package also restores and translates a simple query in a separate consumer project. These changes have not been published; a new package release is still required.

minimal repro

No database or application code is needed: the failure occurs during package restore.

Repro.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net11.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="11.0.0-rc.1" />
  </ItemGroup>
</Project>

NuGet.config:

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

With the .NET 11 RC1 SDK and a previously nonexistent empty-packages directory:

dotnet restore Repro.csproj --configfile NuGet.config --packages ./empty-packages

The result includes:

error NU1102: Unable to find package Microsoft.EntityFrameworkCore with version (= 11.0.0-rc.1.26431.118)
error NU1102: Unable to find package Microsoft.EntityFrameworkCore.Relational with version (= 11.0.0-rc.1.26431.118)

Released v11.0.0-rc.1.1, sorry for the botched release and the delay everyone.

Instead of specifying the EFCore packages as an 11.- or something similar, they are pointed to a package version (11.0.0-rc.1.26431.118) that does not actually exist.

This has nothing to do with AI, and it's in general a pretty bad idea to leave dependency versions floating. The bug here was accidentally using the daily build feed when bumping versions, which contains newer versions that aren't on nuget.org. I'm adding a CI check to ensure this doesn't happen again.

Each package should be pointing to its own version because it's entirely possible that the EFCore team will post an out-of-band release between cycles if they find a problem.

That's not how the .NET/EF build process works; all versions are aligned and the whole thing ships with a single one version.

Fix RC1 dependencies and validate release restores

Navigation Menu

Repository navigation

.NET RC1 Package broken, installation fails #3913

BREAKING ISSUE

SOLUTION FOR DEVELOPERS IMPACTED

AI Triage

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

.NET RC1 Package broken, installation fails #3913

Description

BREAKING ISSUE

SOLUTION FOR DEVELOPERS IMPACTED

Activity

Atulin commented on Sep 14, 2026

robertmclaws commented on Sep 14, 2026

Atulin commented on Sep 14, 2026

robertmclaws commented on Sep 14, 2026

joseftw commented on Sep 14, 2026

robertmclaws commented on Sep 14, 2026

DUWENINK commented on Sep 16, 2026

Atulin commented on Sep 18, 2026

Dona278 commented on Sep 18, 2026

glen-84 commented on Sep 18, 2026

ChrisJollyAU commented on Sep 18, 2026

Dona278 commented on Sep 18, 2026

janzen01 commented on Sep 24, 2026

roji commented on Sep 24, 2026

roji commented on Sep 24, 2026

AI Triage

roji commented on Sep 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions