dotnet paket fails after installing VS 2019 16.8

[DanJensen]

Description

I've been using paket as a .net tool for a netcoreapp3.1 project. However, after installing the latest update to VS2019 (16.8) yesterday, I'm getting a errors when I try to run dotnet paket restore . It was working prior to this.

Repro steps

Please provide the steps required to reproduce the problem

1. dotnet tool restore

2. dotnet paket restore

Expected behavior

Packages should be restored without errors.

Actual behavior

Getting these errors:

Cannot use file stream for [C:\Users\dan.jensen.nuget\packages\paket\5.251.0\tools\netcoreapp2.1\any\paket.deps.json]: No such file or directory
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Users\dan.jensen.nuget\packages\paket\5.251.0\tools\netcoreapp2.1\any'.
Failed to run as a self-contained app.

• The application was run as a self-contained app because 'C:\Users\dan.jensen.nuget\packages\paket\5.251.0\tools\netcoreapp2.1\any\paket.runtimeconfig.json' was not found.
• If this should be a framework-dependent app, add the 'C:\Users\dan.jensen.nuget\packages\paket\5.251.0\tools\netcoreapp2.1\any\paket.runtimeconfig.json' file and specify the appropriate framework.

Known workarounds

The old school paket.exe approach does work for me.

[forki]

Oh boy. No idea what that is about

[isaacabraham]

@DanJensen this is going to sound silly, but have you rebooted since installing 2019? I had a bunch of crazy errors after installing - I couldn't even build my projects.

[DanJensen]

Yeah I've rebooted. I can't explain it. I have a global.json that specifies 3.1.302. I tried updating to paket 5.252.0, but still get those errors above. I tried using the old school paket.exe approach, and that does work. I just changed to the tool approach a couple weeks ago, so I hate to revert back if I can help it.

[mnmr]

It seems very likely that this issue is caused by the fact that you now have .NET 5 installed. If you have a global.json that overrides the SDK version, make sure that you do indeed have this SDK version installed and available on the system, as it will silently fall back to using the newest available. The rules for SDK selection are described here.

Update: I was able to install paket 5.252.0 as a global tool and run it without issues (with VS 16.8 and .NET 5 installed). I'd recommend you try to remove and re-install it, in case the current installation has somehow become corrupted.

[forki]

just to clarify @DanJensen - are you using paket as global or local paket tool?

/cc @cartermp

[DanJensen]

@mnmr I do have 3.1.302 installed, yes. That's what our code is targeting. We had to be specific with that due to the bug in newer SDKs that cause a problem using paket to create nuget packages.

@forki I'm using it as a local tool, via the .config folder. I'll paste the dotnet-tools.json below. One thing I noted: I do have another git repo that is working fine. However, that one only uses one dotnet tool, paket. The one that's causing me trouble uses two: paket and fake. I don't know why that would matter, unless my syntax is wrong in the json file. But they do both install correctly when I do the tool restore. So it may be nothing.

{
  "version": 1,
  "isRoot": true,
  "tools": {
    "fake-cli": {
      "version": "5.20.3",
      "commands": [
        "fake"
      ]
    },
    "paket": {
      "version": "5.252.0",
      "commands": [
        "paket"
      ]
    }
  }
}

[forki]

/cc @matthid

[DanJensen]

A little more info after some experimenting. On my git repo that works, I updated it to paket 5.252.0, and then it started failing with the same error. I downgraded it back to 251, and it worked fine. I went back and forth a few times just to make sure it wasn't a fluke, and this behavior was consistent. It works with 251, and fails with 252.

After doing that, I went back to my troublesome git repo (which is much larger btw), and downgraded it back to 251. Still failed. I tried a bunch of combinations of things: copying the paket.dependencies and paket.lock from the working repo over to this one to see if it made a difference; removing tons of files to get to a mostly empty directory; deleting the packages folder to force it to start fresh; making sure the .paket folder matched between the two repos; deleting everything out of the paket-files folder. Somehow I got it to work one time, when I did have all of the files still in the repo. However I ran the restore command one more time and it went back to failing, and has every time since. I just can't explain what I'm seeing.

[inosik]

Looks like this is happening all over the place:

• Compiling a F# class library fails when using Visual Studio 16.8 dotnet/fsharp#10447
• dotnet/sdk#14497

Looks like this has something to do with DOTNET_HOST_PATH being set or not.

[DanJensen]

@inosik Thanks, I just tried that. Unfortunately it had no effect. Still getting the errors.

[forki]

What about Paket alpha channel? Does this work?

[DanJensen]

@forki I found the problem, and it was my fault. When I run the dotnet commands directly, they work at first. But if I run our build script, one of the things it was doing was: dotnet paket clear-cache. Since we switched to using paket as a dotnet tool recently, that was actually the cause of the problem because it would essentially delete itself. Or at least all of its supporting files. And after that it wouldn't work right. I can change my script to not do that anymore.

One question though: since using paket as a dotnet tool is the recommended approach now, is there a way to use the clear-cache option anymore? Or is that basically deprecated now?

Thanks for your help!

[DanJensen]

It was caused by something I was doing, not paket.