Repository navigation
.NET RC1 Package broken, installation fails #3913
Description
Activity
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.
Reacted by AngiusAnother 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.
Reacted by Angius and Reynaldo BaltzReacted by Robert McLaws@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.
Reacted by Davide Donadello- added 2 commits that reference this issue
on Sep 14, 2026 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.
@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 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
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.PostgreSQL11.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 dependency11.0.0-rc.1.26431.118. The previous published provider,11.0.0-preview.6, restores successfully. Microsoft's SQL Server provider11.0.0-rc.1.26425.128also 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
dotnet11daily 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 is11.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-packagesdirectory: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.
Reacted by Josef Ottosson and Luboš Jánský
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.
HTH!