dotnet-ef installation fails since 8.0 release

[vyruz1986]

Describe the bug

Running dotnet tool install dotnet-ef on a system which does not have the .NET 8.0 SDK installed, the installation fails with:

error NU1202: Package dotnet-ef 8.0.0 is not compatible with net7.0 (.NETCoreApp,Version=v7.0) / any. Package dotnet-ef 8.0.0 supports: net8.0 (.NETCoreApp,Version=v8.0) / any

While this makes somewhat sense, I'm wondering whether this is intended behaviour? We have a lot of pipelines running the above command to generate EF migration bundles, and the .NET 8.0 release effectively broke all of these pipelines.
I'm also quite sure that we didn't have this problem last year when .NET 7.0 was released.
Since azure devops hosted build agents have apparently not yet been upgraded to .NET 8.0 (which was also the case in the first months 7.0 was released), this fails.

I'm aware this can be fixed by either installing the 8.0 SDK in a previous step in the build pipeline, or by specifying the dotnet-ef version (e.g. dotnet tool install dotnet-ef --version 7.0.14), but both of those solutions would require modifying all existing pipelines, and mantaining either of those versions going forward.

Isn't the .NET SDK supposed to figure out whichever tool release is compatible with my local SDK version, and install that release instead of mindless attempting to install whichever latest version is published?

To Reproduce

1. Start from a clean system
2. Install the .NET 7.0 SDK
3. Run dotnet tool install dotnet-ef

[baronfel]

This may have been regressed with some recent tool install work we did - @JL03-Yue can you add this to your list to investigate? What I think may be happening is that we are defaulting to 'latest version' instead of filtering the list of versions to those that support the implicit TFM of the currently-running SDK.

[KalleOlaviNiemitalo]

Did that "recent tool install work" go to .NET SDK 8 only, or was it backported to 7 as well? If the problem occurs in a computer with only .NET SDK 7 installed, then it cannot be caused by any change in tool installation logic in .NET SDK 8 only.

[baronfel]

That was .NET 8 only. I don't understand your meaning @KalleOlaviNiemitalo - as I understand it @vyruz1986 said that the 6->7 transition didn't have this problem, so it must have been something introduced in the 7->8 transition?

[baronfel]

@KalleOlaviNiemitalo I understand now - I completely misread the initial submission. Thanks for poking :)

[baronfel]

I think this worked on .NET 7 because the EF tool targeted the net6.0 TFM. Since they've bumped to targeting net8.0 I just kind of expect this to happen. @ajcvickers do you have any guidance for folks that need to use the tool in CI scenarios? should they always be pinning?

[ajcvickers]

@bricelam Did we intentionally bump the tool to 8.0?

[dsplaisted]

Looks like the ASP.NET build ran into this too here: dotnet/aspnetcore#52045 (comment)

[bricelam]

@bricelam Did we intentionally bump the tool to 8.0?

Yes, EF8 requires .NET 8 (including the tools). If you need an older version of .NET, use an older version of the tool.

[Joren-Thijs]

I ran into this as well today. Is there any merit to @vyruz1986's comment on "Isn't the .NET SDK supposed to figure out whichever tool release is compatible with my local SDK version, and install that release instead of mindless attempting to install whichever latest version is published?"? I would also hate to start manually specifying dotnet-ef versions everywhere.

A possible workaround I did find is that the dotnet install command does appear to accept wildcards so you could use
dotnet tool install -g dotnet-ef --version 7.* to keep using the latest 7.x version. And then update it to 8.* when you upgrade to EF8.

[mcallaghan-geotab]

How is it expected for systems that have multiple SDKs installed (to support multiple project development ecosystems).

Imagine a developer workstation that has .NET6, .NET7, and .NET8 SDKs now installed. If the latest global tools are not backwards compatible with prior SDKs, what are they supposed to do?

[baronfel]

