>> Hi friends. Welcome back to The NuGet 101 Series.
I'm Chris, and today we're going to learn how to create
a NuGet Package with the.NET CLI and then upload it to NuGet.org.
To follow along, you will need the.NET SDK installed.
To install the latest version,
check out the links in the description.
Otherwise, let's get started.
So you might recall from the What
is NuGet video that packages can generally be
thought of as compiled libraries packed
together with some 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 to put into our NuGet package.
To do that, I'm going to fire up VS Code and make sure
that we're starting in an empty folder
that you want named after your project.
So I'm naming mine AppLogger.
Then we're going to start a new terminal,
so that I can actually use the.NET CLI commands.
The first thing we're going to do is generate
a new class library using.NET.
So you can do that by executing the dotnet new classlib command.
It's going to generate a couple files for us.
So you'll see that it's generated a.cs file.
That's a C# file that's going to house
our library code and then a.csproj file.
It's going to have all of our project metadata,
but we'll get to that in just a little bit.
So let's go back to our code.
You'll see we have an empty template for
a class library and I'm going to
paste in a really simple class that I've already built.
It's a single logger class with a single log method.
All that log method is going to do is print
whatever text you pass to it to the console.
You could say it logs texts to the console.
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 modify our package metadata,
I'm going to head over to the.csproj file,
and now I'm going to paste in
some metadata I've already written out so that I
can walk you through the key elements and explain how to do them.
So let's start with the package ID.
The most important part about
the package ID is that it has to be unique
so that it doesn't conflict with existing packages on NuGet.org.
So a popular convention is something like Company.Product.Feature.
In this case I've gone with Contoso.Utilities.AppLogger.
But you don't have to follow
that convention as long as your ID is unique.
Now, the Author field is typically meant for
the publishing entity of the package.
So if you're an individual publishing this as an individual,
then you can use your own name.
But since I'm working for a company,
I'm using the classic Microsoft example, Contoso.
I'll put it in Contoso for both the Author and Company field.
Now for description.
It's incredibly useful to include
a description with your package because it's one of
the most prominent fields that'll be displayed
whenever someone is looking for your package on NuGet.org.
It's likely going to be the first thing they look at
to figure out what your package is or what it does.
We also want to keep it short and sweet.
So I've gone with library to log text to console.
The next field I want to talk about is the License.
It is incredibly important
that you specify a license in your package.
Otherwise, almost nobody will be able to use it because it will be
unclear if there are any restrictions associated with its use.
In this case, I've gone with the MIT License because it's
a very permissive license that I know just
about anybody will be able to use in their project.
Now for PackageTags.
This can significantly help with
the discoverability of your package.
You want to make sure you include any terms that you think
someone might search for to find your package.
In this case, I've gone with logging, logger, and log.
Now, for any serious project,
I would likely have a repository setup to
house my source code and documentation.
If you have that,
it's very useful to include a link to that URL so that people can
go there to learn more about
your library or even learn how to use it.
So I've pasted it in an example of what that might
look like. All right.
So now that we've finished the first component of our package,
built the simple library and the second component
and filled in the metadata using strong metadata practices,
we're ready to generate a NuGet package.
To do that, let's go back to our terminal and execute dotnet pack.
Make sure you save the file first.
All right. You can see in the output,
that we've successfully generated a NuGet package.
It's That file ending with the.nupkg extension.
So now that we've generated a NuGet package,
we're ready to publish.
So there's a couple of ways that we can do that.
But in my opinion, the easiest and fastest way is
to copy the full path to our NuGet package.
Head over to NuGet.org.
Make sure you're signed in and then head over to "Upload".
Hit "Browse" and now we're going to
paste in that full path in the filename box and hit open.
It'll find your package instantly.
Then the next step is to make sure that you verify all of
the metadata presented here because once you upload a package,
you cannot delete it or edit it.
So so far all the information looks good to me.
I'm going to go ahead and submit my package.
Awesome. As soon as I submit the package,
it's going to have to undergo some validation and
indexing before you can find it on NuGet.org,
but within a few minutes to an hour,
you or anybody else will be able to find
your package and then use it in their own projects.
So that was just a brief overview on how you can create
a NuGet package using the.NET CLI
and then publish it to NuGet.org to become
an official Published Package Author.
That concludes our NuGet 101 Series.
If you enjoyed it, I highly recommend you check out
related series available online for C#,
ASP.NET Core, ML.NET, and plenty of other amazing products.
Thank you so much for watching and I'll see you next time.