Managing Packages for a Solution4:22 with Jeremy McLain
Visual Studio makes it easy to manage NuGet packages for multiple projects in a solution.
Let's look at the solution folder in the file explorer again. 0:00 Notice that the packages folder is inside of the solution folder 0:04 instead of the project folder. 0:08 The packages are dependencies of the Json to DB project, but 0:10 they're stored outside of the project folder. 0:14 This is because it's common for 0:17 multiple projects inside of a solution to depend on the same you get packages. 0:18 When working with Entity Framework, 0:23 it's common to have all of the code that models the database in its own assembly. 0:25 That way it can be used in other applications that also want to work with 0:30 the database. 0:33 Let's add a class library project to our solution and name it database models. 0:34 And because this project will need access to the database, 0:44 let's add a reference to Entity Framework in it as well. 0:48 We could right click on references and click Add Reference and then browse to 0:51 the Entity Framework assemblies in the packages folder, but that would be a bad 0:55 idea for many reasons It's far better to let NuGet handle this for us. 0:59 We can add Entity Framework to the database models project 1:04 the same way we did with the Jaison to DB project, and that would be perfectly fine. 1:07 But I want to show you another way that has a couple of advantages. 1:12 If we right click on the solution name of the solution's board, 1:16 we can see a menu item that says manage new packages for solution. 1:19 It opens up a tab in the main workspace that looks a lot like the new get window 1:26 we've been using, but it isn't see the other one is still open here. 1:30 This allows us to manage the new packages for 1:37 all the projects in a solution from a single window. 1:40 Let's say we wanted to add Common.Logging to both of our projects. 1:43 We can select it, and then over here, we can click on the check boxes for 1:52 both the projects and click Install. 1:56 This time the confirmation dialog shows us that we're adding these assemblies to both 2:01 projects. 2:06 Notice that down here the details of the package are still shown. 2:10 We just need to scroll down a little. 2:14 Click on Installed to see all the packages used by the solution. 2:16 Only the click on this X here to clear out the search query. 2:21 Entity Framework is already installed into the JSON onto Db project. 2:24 So if you want to have it installed into the database models project, we can select 2:28 it here and then click the check box for database models and click Install. 2:32 Now, let's say that our database models class library encapsulates everything that 2:47 we want to do with Entity Framework well enough, 2:51 that we don't need to have a dependency to it in both projects. 2:53 We can make sure that the Jaison to D.B. 2:57 project is the only project click here, and then click uninstall. 2:59 Notice that the Entity Framework configuration block 3:08 is still in app.config. 3:11 This, we have to remove manually. 3:13 It doesn't hurt anything to have it here but it's something to be aware of. 3:15 When working with the solution that has multiple projects, I encourage you to get 3:19 in the habit of managing to get packages for the entire solution. 3:22 The reason for this is because it helps to identify where projects 3:26 may be using different versions of the same library. 3:29 Having projects that are dependencies of each other 3:32 that are using different versions of the same library can be problematic. 3:35 Say, for example, we installed version 8.0.7 of 3:39 Newtonsoft.Json in Database Models, and then a newer version was released. 3:43 After the newer version was released, we added it to JSON2db. 3:50 So now, JSON2db is using the newer version. 3:55 If we manage the NuGet packages per project 3:59 we might not see this disparity right away. 4:02 The NuGet packages for solution window has an extra section called consolidate. 4:04 This tells us how many different versions of a package are being used in 4:10 the projects of a solution. 4:13 We can use this to decide which version we want to use across all the projects and 4:15 update them accordingly. 4:20
You need to sign up for Treehouse in order to download course files.Sign up