Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
With NuGet it's not necessary to commit dependencies to version control, but you can if you want.
When it's time to commit our
project to version control,
0:00
we have to decide if we're going to commit
all of the project's dependencies as well.
0:03
Before package management
systems were available,
0:07
the answer to this question
was consistently yes.
0:10
It's important to make sure that
a project in version control builds, and
0:13
it can't build if it's
missing its dependencies.
0:17
Package management systems give us
the option of not always committing
0:20
all the libraries that a project
needs into version control.
0:24
Let's make sure we have the directory
that contains our solution open, and
0:27
then close down Visual Studio.
0:31
We'll pretend that we
just cloned this solution
0:34
from a version control system like GitHub.
0:37
Typically we tell Git to ignore
the project's bin and OBJ directories.
0:39
So let's go into each project and
delete those.
0:44
We also ignore this .vs directory.
0:58
The packages directory contains all
of the assemblies outside of the .NET
1:02
Framework that our
project is dependent on.
1:06
When we're using NuGet, we don't need to
commit these to version control either.
1:09
So let's delete the entire
package directory.
1:13
This is how our solution would look
had we just cloned it from a version
1:16
control system.
1:20
Now let's open Visual Studio by
double-clicking on the solution file.
1:21
Now if we look over here under
the references of these projects,
1:33
we see yellow triangles on the assemblies
that we added using NuGet.
1:36
If we look in the Error List window,
1:40
we see a list of errors
that our solution has.
1:42
It's complaining that all these
assemblies can't be found.
1:44
Because we originally used
NuGet to get these packages,
1:49
each project has a list of
the NuGet packages it needs.
1:52
That's what the package.config
files in each project are for.
1:56
Let's see what happens when
we go to build our solution.
1:59
I'll type Control+Shift+B
to build the solution.
2:02
Notice that the solution
built successfully, and
2:06
also notice that the yellow
triangles went away.
2:08
Because we're using NuGet to manage our
dependencies for us, it automatically
2:11
fetches the packages we needed and
put them back in their solution.
2:14
If we needed NuGet to install the packages
before we needed to build, we could
2:18
have right-clicked on the solution and
clicked Restore NuGet Packages.
2:21
And if we go back into the File Explorer,
2:27
we can see that the package directory is
back, and it contains all of our packages.
2:30
I should mention that NuGet didn't have to
go out to the Internet to fetch all those
2:35
packages.
2:39
NuGet maintains a cache of packages
that we've previously installed to any
2:39
Visual Studio project on our machine
inside of the .nuget in your Users folder
2:44
on your computer.
2:48
In my case, it's C: > Users >
Jeremy > .nuget and then packages.
2:50
When installing a package,
NuGet will first check this cache for
2:57
the version of the package it's looking
for and use that one instead of
3:00
fetching it from the NuGet package
repository on the Internet.
3:04
By the way, you can explore the NuGet
package repository from a web browser
3:07
instead of Visual Studio
by going to www.nuget.org.
3:11
You need to sign up for Treehouse in order to download course files.
Sign up