Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
joakimriedel opened this issue Jun 3, 2023 · 4 comments
Open

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

joakimriedel opened this issue Jun 3, 2023 · 4 comments
Milestone

Comments

@joakimriedel
Copy link

joakimriedel commented Jun 3, 2023

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
Copy link
Member

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

@ajcvickers ajcvickers transferred this issue from dotnet/efcore Jun 4, 2023
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Tools untriaged Request triage from a team member labels Jun 4, 2023
@baronfel
Copy link
Member

baronfel commented Jun 4, 2023

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
Copy link
Member

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

@dsplaisted dsplaisted added this to the .NET 8.0 milestone Jun 6, 2023
@dsplaisted dsplaisted removed the untriaged Request triage from a team member label Jun 6, 2023
@JL03-Yue JL03-Yue modified the milestones: .NET 8.0, 9.0.1xx Oct 20, 2023
@JL03-Yue JL03-Yue removed their assignment Apr 19, 2024
@andrewlangemann
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants