dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.72k stars 1.07k forks source link

Issue with dotnet-ef tool after moving to Dev Drive #33023

Open joakimriedel opened 1 year ago

joakimriedel commented 1 year ago

After moving all my sources and packages to a new Dev Drive following these instructions, the dotnet-ef tool would not work anymore.

dotnet-tools.json

{
  "isRoot": true,
  "tools": {
    "dotnet-ef": {
      "version": "7.0.5",
      "commands": ["dotnet-ef"]
    }
  }
}

CLI

PS D:\repos\project> dotnet ef
Run "dotnet tool restore" to make the "dotnet-ef" command available.
PS D:\repos\project> dotnet tool restore
Tool 'dotnet-ef' (version '7.0.5') was restored. Available commands: dotnet-ef

Restore was successful.
PS D:\repos\project> dotnet ef
Run "dotnet tool restore" to make the "dotnet-ef" command available.

No matter how I would try to restore the tools, even if it reported success, the tool was still not available.

After banging my head against this for some time, I found out that if I deleted the cache in the %USERPROFILE%\.dotnet\toolResolverCache folder followed by executing dotnet tool restore, the dotnet ef command would start working again.

Neither I nor GPT-4 could find any other mention of this problem somewhere. Perhaps if more people start moving to Dev Drive (20% less build time!) this step should be documented somewhere. Or if it's a bug, it would be nice if the dotnet tool restore command was a bit more resilent to a moved repository.

Include provider and version information

EF Core version: 7.0.5 Operating system: Windows 11 insider dev channel

ajcvickers commented 1 year ago

Moving to SDK, since this doesn't seem specific to the ef tool, but rather something wrong with .NET tools in general.

baronfel commented 1 year ago

This is a great report, thank you! I think what's happened is that the tool resolver cache points the various local tool installs to the packages directory, and so when you reconfigured that we didn't update our caches. @dsplaisted we should probably chat about mitigations here - perhaps the resolver cache file should store the observed global packages directory and invalidate of that has changed?

dsplaisted commented 1 year ago

Yes, seems like we should be doing something here to detect that the cache is invalid.

andrewlangemann commented 3 months ago

I also encountered this issue, but resolved it by deleting the toolResolverCache folder per this answer on #11432