Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
CollectPackageReferences in .NET Core 2.0.2 results in Paket failing to restore the dotnet-fable tool in fable-suave-scaffold #2784
From @rrelyea in our internal investigation thread:
For the 15.4 timeframe, we’ve added that support.
In .NET Core 2.0.0 – Paket downloaded many nupkgs and put them in the user package folder. However, they just put the .nupkg there, they didn’t extract it. It still worked because NuGet redownloaded all the packages and cleaned up their non-extracted install.
In .NET Core 2.0.2 – NuGet now is respecting CollectPackageReferences, which enables Paket to clear NuGet sources via the nuget.config that they pass us. This means we cannot go download things the 2nd time to make it all work.
This looks like the correct behavior from NuGet.
Paket is trying to prevent NuGet from downloading twice, despite the fact that they downloaded them improperly the first time.
On Windows (I haven't tested this on macOS or Linux)
Failure (paths are from a test VM, but this will repro on a local machine).
This will impact fable-suave-scaffold on .NET Core moving forward. The first time people could encounter this en-masse will be when VS 2017 15.4 releases.
Use 2.0.0 first, then switch back to 2.0.2.
changed the title from
Change in NuGet to respect CollectPackageReferences in .NET Core 2.0.2 breaks Paket's usage in fable-suave-scaffold
CollectPackageReferences in .NET Core 2.0.2 results in Paket failing to restore the dotnet-fable tool in fable-suave-scaffold
Sep 21, 2017
Do you have a suggestion on what the error message should be here?
In this scenario NuGet restore finds a corrupted install, zero sources, and has no idea that another tool has modified all of these things are not the user. The current NU1100 message is shown when a package cannot be found and no sources exist, otherwise the sources would be listed along with the versions that were found.
I wouldn't say it is trying to hide the state. For NuGet restore the package is downloaded to the http cache, validated there, and retries occur as needed. If there are issues warnings or errors are displayed and the global packages folder remains untouched.
Once the package is completely downloaded and validated it is then extracted to the global packages folder and files are moved into place while the package is locked to avoid conflicts. If there is a corrupt install it will be fixed at this point by replacing it.
A warning about finding a previous corrupted install could be useful, however under normal circumstances this isn't something that the user needs to act on. Restore fixes the problem. In this case the primary problem is that the package cannot be found to install, and the user is shown that message.