Hello.
In this video, we're going to talk about Question 47, what are Nuggets packages look at is a Microsoft
supported package manager, so a tool with which developers can create, share and consume useful code.
There are tons of libraries that other developers created, which we can use in our own projects.
Look at package manager is the tool that allows us to access them.
Each package contains the yellow's built from the code that someone else developed.
For instance, let's add another unit and walk to this project, and the unit is one of the most popular
unit testing frameworks for C-sharp, and Mock is unlocking library together.
There are two essential tools that we can use to create unique tests for our code.
The easiest way to install a no-good package is by right clicking on the project.
And selecting Manage to get packages.
On this screen, we can search for the package that we want to install.
After selecting it, we can choose the version that we want.
Let's select the latest one and now we can click install.
After installing the package, we can start using it.
There is another, sometimes even more convenient way of installing nugget packages.
We can simply start using the types from the package.
No Visual Studio complains that it doesn't know this type, but we can choose to install this package
from the context menu.
And now the court compiles correctly.
Now let's take a look at how this year's profile changed after installing those two packages to see
the Sears profile of the project.
We must first unload it.
We can simply right click on the project.
And select download project.
And now we can select Edit Project File.
And here we can see the entries that have been added by Nuggets package manager.
The question is where exactly did the packages get installed?
Well, this evolved with the versions of dotNet, but in net six, which we use in this course, it
by default gets installed in your users folder.
For example, in a path like this.
Let's go to this folder and see the packages.
Here it is.
Let's take a look inside.
And here we can see the onion folder that God created when the package was installed.
Don't worry if for you, this entire folder looks different.
I have dozens of different coding projects on my computer and overall four hundred and eight get the
packages installed, thanks to the fact that the package gets installed in the user folder.
It can be reused between different projects.
I have multiple products using the unit, but this library only exists in a single copy on my machine.
And for each of my projects, it gets taken from this folder.
Let's take a look inside to see what's inside such a new package.
In here, what is most important is the leap for the.
In here, we can see the actual deals that get referenced from our project.
Now I will do something, I mean.
I will remove the entire immunity folder from this directory.
Let's go back to Visual Studio and see if the project was built correctly after all the dials it needs
have been deleted.
Well, that's a bit surprising.
The dude was successful and you think and you unit still works.
Let's take a look again into the new Get Packages directory.
It seems like the unit folder has magically reappeared.
Actually, it's no wonder, Jake.
This year's profile now clearly declares what packages it needs.
Visual Studio notes that if the package is missing from the packages folder, it must simply reinstall
it.
It's quite convenient, especially if we share the code via some kind of repository.
We only commit the code and package references to the repository, but not the packages themselves once
another programmer downloads the code and builds it.
The packages get installed on his or her machine automatically.
One more thing?
Sometimes Visual Studio messes something up, and it's not able to restore the packages.
If this happens, we can restore them manually to do it.
We must select tools.
Nugget, package manager, package manager, console, and from this console, we must run those not
restore command, which will restore all packages referenced in the solution.
All right.
We now know how to use the packages that someone else created.
I highly recommend you use this beautiful concept and not reinvent the wheel each time you need something
done in general when you think of something not specific to your project, but rather something that
could likely be used by other developers.
There is a 99 percent chance there is a new gift package that already does that.
If you have some good ideas of your own, you can always create and publish your own nugget packages.
In the document attached to this lecture, I linked a series of articles about that.
All right.
That's it in this lecture.
Thanks for watching and see you in the next video.