This workshop will be retired on May 1, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed Package Management with NuGet!
You have completed Package Management with NuGet!
Preview
There are a few options to consider when installing packages and their dependencies.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
We now have all the dependencies our
JsonToDb program needs to do its job.
0:00
Now we need to do is use these libraries
in our code and write the program.
0:05
Because this workshop is about
package management with NuGet,
0:09
we'll leave that task for another day.
0:12
To play with some more features of NuGet,
let's create a whole new project.
0:14
This time we'll create a project for
an ASP.NET MVC application.
0:18
So we'll click File > New > Project.
0:23
Under Web, click ASP.Net Web Application.
0:27
For this demo, just leave the project
name and location the same, and click OK.
0:31
We'll create an MVC web application and
uncheck this box to host in the cloud.
0:38
Pay attention to what
happens when I click OK here.
0:43
Because this is the first time I've
created an ASP.NET MVC application on this
0:47
computer, it will take a bit longer
than usual to create this project.
0:51
The reason for this is because most
of the libraries that are needed to
0:56
create an MVC application
are downloaded from NuGet.
0:59
when we look at our project,
1:03
we can see that there's already
a packages.config file.
1:04
If we open the file, we can see a list
of all the NuGet packages that our
1:08
project needs, and we have a lot of
assemblies listed under References.
1:12
These were all installed from NuGet
when the project was created.
1:17
Let's add another package to our project.
1:22
ELMAH is a popular way to add
error logging to a website.
1:25
It makes it much easier to
troubleshoot errors that happen
1:29
in ASP.NET applications.
1:31
Since we only have a single project
in our solution, just right-click
1:34
on the project name to manage
the NuGet packages for this project.
1:37
In the search bar under Browse,
we'll type elmah.
1:41
Since we're creating an ASP.NET MVC
application, we'll select Elmah.MVC.
1:46
Look over here in the details.
1:53
Notice that this package has a dependency
on the ELMAH core library package.
1:54
Nuget packages can have dependencies
on other Nuget packages.
2:00
By installing Elmah.MVC, it will install
elmah.corelibrary for us automatically.
2:03
So NuGet not only manages
the dependencies of our project, but
2:10
also the dependencies of those
dependencies, and so forth.
2:14
Here it says that Elmah.MVC will work with
2:17
version 1.2.0 or
greater of elmah.corelibrary.
2:22
Let's go back up here and
expand the Options area.
2:26
These options don't only apply to
the Elmah.MVC package we've selected.
2:30
Changing these options
will change them for
2:35
all future packages we want to install.
2:37
But we can change these options each
time we want to install, update, or
2:40
uninstall a package.
2:44
Just be aware that they will
remain set that way for
2:45
the next package you want to install
unless you change them again.
2:48
Here we have a few options for
how to deal with dependencies.
2:52
Inside the Dependency behavior drop-down
we see an option for Ignore Dependencies.
2:55
If this is selected,
3:01
then none of the dependencies of our
packages will be installed automatically.
3:03
These other options allow us to control
which version of the dependencies
3:06
should be used.
3:10
NuGet assumes that all
packages are versioned using
3:11
the Semantic Versioning schema.
3:14
Semantic Versioning refers to
three numbers separated by dots.
3:16
It's pretty straightforward.
3:20
The three numbers correspond to the major,
minor, and patch version numbers.
3:21
[SOUND] When versioning the library, we
should increment the major version number
3:25
when we make breaking changes to the API,
meaning code that worked with the previous
3:30
version might need to be changed in order
for it to work with the new version.
3:34
We should increment the minor version
when we add new features to the library
3:39
that won't break any code
that uses the library.
3:42
And we should increment the patch
version when releasing a version that
3:46
only contains bug fixes.
3:49
Finally we can identify prerelease
versions of the library
3:51
by appending -alpha, -beta and so
on to the end of the version number.
3:55
When searching for NuGet libraries, we can
see packages that are only in prerelease
4:01
by checking this check box here.
4:05
This is handy when we want to experiment
with future versions of a library.
4:07
With Semantic Versioning in mind, the rest
of these options start to make sense.
4:11
Lowest refers to the lowest
version that can be used.
4:17
In the case of elmah.corelibrary,
this is 1.2.0 because that's
4:20
the lowest version that
Elmah.MVC says it can work with.
4:25
Highest Patch refers to the lowest minor
version, but highest patch version.
4:32
In the case of elmah.corelibrary,
the lowest minor version is 1.2.
4:37
But it should get the highest
patch of 1.2 available.
4:42
Highest Minor would get
the highest minor and
4:46
patch version for elmar.corelibrary
that has a major version of 1.
4:48
Highest gets the latest and greatest
non-prerelease version of the library.
4:53
By default, NuGet comes preconfigured
to always install the lowest version of
4:57
the dependency.
5:01
However it's usually best to use
the latest version of the library possible
5:03
because it probably contains
the fewest bugs and
5:07
we can use it longer without it
becoming too far out of date.
5:10
You might think that NuGet should always
install the highest version that's
5:13
guaranteed to work with
the library that depends on it.
5:16
In that case, we would always
want the highest minor version.
5:19
The reason NuGet doesn't select this
by default is because not all libraries
5:23
are versioned using Semantic Versioning.
5:27
They may use their own versioning system
where a minor version may contain breaking
5:30
changes.
5:34
elmah.corelibrary uses
Semantic Versioning, so
5:34
I'm going to pick Highest Minor.
5:37
This means we'll get a later version
of elmah.corelibrary then we would have
5:40
had we left this at Lowest.
5:45
I mentioned earlier that NuGet packages
have the ability to add files to a project
5:48
other than just libraries.
5:52
The File conflict action option here
tells NuGet what to do if the file it's
5:54
trying to add already
exists in the project.
5:58
We can also tell NuGet what to do when
a package is uninstalled from a project.
6:01
By checking this box, we tell NuGet
to uninstall any dependencies
6:06
that were installed with the package
when this package is uninstalled.
6:09
The second checkbox, Force uninstall,
6:13
has to do with uninstalling packages
that are dependencies of other packages.
6:16
By checking this box, NuGet can uninstall
a package even if there is another package
6:21
in the project that depends on it.
6:26
In most cases we want to keep
Remove dependencies checked and
6:28
Force uninstall unchecked.
6:33
Let's click the Install
button to install Elmah.MVC.
6:36
Now this preview makes even more sense.
6:42
We can review here the versions of
the packages that will get installed.
6:45
We can see here that instead of installing
version 1.2.0 of elmah.corelibrary,
6:49
we're getting 1.2.2 instead because we
chose to install the highest minor and
6:55
patch versions available.
7:00
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up