NuGet is the Microsoft-supported code sharing mechanism that defines how packages for .NET are created, hosted, and consumed. Developers with code to share create packages and publish them to a public or private host. Package consumers obtain those packages from suitable hosts, add them to their projects, and then call a package's functionality in their project code. NuGet itself then handles all of the intermediate details.
Technically speaking, a NuGet package is a single ZIP file with the .nupkg extension that contains compiled code (DLLs), other files related to that code, and a descriptive manifest that includes information like the package's version number. To easily examine any package's contents, change the extension to .zip and expand its contents as usual.
NuGet itself maintains the central repository of over 100,000 unique packages at nuget.org. These packages are employed by millions of .NET/.NET Core developers every day. NuGet also enables you to host packages privately in the cloud (such as on Azure DevOps), on a private network, or even on just your local file system.
Because NuGet supports private hosts alongside the public nuget.org host, you can use NuGet packages to share code that's exclusive to an organization or a work group. You can also use NuGet packages as a convenient way to factor your own code for use in nothing but your own projects. In short, a NuGet package is a shareable unit of code, but does not require nor imply any particular means of sharing.
Whatever its nature, a host serves as the point of connection between package creators and package consumers. Creators build useful NuGet packages and publish them to a host. Consumers then search for useful and compatible packages on accessible hosts, downloading and including those packages in their projects. Once installed in a project, the packages' APIs are available to the rest of the project code.
Creating a NuGet package from a .NET Framework Class Library involves creating the DLL in Visual Studio on Windows, then using the nuget.exe command line tool to create and publish the package.
Install the nuget.exe CLI by downloading it from nuget.org, saving that .exe file to a suitable folder, and adding that folder to your PATH environment variable.
You can use an existing .NET Framework Class Library project for the code you want to package, or create a simple one as follows.
In Visual Studio, choose File > New > Project, select the Visual C# node, select the "Class Library (.NET Framework)" template, name the project AppLogger, and click OK.
A NuGet package contains a manifest (a .nuspec file), that contains relevant metadata such as the package identifier, version number, description, and more. Some of these can be drawn from the project properties directly, which avoids having to separately update them in both the project and the manifest. This section describes where to set the applicable properties.
1. Select the Project > Properties menu command, then select the Application tab.
2. In the Assembly name field, give your package a unique identifier.
3. Select the Assembly Information... button, which brings up a dialog box in which you can enter other properties that carry into the manifest. The most commonly used fields are Title, Description, Company, Copyright, and Assembly version. These properties ultimately appear with your package on a host like nuget.org, so make sure they're fully descriptive.
4. Optional: to see and edit the properties directly, open the Properties/AssemblyInfo.cs file in the project.
5. When the properties are set, set the project configuration to Release and rebuild the project to generate the updated DLL.
With a DLL in hand and project properties set, you now use the nuget spec command to generate an initial .nuspec file from the project. This step includes the relevant replacement tokens to draw information from the project file.
You run nuget spec only once to generate the initial manifest. When updating the package, you either change values in your project or edit the manifest directly.
1. Open a command prompt and navigate to the project folder containing AppLogger.csproj file.
2. Run the following command: nuget spec AppLogger.csproj. By specifying a project, NuGet creates a manifest that matches the name of the project, in this case AppLogger.nuspec. It also include replacement tokens in the manifest.
nuget spec AppLogger.csproj
3. Open AppLogger.nuspec in a text editor to examine its contents, which should appear as follows:
<releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
1. NuGet produces an error if you try to create a package with default values in your .nuspec file, so you must edit the following fields before proceeding. See .nuspec file reference - optional metadata elements for a description of how these are used.
2. For packages built for public consumption, pay special attention to the Tags property, as tags help others find your package on sources like nuget.org and understand what it does.
3. You can also add any other elements to the manifest at this time, as described on .nuspec file reference.
4. Save the file before proceeding.
1. From a command prompt in the folder containing your .nuspec file, run the command nuget pack -Properties Configuration=Release
nuget pack -Properties Configuration=Release
2. NuGet generates a .nupkg file in the form of identifier-version.nupkg, which you'll find in the current folder.
Most general-purpose packages contain one or more assemblies that other developers can use in their own projects.
In general, it's best to have one assembly per NuGet package, provided that each assembly is independently useful. For example, if you have a Utilities.dll that depends on Parser.dll, and Parser.dll is useful on its own, then create one package for each. Doing so allows developers to use Parser.dll independently of Utilities.dll.
If your library is composed of multiple assemblies that aren't independently useful, then it's fine to combine them into one package. Using the previous example, if Parser.dll contains code that's used only by Utilities.dll, then it's fine to keep Parser.dll in the same package.
Similarly, if Utilities.dll depends on Utilities.resources.dll, where again the latter is not useful on its own, then put both in the same package.
Resources are, in fact, a special case. When a package is installed into a project, NuGet automatically adds assembly references to the package's DLLs, excluding those that are named .resources.dll because they are assumed to be localized satellite assemblies (see Creating localized packages). For this reason, avoid using .resources.dll for files that otherwise contain essential package code.
© 2021 Digcode.com