One of the most frustrating changes made in .Net Core is the NuGet package manager. I like the way the new package manager works, unfortunately, there are still a lot of bugs in the way the package manager works. I call it the tyranny of intelligent software. The software is supposed to do all the intelligent work for you, leaving you to do your work as a developer and create your product. Unfortunately, one or more bugs cause errors to occur and then you have to out-think the smart software and try and figure out what it was supposed to do. When smart software works, it’s magical. When it doesn’t work, life as a developer can be miserable.
I’m going to show you how the NuGet manager works in .Net Core and I’ll show you some tricks you’ll need to get around problems that might arise. I’m currently using Visual Stdio 2015 Community.
The Project.json File
One of the great things about .Net Core is the new project.json file. You can literally type or paste in the name of the NuGet package you want to include in your project and it will synchronize all the dlls that are needed for that package. If look real close, you’ll see a triangle next to the file. There is another file that is automatically maintained by the package manager called the project.lock.json file. This file is excluded from TFS check-in because it can be automatically re-generated from the project.json file. You can open the file up and observe the thousands of lines of json data that is stuffed into this file. Sometimes this file contains old versions of dlls, especially if you created your project months ago and now you want to update your NuGet packages. If your dependencies section in your project.json file are all flagged as errors, there could be a conflict in the lock file. You can hold your cursor over any NuGet package and see what the error is, but sometimes that is not very helpful.
To fix this issue, you can regenerate the lock file. Just delete the file from the solution explorer. Visual studio should automatically restore the file. If not, then open up your package manager console window. It should be at the bottom of visual studio, or you can go to “Tools -> NuGet Package Manager -> Package Manager Console”. Type “dotnet restore” in the console window and wait for it to complete.
The NuGet Local Cache
When the package manager brings in packages from the Internet, it keeps a copy of each package in a cache. This is the first place where the package manager will look for a package. If you use the same package in another project, you’ll notice that it doesn’t take as much time to install it as it did the first time. The directory is under your user directory. Go to c:\Users, then find the directory with your user name (the name you’re currently logged in as, or the user name that was setup for your computer when you installed your OS). Then you’ll see a folder named “.nuget” Open that folder and drill down into “packages”. You should see about a billion folders with packages that you’ve installed since you started using .Net Core. You can select all of these and delete them. Then you can go back to your solution and restore packages. It’ll take longer than normal to restore all your packages because they must be read from the Internet first.
An easier method to clearing this cache is to go to the package manager console and type in:
nuget locals all -clear
If you have your .nuget/packages folder open, you’ll see all the sub directories disappear.
If the nuget command does not work in Visual Studio, you’ll have to download the NuGet.exe file from here. Get the recommended latest. Then search for your nuget execution directory. For VS2015 it is:
C:\Program Files (x86)\NuGet\Visual Studio 2015
Drop the EXE file in that directory (There is probably already a vsix file in there). Then make sure that your system path contains the directory. I use Rapid Environment Editor to edit my path, you can download and install that application from here. Once you have added to your PATH, then exit Visual Studio and start it back up again. Now your “nuget” command should work in the package manager console command line.
NuGet Package Sources
If you look at the package console window you’ll see a drop-down that normally shows “nuget.org”. There is a gear icon next to the drop-down. Click it and you’ll see the “Package Sources” window. This window has the list of locations where NuGet packages will be searched for. You can add your own local packages if you would like, and then add a directory to this list. You can also update the list with urls that are shown at the NuGet site. Go to www.nuget.org and look for the “NuGet Feed Locations” header. Below that is a list of urls that you can put into the package sources window. As of this blog post, there are two URLs:
Sometimes you’ll get an error when the package manager attempts to update your packages. If this occurs, it could be due to a broken url to a package site. There is little you can do about the NuGet site. If it’s down, you’re out. Fortunately, that’s a rare event. For local package feeds, you can temporarily turn them off (assuming your project doesn’t use any packages from your local site). To turn off one feed, you can go to the “Package Sources” window and just uncheck the check box. Just selecting one package feed from the drop-down does not prevent the package manager from checking and failing from a bad local feed.
Restart Visual Studio
One other trick that I’ve learned, is to restart Visual Studio. Sometimes the package manager just isn’t behaving itself. It can’t seem to find any packages and your project has about 8,000 errors consisting of missing dependencies. In this instance, I’ll clear the local cache and then close Visual Studio. Then re-open Visual Studio with my solution and perform a package restore.
Package Dependency Errors
Sometimes there are two or more versions of the same package in your solution. This can cause dependency errors that are tough to find. You’ll get a dependency error in one project that has a package version that is newer than the same package in another project that your current project is dependent on.
To find these problems, you can right click on the solution and select “Manage NuGet Packages for Solution…” then click on each package name and look at the check boxes on the right. If you see two different versions, update all projects to the same version:
Finally
I hope these hints save you a lot of time and effort when dealing with packages. The problems that I’ve listed here have appeared in my projects many times. I’m confident you’ll run into them as well. Be sure and hit the like button if you found this article to be helpful.