@mcallaghan-geotab for the short term, I'd suggest that users that have explicit version requirements install EF as a local tool instead of as a global tool. This will allow them to pin to versions that work with the various SDKs that their individual projects might be pinning to via global.json.

Longer term we are working on enhancements to the .NET Tool install and run commands that let users specify how the tool should 'roll forward' to runtimes that aren't specifically supported. We're also working on a feature where tool install will warn you at install time if a tool will not work on your system due to missing or incompatible runtimes.

[baronfel]

Is there any merit to @vyruz1986's comment on "Isn't the .NET SDK supposed to figure out whichever tool release is compatible with my local SDK version, and install that release instead of mindless attempting to install whichever latest version is published?"

There 100% is merit to this comment, and we are working on adding this capability. It's just not how tools were originally designed, so it's taking a bit of time to ensure we can do the detection accurately.

[mcallaghan-geotab]

@baronfel

@mcallaghan-geotab for the short term, I'd suggest that users that have explicit version requirements install EF as a local tool instead of as a global tool. This will allow them to pin to versions that work with the various SDKs that their individual projects might be pinning to via global.json.

hey thanks for the suggestion - for the "local tool" install, and "pin to versions" via global.json, might you have a decent documentation reference for me?

[baronfel]

@mcallaghan-geotab There's some docs here: https://learn.microsoft.com/en-us/dotnet/core/tools/local-tools-how-to-use

The gist is:

• in the repo root, run dotnet new tool-manifest
• install tools with dotnet tool install <toolname> (note the absence of the -g options)
• check in the tools manifest to source control
• run the tool with dotnet ef .....

[NewkyNet]

We ran into this yesterday(2/13) and today(2/14). I wanted to get it at least documented so the situation is at least know.

During our CI build we install dotnet-ef so it can create bundles to be used in later release pipelines. When the agent does this it currently is finding version 8.0.2 of the tool to install but does not have the ability to run that version later as it is greater than the currently available SDK.

Pinning a full version seems to defeat the purpose of getting minor updates when available. Pinning at the major would have had the same outcome as this is a minor version bump. I'm guessing if we wait a few days the hosted agents will update but will again come across these issues the next time dotnet-ef updates prior to the agent getting an SDK bump.

Running on vmImage: ubuntu-latest

Simplified example of steps

• dotnet new tool-manifest
• dotnet install dotnet-ef
  • Tool 'dotnet-ef' (version '8.0.2') was successfully installed. Entry is added to the manifest file /home/vsts/work/1/s/.config/dotnet-tools.json.
• dotnet build
  • .NET SDK: Version: 8.0.101
• dotnet ef migrations bundle --self-contained -r linux-x64 --output $(Build.ArtifactStagingDirectory)/efmig/DbContext.exe
• dotnet ef migrations bundle --self-contained -r win-x64 --output $(Build.ArtifactStagingDirectory)/efmig/win/DbContext.exe

dotnet ef migration errors produced

The below error occurs on each of the steps

App: /home/vsts/work/1/.nuget/packages/dotnet-ef/8.0.2/tools/net8.0/any/dotnet-ef.dll
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '8.0.2' (x64)
.NET location: /usr/share/dotnet/

The following frameworks were found:
  6.0.26 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  7.0.15 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  8.0.1 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

[baronfel]

@NewkyNet this won't be fixed until the March servicing releases, unfortunately - the fix for this is targeted to 8.0.3, which releases next month: dotnet/efcore#32869 Once that releases, any .NET 8 SDK/Runtime should be able to run the 8.0.3 version of dotnet-ef, so dotnet tool install dotnet-ef should Just Work.

[manzur-billiyo]

it's an annoying issue, i have .net 8.0, some of my colleagues have 8.0.1. the current ef tool version is 8.0.2. it's failing for everyone now. I used to specify the version so far instead of upgrading my sdk to 8.0.1. it's not sustainable.

[Herve-M]

So what version pair is working right now in Azure DevOps CI context?
SDK-8.0.100 with dotnet-ef 8.0.0?