When using NuGet, use NuGet Oolong

When using NuGet, use NuGet Oolong
Problem description

Recently, a self-developed project planned to start using NuGet to manage dll, but encountered a strange problem, but the result proved to be a problem of oolong.

Create a WebApi project and use NuGet to manage third-party dll files. Newtonsoft. Json is referenced and the version is 5.0.6. Check that the project reference is correct.

Upload the project to GitHub. During the upload, the packages directory generated by NuGet is ignored.

Then, clone the project from GitHub to the local machine. Newtonsoft. Json references the system before the NuGet reference is restored in the compilation Project, for example.

Then, re-compile the project, restore the NuGet reference, and generate the packages directory. However, Newtonsoft. Json displays the 4.5.0 version of the referenced system, but check the generated bin directory. It is indeed the 5.0.6 version referenced by NuGet.

So the question is, why does the NuGet packages directory still reference the system?

Analysis ideas

First, check the generated output of MSBuild and find that the copy path is correct, as shown in.

Then, we can think of how to use assembly redirection and force it to use version 5.0.6. Therefore, add the following code to web. config.

After the project is regenerated, the system still references the project, for example.

At this point, I thought about all the methods I could think of, but why is the project still displaying the dll that references the system.

Then I asked my colleagues, and the colleague refreshed the project. The project was OK and the NuGet packages directory was correctly referenced.

It turns out that there is no refresh, and the project shows the old ones!

So I will summarize it here to avoid making such low-level mistakes in the future.