.NET RC1 Package broken, installation fails

[robertmclaws]

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!

[Atulin]

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.

[robertmclaws]

Just added a solution to the post. See above.

[Atulin]

Doesn't work with CPM, getting NU1011 errors.

[robertmclaws]

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

[joseftw]

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.

[robertmclaws]

@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.

[DUWENINK]

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

[Atulin]

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

[Dona278]

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.

[glen-84]

@roji FYI

[ChrisJollyAU]

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

[Dona278]

@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