Using Packages with Version Control

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