# NuGet Pro Tip: Control Where Your Packages Are Installed

As you are likely aware, there are currently two methodologies for using NuGet packages in your Visual Studio project:

1. The packages.config file - all of your packages are listed in this file, one per project, and typically the packages are installed to a "packages" folder on the root level of your solution. This also means they tend to be inside the scope of your source control, but most ignore files will filter them out for you, and they shouldn't be stored in source control unless they're local packages.
2. The PackageReferences format - all of your packages for the project are listed in the project definition file, like your content is, and typically the packages are installed to a folder in your Windows "users" directory. You'll find the references in the References or Dependencies section of your project, depending on if you're using .NET Framework or .NET Core, respectively. By default, a .NET Framework project won't let you convert to PackageReferences, but if you manually do one in your project file, the rest will fill in accordingly.

As .NET Core (soon to be .NET 5, merged with Framework and Standard) is the future, PackageReferences is becoming the typical way to see NuGet done. But I had a scenario come up recently with a T4 template that needed references to my NuGet packages...how do I reference the package location when it's in my users directory, and thus has my username on it, and still share with other developers on the project?

Enter the globalPackagesFolder setting! This allows you to determine exactly where to put your packages, such as a location common to all. I chose c:\packages to make it easy. So my NuGet.config files looks like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<clear />
</config>
<solution>
</solution>
<packageSources>
<clear />
</packageSources>
<activePackageSource>
</activePackageSource>
</configuration>


This doesn't affect anything like the Azure devops CI/CD process, everything will process fine there. This is purely for local machines. And from there, references to the packages are easy if you need a file path.

Posted on by:

### Kenneth McAndrew

Over 20 years in web development, from HTML (remember image maps and frames?) to classic ASP to ASP.NET to .NET CMSes.