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