visual studio 2019 packages.config

Question

I am using VS 2019 CE v 16.64 with Net Framework 4.8.03761
I have two projects TestSql and Notebook TestSql was built first and the only package installed was System Data SQLite Core
After a few updates to VS 2019 I built Notebook I only installed System Data SQLite Core and WeCantSpell.Hunspell

When I look at the folder packages.config for Notebook I see the following packages installed and wanting Updates
System Buffers
System Memory
System Numeric Vectors
System Runtime CompileServices Unsafe
Well if I did not install them just Uninstall them That is not working?

The other issue is "If it ain't broke don't fix it" the TestSql project had the packages.config folder at the bottom in Solution Explore I did a Migrate from packages.config to PackageReference
When I saw the phrase Benefits of using PackageReference I should have known this was perhaps a bad idea
Link to Benefits

So the questions are two
How do I get my packages.config folder back where it was? (See Screen Shots)
OR has my OCD clouded my sense of reality that Package References is really better design?
How do I Uninstall the packages I did not install? YES I tried with Manage NuGet Packages

Answer 1

How do I get my packages.config folder back where it was?

If you do not absolutely need packages.config, then do not go back. The PackageReference format offers lots of benefits that you do not want to miss in the long run, your link does not lie. It even solves your next problem.

How do I Uninstall the packages I did not install?

You simply don't, because it will break your library. A NuGet package represents a module or set of features consisting of artifacts like assemblies, content files or build scripts. Such a module may have dependencies that it requires to work, for example an SQLite library. Instead of creating one giant archive that contains all assemblies and files that are required, packages specify dependencies to other packages. This way, you can flexibly consolidate and update packages, especially if there are common dependencies of multiple packages, which also prevents having multiple copies of the same assemblies or files in different versions, which can become problematic.

Let's look at the dependencies of the packages that you are using.

• System.Data.SQLite.Core
  • No dependencies
• WeCantSpell.Hunspell
  • System.Memory for .NET Framework >= 4.5

[...] the only package installed was System Data SQLite Core

This package does not have any dependencies, that is why there were not additional packages.

[...] I only installed System Data SQLite Core and WeCantSpell.Hunspell

If you look at the list above, the Hunspell package requires System.Memory, that explains why it is installed, too. Hunspell will not work without it, it depends on it. I hear you ask, where do the other packages come from then? Each package can have dependencies. Consequently a package can depend on a package that depends on other packages that... I think you get the idea. So let's take another look at dependencies for .NET Framework >= 4.6.1.

• System.Memory
  • System.Buffers
  • System.Numerics.Vectors
  • System.Runtime.CompilerServices.Unsafe

I think that these are all the dependencies that you were looking for. All these packages will be added to your packages.config and this is one good reason to migrate to PackageReference, because it handles transitive package references way better. Suppose you add one package A with a dependency to package B and that has a dependency to package C. Then A has a dependency to C. This is called a transitive dependency.

The older packages.config will add all packages, while PackageReferece will only add A and is smart enough include the other packages, without explicitly adding them. In your example, the project file would only contain the references below.

<PackageReference Include="System.Data.SQLite.Core">
   <Version>1.0.113.1</Version>
</PackageReference>
<PackageReference Include="WeCantSpell.Hunspell">
   <Version>3.0.1</Version>
</PackageReference>