NuGet

To work with NuGet, as a package consumer or creator, you can use command-line interface (CLI) tools as well as NuGet features in Visual Studio.

• dotnet.exe CLI tool for .NET Core and .NET Standard libraries, and for any SDK-style project such as one that targets .NET Framework. Included with the .NET Core SDK and provides core NuGet features on all platforms. (Starting in Visual Studio 2017, the dotnet CLI is automatically installed with any .NET Core-related workloads.) .NET Core SDK
• nuget.exe CLI tool for .NET Framework libraries and for any non-SDK-style project such as one that targets .NET Standard libraries. Provides all NuGet capabilities on Windows, provides most features on Mac and Linux when running under Mono. nuget.exe
• Visual Studio On Windows, the NuGet Package Manager is included with Visual Studio 2012 and later. Visual Studio provides the Package Manager UI and the Package Manager Console, through which you can run most NuGet operations. Visual Studio
• Visual Studio for Mac On Mac, certain NuGet capabilities are built-in directly. Package Manager Console is not presently available. For other capabilities, use the dotnet.exe or nuget.exe CLI tools. Visual Studio for Mac
• Visual Studio Code On Windows, Mac, or Linux, NuGet capabilities are available through marketplace extensions or use the dotnet.exe or nuget.exe CLI tools. Visual Studio Code

The MSBuild CLI also provides the ability to restore and create packages, which is primarily useful on build servers. MSBuild is not a general-purpose tool for working with NuGet.

Install the nuget.exe CLI by downloading it from nuget.org and adding the folder to your PATH environment variable.

The latest version is recommended.

NuGet Gallery | Downloads

To create a package, first we need to create .nuspec file. This is a manifest file that uses XML to describe the package. This manifest file is used to build a package and it's also stored in the package after the package is built. To create this .nuspec file, execute the following command in a command prompt.

nuget.exe spec

The default name for the manifest file is Package.nuspec.

<?xml version="1.0" encoding="utf-8"?>
<package >
  <metadata>
    <id>Package</id>
    <version>1.0.0</version>
    <authors>username</authors>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <license type="expression">MIT</license>
    <!-- <icon>icon.png</icon> -->
    <projectUrl>http://project_url_here_or_delete_this_line/</projectUrl>
    <description>Package description</description>
    <releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
    <copyright>$copyright$</copyright>
    <tags>Tag1 Tag2</tags>
    <dependencies>
      <group targetFramework=".NETStandard2.1">
        <dependency id="SampleDependency" version="1.0.0" />
      </group>
    </dependencies>
  </metadata>
</package>

NuGet produces an error if you try to create a package with default values in your .nuspec file, so you must change the following fields before proceeding.

• licenseUrl
• projectUrl
• iconUrl
• releaseNotes
• tags

For packages built for public consumption, you must define Tags property, as tags help others find your package on sources like nuget.org and understand what it does.

You can also add any other elements to the manifest at this time, as described on Manifest Elements from NuGet - snippset.

• id: This is a unique identifier of the package. It's the name of the package that is used when installing the package using the Install-package command in the Package Manager console in Visual Studio. The Package Id follows the same rule as a .Net namespace. For example Mvc.Helper is a valid package id.
• Version: This is a version of the package like 1.0.0.
• Authors: This is a comma separated list of the authors of the package.
• owners: This is a comma separated list of package creators. Most of the time it is same as package authors.
• licenseUrl: This is a link to the license that the package is under. For example Apache license.
• projectUrl: This is a link to the project home page. If the project is open-source then it can be the project source code URL like Github project URL.
• iconUrl: This is the link for the image that is used as an icon for the package. The size of the image should be a 32x32 pixel png image with transparent background.
• requireLicenseAcceptance: This is a boolean value that indicates whether the Nuget client must ensure that the package license (specified by licenseUrl) is accepted by the user before installation of the package.
• description: As the name suggests, this is a long description of the package.
• releaseNotes: This is a description of the changes that are made in each release of the package.
• copyright: Specify copyright details for the package.
• tags: This is a space-separated list of keywords that describes the package. These tags are useful when a user tries to search for the package.
• dependencies: This element specifies the list of other dependent Nuget packages that should be installed in order to use our package.
• title: This is a user-friendly name of the package. If not specified then the package id is used. (By default this element is not included in the manifest file.)
• files: This element is used to specify the package content. (By default this element is not included in the manifest file.)

The elements are described in .nuspec file reference.

The contents of the Nuget package can be defined either by defining a conventional based folder structure relative to the package manifest file or by using a files element in the manifest file. The convention based approach requires the following folder structure:

• tools: The tools folder of a package is for PowerShell scripts and programs accessible from the Package Manager Console.
• lib: Assemblies (DLL files) in the lib folder are added as assembly references when the package is installed.
• content: Files under the content folder are directly copied to the root of the application when the package is installed. For example, if we want to add a script file to the /Scripts folder of the target application, then we need to place that file under Content/Scripts/{jsfilename}.

<?xml version="1.0" encoding="utf-8" ?>
<package>
 <metadata>
  <id>Nuget.Package.Name</id>
  <version>1.0.0</version>
  <title>Nuget Package Name</title>
  <authors>Company Ltd.</authors>
  <owners>Joe Smith</owners>
  <license type="expression">MIT</license>
  <projectUrl>https://www.website.com/project</projectUrl>
  <requireLicenseAcceptance>false</requireLicenseAcceptance>
  <description>A description of your package</description>
  <releaseNotes>Initial 1.0.0 release</releaseNotes>
  <copyright>Copyright 2022 CompanyLtd</copyright>
  <tags>sample nuget</tags>
  <dependencies>
   <group targetFramework=".NETStandard2.0">
   </group>
  </dependencies>
  <summary> A summary of your package </summary>
 </metadata>
 <files>
  <file src="README.txt" />
  <file src="lib\**" target="\lib\netstandard2.0" />
 </files>
</package>