>> Hey friends, and welcome back to the NuGet 101 series.
I'm Chris, and today we're going to learn how to
create a NuGet package with Visual Studio,
and then publish it to NuGet.org.
To follow along, you will need Visual Studio installed with
a.NET Core workload to get the latest version of Visual Studio,
check out the links in the description.
Otherwise, let's get started.
So you may recall from what is
NuGet video that packages can generally be
considered compiled libraries packed together with
descriptive metadata into a nice shareable unit.
So to start off this tutorial,
we're going to focus on the first component and
build a simple library from scratch.
To do that, let's fire up Visual Studio,
we're going to go to "Create a new project",
and then search for ".net core class library",
that's a kind of library we're building.
Make sure that you get the C# version,
and then hit "Next".
We're going to name our project "AppLogger",
and you'll see why in just a minute, and then hit "Enter".
Now Visual Studio is going to generate
an empty template of a class library for us.
Now I'm going to paste in
a really simple class I've already built.
All it is is a logger class with a single log method.
All that log method's going to do is print to
the console whatever text is passed to it.
It's not the most sophisticated library in the world,
but for this tutorial,
it'll get the job done.
So now that we've completed
the first component of
our NuGet package and we've built the simple library,
it's time for us to switch our focus to the second component.
That's right, the descriptive metadata.
Now the metadata is really going to define our package.
So to access the project metadata,
let's go to "Project",
and then "AppLogger properties",
and will go straight to
the "Package" tab since that's what we're interested in,
and this is the package metadata.
You'll see that there's already a few
default values filled in for us,
but we can do a little better than that.
So I'm going to walk through some of
the most important metadata elements
so that we can practice filling them in.
So let's start with the package ID.
The package ID has to be unique,
otherwise it may conflict with existing packages on NuGet.org.
A really common convention
is something like company.product.feature,
so I'll go with Contoso.Util.AppLogger,
but you don't have to follow
that convention as long as it's unique.
Now for version.
So this is indeed the first version of our app logger library.
So we'll stick with 1.0.0.,
but you can learn more about
versioning strategies in the NuGet documentation.
Now the "Author" field is typically meant
for the publishing entity of the package.
So that could be your name
if you're an individual publishing this,
or it could be your company if you're doing it for a company.
So I'll put in Contoso,
and we can keep the company field the exact same.
Now "Product" is meant for the pretty name of our package.
So in this case, that's "AppLogger" for us,
something a little more recognizable
or memorable than the full package ID.
So "Description" is a very useful field
to have because it's one of
the most prominent fields that'll be displayed
whenever someone is searching for your package.
It's probably the first thing anyone will look at to
figure out what your package is, and what it does.
So while we want to be descriptive,
we also want to keep it short and sweet.
So I'll go with something like "Library to log text to console".
The next field I want to talk about is "Licensing".
Now, it's incredibly important that
you specify a license for your package,
otherwise almost nobody will be able to use it,
because it's unclear if there's
any restrictions associated with its use.
For this project, I'm going to put it in
an MIT license which is a very permissive,
very common license that just about anybody can use.
Now, for any serious project,
I would likely have a repository setup,
one that's hosting my source code and documentation.
If you have that, it's very useful to include a link to that,
and I'll paste in something to show you what that looks like,
so that people can go to that link to learn
more about your package and learn how to use it.
Now, the last field I want to talk about is "Tags".
Tags can significantly help
with the discoverability of your package.
You want to make sure you include any terms that
someone might be searching for to find it.
So in this case I'm going to put in a "Logging,
Logger, Logs, Text," and that should be sufficient.
So these are just the most important metadata fields in my view,
but there are other really nice ones to have.
If you can, you always want to include an icon to
help visually differentiate your package,
it's also very nice to include
release notes whenever you are creating
updates of your package so people can
tell what's new, what's changed.
With that, we've officially
completed both the first component of our package,
the simple library and
the second component; the descriptive metadata.
So now it looks like we're ready to generate the package.
There's a couple ways we can do that.
If you want to do it automatically
without having to worry about it,
we can select "Generate NuGet package on build".
What that means is that every time we build our project,
it's going to generate a new NuGet package.
Or if we wanted to do it manually,
we can go to "Build" up-top,
and then go to "Pack AppLogger" which,
since I just need to do this once,
that's what I'm going to go ahead and do.
Awesome. So you can see in the "Output"
that we've officially generated a NuGet package.
It's the file that ends with the.nupkg extension.
So we've created our package,
we're ready for the next phase of publishing.
There's a couple of ways we can do that too,
but I think the easiest and fastest way is to go
ahead and copy this full path to our package.
Make sure that we're not including the little enquotes at the end,
and then we're going to NuGet.org,
makes sure that you're logged in,
and head to "Upload", and go to "Browse".
Now, we could look around to try to find our package,
or because we were smart and we copied the full path to it,
we are can paste that right into
the little "File name" box and click "Open",
and it'll find it instantly.
Now, before we complete the upload,
we want to verify all of this information
because once you upload a package to NuGet.org,
you cannot delete it or edit it.
So everything looks good to me,
I'm going to go ahead and submit the package.
So I'm going to click "Submit".
So now that we've submitted the package,
it has to undergo a little bit of validation and
indexing before you'll be able to find it on NuGet.org,
but within a few minutes to an hour you or anybody else will
be able to download your package and use it in their projects.
So to recap, we learned how to create a very simple class library,
how to fill out our descriptive metadata
using strong metadata practices,
how to pack the two together and generate a NuGet package,
and then ultimately how to upload that to NuGet.org
to become official published package authors.
So in the next video,
we're going to learn how to create
a NuGet package using the.NET CLI,
and then publish that again to NuGet.org.
So thank you so much for watching,
and I'll see you next time.