When it's time to commit our project to version control,

we have to decide if we're going to commit all of the project's dependencies as well.

Before package management systems were available,

the answer to this question was consistently yes.

It's important to make sure that a project in version control builds, and

it can't build if it's missing its dependencies.

Package management systems give us the option of not always committing

all the libraries that a project needs into version control.

Let's make sure we have the directory that contains our solution open, and

then close down Visual Studio.

We'll pretend that we just cloned this solution

from a version control system like GitHub.

Typically we tell Git to ignore the project's bin and OBJ directories.

So let's go into each project and delete those.

We also ignore this .vs directory.

The packages directory contains all of the assemblies outside of the .NET

Framework that our project is dependent on.

When we're using NuGet, we don't need to commit these to version control either.

So let's delete the entire package directory.

This is how our solution would look had we just cloned it from a version

control system.

Now let's open Visual Studio by double-clicking on the solution file.

Now if we look over here under the references of these projects,

we see yellow triangles on the assemblies that we added using NuGet.

If we look in the Error List window,

we see a list of errors that our solution has.

It's complaining that all these assemblies can't be found.

Because we originally used NuGet to get these packages,

each project has a list of the NuGet packages it needs.

That's what the package.config files in each project are for.

Let's see what happens when we go to build our solution.

I'll type Control+Shift+B to build the solution.

Notice that the solution built successfully, and

also notice that the yellow triangles went away.

Because we're using NuGet to manage our dependencies for us, it automatically

fetches the packages we needed and put them back in their solution.

If we needed NuGet to install the packages before we needed to build, we could

have right-clicked on the solution and clicked Restore NuGet Packages.

And if we go back into the File Explorer,

we can see that the package directory is back, and it contains all of our packages.

I should mention that NuGet didn't have to go out to the Internet to fetch all those

packages.

NuGet maintains a cache of packages that we've previously installed to any

Visual Studio project on our machine inside of the .nuget in your Users folder

on your computer.

In my case, it's C: > Users > Jeremy > .nuget and then packages.

When installing a package, NuGet will first check this cache for

the version of the package it's looking for and use that one instead of

fetching it from the NuGet package repository on the Internet.

By the way, you can explore the NuGet package repository from a web browser

instead of Visual Studio by going to www.nuget.org.