2

In line with the rules, I have to ask a new question, to get some clarification on another question/answer.

This answer is this one: https://stackoverflow.com/a/45964469/305916

Then what? Just did the accepted answer, but the packages.config file is not populated with the packages (I know it doesn't say so).

I am missing what to do next if the packages appear automatically in the packages.config or I need to install them again...

I am leaning towards the latter, but I feel the answer is not complete :)

But what to do?

Dennis
  • 63
  • 1
  • 10
  • 1
    The original answer mentions creating an empty packages.config file, but as you mention, does not indicate what to do next. One option would be to install them again. Another option would be to edit the packages.config file and add the package information into the packages.config file. However PackageReferences do not include all dependencies in the project file where as packages.config files do. So you would need to reinstall them using 'Update-Package -reinstall' to ensure the missing packages are added. – Matt Ward Nov 16 '18 at 19:02

2 Answers2

5

Firstly, do you mind editing your question, or posting as a comment, why you want to revert back to packages.config? As a member of the NuGet team, it's useful to know the reasons why PackageReference doesn't work for you. If it's not one of the reasons listed in as a limitations of PackagesConfig, including the package compatibility section, perhaps we can help resolve that issue so you can keep using PackageReference.

If you really want to revert to packages.config, I suggest the following, not the answer that you linked.

  1. Go to Options, NuGet PackageManager->General and enable Allow format selection on first package install
  2. Uninstall all packages in your project using "Manage NuGet Packages" (Package Manager UI). You can use Package Manager Console to uninstall, but you must use Package Manager UI for the next step. Keep track of which packages you uninstall, so you know which to install again in the next step.
  3. Once your project has no package references, then install the packages you need again. The first package you install will pop up a dialog where you choose to use packages.config or PackageReference. If you didn't keep track of which packages you uninstalled in the previous step, use your source control system to diff your project file, or look at an unmodified copy, and look for all instances of PackageReference.

It's necessary to uninstall all packages in the project installing a new one, because if any PackageReference exists in the project file, NuGet will add new packages as PackageReference. Therefore you can't uninstall the first package, re-install it, then move the second package in the project.

zivkan
  • 12,793
  • 2
  • 34
  • 51
  • 3
    We found that using package reference our builds did not package (nuget pack) the dependencies correctly. So we reverted. Your process is what we ended up doing. Clearing out the obj folder from time to time, to get the reference list in VS to show up correct. – Dennis Nov 19 '18 at 08:31
  • I talked to my team this morning and was told that the dotnet cli pulls in its own targets, even when run against an "old-style" csproj (not a SDK project). If you have .NET Core (which includes the dotnet cli) installed, you could try `dotnet pack myproj.csproj` to pack PackageReference projcts and get nuget dependencies automatically. I don't have time to test it myself yet though. If you can migrate your projects to SDK projects, then there will certainly be no problem, as that's a scenario it's designed for. – zivkan Nov 19 '18 at 19:12
  • Unfortunately, not all functionality exists in SDK projects that exists in non-SDK projects (GUI applications are the biggest offenders but even some libraries have problems). Due to [a bug in NuGet](https://github.com/NuGet/Home/issues/5979), PackageReference in non-SDK projects is basically broken, so the only option we have is to migrate back to packages.config. – qid Feb 20 '19 at 17:23
  • @qid the bug you linked is just that nuget.exe can't pack ProjectReference and you need to use `msbuild -t:pack` instead (and import NuGet.Build.Tasks.Pack if necessary, like when not using an SDK project). Considering there are far more projects that never get packed compared to projects that do get packed, while I acknowledge that you and other customers are experiencing issues, it feels unfair to say the entire feature is "basically broken". There are scenarios where it works just fine. – zivkan Feb 28 '19 at 19:16
  • @zivkan I have tried that approach, and MSBuild fails saying that a "pack" target could not be found. I added a comment regarding this to the linked github issue. I agree this problem does not affect all scenarios, but in the scenarios it does affect, there is as of yet no solution available. – qid Mar 04 '19 at 01:12
  • On VS 2019 (v16.3.2) I had to restart Visual Studio after step 1 for it to recognize the change and prompt me for the format selection when installing the first package. – deadlydog Oct 09 '19 at 02:22
  • Hey @zivkan, an example of where the `PackageReference` format doesn't work is when using `outdir` with MSBuild. With `outdir` all assemblies from all projects end up in the same directory. If Project A references v2 of NuGet Package X, and Project B references NuGet Package Y which has a dependency on v1 of NuGet Package X, then I may end up with v1 of NuGet Package X copied to my output directory. Since 2nd-hand dependencies are omitted in the `PackageReference` format, I cannot specify that Project B should use v2 of Package X like I can with `packages.config`. An edge case that we have :( – deadlydog Oct 09 '19 at 05:54
  • @deadlydog pack doesn't use the output directory to determine dependencies, so it sounds unrelated to whatever issue you're having. `nuget pack` doesn't support PackageReference, you need to use `msbuild -t:pack`, which may be related. I suggest creating a new question or issue if you want help with your scenario. – zivkan Oct 10 '19 at 13:33
  • @zivkan using `nuget pack` wasn't mentioned in the original question or your answer. Looking now I see that you guys did discuss it in the comments. I was simply responding the question you asked in your answer of, why someone might want to revert back to packages.config; It not working with `outdir` is a reason. I just wanted to make you aware of that shortcoming. I'm not going to create a new question; we've simply decided not to use `PackageReference` for slns using `outdir`. Thanks. – deadlydog Oct 11 '19 at 15:12
  • And I was trying to let you know that with the information you provided, I don't understand why PackageReference doesn't work for you. To better understand, I need more details, possibly a sample reproduction, and a comment on an answer to someone else's question isn't the best place for that. – zivkan Oct 11 '19 at 15:39
  • Hi there, just to add my word about why dependencies in csproj is problematic: I build my app via docker, which is FAR FASTER when it can use cache. But csproj is affected by a lot of chores, including whitespaces mess auto-generated from Visual Studio. This invalidates NuGet restore cache for.... No reason. And builds takes so long. So, having deps separated from project file reduce chances for that kind of cache miss. – Alexandre Germain Dec 23 '21 at 14:32
  • @AlexandreGermain NuGet's restore no-op/up-to-date check doesn't consider whitespace or any other MSBuild items/properties unrelated to NuGet. It asks MSBuild just for the things it cares about, takes a hash, and only when the hash is different to the contents to a file in your obj folder, NuGet does restore. So I really don't follow your comment. – zivkan Dec 23 '21 at 21:13
  • Yup, maybe NuGet does. Docker don't. So it executes the restore step every time anyway. So, yeah, it is a bit faster than running restore for the first time if you use buildkit, but it takes extra configuration from the docker environment. If you don't manually setup docker to cache the .nuget packages directory, you're good for a full reinstall for a single whitespace. – Alexandre Germain Dec 24 '21 at 07:20
0

I am missing what to do next if the packages appear automatically in the packages.config or I need to install them again...

Yes, you have to install those packages again. That because automatically migrating projects from PackageReference -> packages.config is not something that will be supported.

Check the thread:

https://github.com/NuGet/Home/issues/4973

To accomplish this, you can follow below steps:

First, change the Package Management to Packages.config, Tools->Options->NuGet Package Manager->Package Management:

enter image description here

Second, unload the project and edit it, remove all PackageReference elements out of the project file (Make sure that is not set in the project file.).

Third, reload the project, then reinstall those packages.

Hope this helps.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135