NuGet.exe
This article is translated from:
- Https://docs.nuget.org/Create/Creating-and-Publishing-a-Package
- Https://docs.nuget.org/Create/Enforced-Package-Conventions
Basic steps
- To generate a Nuspec file using the NuGet spec command
- Edit the Nuspec file and use the NuGet Pack command to package
To create a package from an assembly
Execute the following command: Generate the Nuspec file:
NuGet Spec MyAssembly.dll
To execute the package command after editing the Nuspec file as needed:
NuGet Pack Myassembly.nuspec
To create a package from a project file
In the project folder, execute:
NuGet Spec
The tool reads the csproj or vbproj file to generate the Nuspec file. The Nuspec file generated in this way contains some replaceable tokens, which are replaced with the item's metadata when packaged. Available tags include:
- $id $ Replace with assembly name
- $version $ replace with AssemblyVersionAttribute or AssemblyInformationalVersionAttribute
- $author $ replace with AssemblyCompanyAttribute
- $description $ replace with AssemblyDescriptionAttribute
If auto-replace is not required, these tags can be removed manually.
Note that the use of the project file to execute the Package command replaces these tokens, and the use of the Nuspec file to execute the package command is not replaced.
Use the Files node to explicitly specify which files are included in the package, such as:
< Files > < src= ".. \.. \someroot\**\*.* " target=" "/></files>
The package will contain only the files specified in this node, and if Files node is empty, the package will contain only the Lib folder. In addition, the pack command excludes directories that begin with a period, such as. git.
After editing the Nuspec file, execute the Package command:
NuGet Pack Myproject.csproj
If your project references other projects, you can use the-includereferencedprojects option to include the files for the referenced project. Assume the reference structure as shown:
Execute command
NuGet Pack A.csproj-includereferencedprojects
The generated package contains the files in the project A,b,c,d,e,f,g.
If the referenced project has a nuspec file, it will be a dependency, such as a C.nuspec file in the directory where C.csproj is located, and the resulting package will contain the files in the project A,b,d,e and have a dependency on C.
By default, NuGet uses the default build configuration (usually debug) to package the files for the Release configuration, which can be executed:
NuGet Pack Myproject.csproj-prop Configuration=release
Visual Studio does not provide an interface to modify the default build configuration, and to modify the default build configuration, you need to manually edit the project file.
To create a package at build time
By adding a afterbuild target, you can automatically create a package when the build succeeds. Edit the project file manually by adding the following:
<Name= "Afterbuild" Condition= "' $ (Configuration) ' = = ' Release '" > <Command= "NuGet Pack $ (projectfilename)-prop Configuration=release "></Exec></Target >
The Nuget.exe is automatically called when the build is configured to Release to create the package.
To create a package from a contract-based directory
In addition to assemblies, packages can contain source code, PowerShell scripts, executables, configuration files, and so on. NuGet has a contract for the working directory structure:
- Tools. Used to hold PowerShell scripts and programs that can be accessed in the Package Manager console. When this directory is copied to the target project, it is added to the ' $env:P ath (Path) environment variable.
- Lib. When you install a package, the assembly under this folder is added as a reference to the target project.
- content. When the package is installed, the files under this folder are copied to the root of the target project.
- build. When the package is installed, it is automatically inserted into the. csproj file.
You can think of the content directory as the root of the target project. If you want to add a picture file to the/images directory of the target project, you should place the picture in the Content/images folder of the package.
Create a checklist
Please execute the following command to create a spec file from scratch
NuGet Spec
An. nuspec file is generated in XML format.
<?XML version= "1.0"?>< Packagexmlns= "Http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"> <metadata> <ID>Mypackageid</ID> <version>1.0</version> <authors>Philha</authors> <Owners>Philha</Owners> <Licenseurl>Http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE</Licenseurl> <Projecturl>Http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE</Projecturl> <ICONURL>Http://ICON_URL_HERE_OR_DELETE_THIS_LINE</ICONURL> <requirelicenseacceptance>False</requirelicenseacceptance> <Description>Package description</Description> <Tags>Tag1 Tag2</Tags> <Dependencies> <DependencyID= "Sampledependency"version= "1.0" /> </Dependencies> </metadata></ Package>
Change the placeholder in the file to the actual value, then create the desired directory and copy the content
mkdir Lib mkdir Tools mkdir content mkdir content\controllerscopy . \src\somecontroller. CS Content copy .. \src\mylibrary libcopy . \SRC\SOMEPOWERSHELLSCRIPT.PS1 Tools
When the working directory is ready, execute:
NuGet Pack Yourpackage.nuspec
To package the files. Creating packages in this way does not support the tag substitution feature.
To create a solution-level package
Solution-level packages are used to follow tools or additional commands to the Package Manager console, but do not add references, content, or modify the build process. For example, the Psake package installs PowerShell scripts to help automate the build process.
If the package does not have a file in the Lib, content, build directory, it is the solution level, and is also not included in the Lib, content, and build directories by its dependencies.
Installed solution-level packages are tracked in the. NuGet directory's Package.config file, not in the Packages.config file for a specific purpose.
NuGet 3.0.0-3.2.0 does not support solution-level packages, and the workaround is to install them in public projects.
Package Contract Framework Version folder structure
When you install the package, NuGet examines the project's target framework, and then selects the appropriate subfolder from the Lib folder. Use the following naming convention to indicate to which framework the assembly is installed:
Lib\{framework Name}{version}
For example, the following folder structure supports four versions
\lib \net11 \myassembly.dll \net20 \myassembly.dll \net40 \myassembly.dll \sl40 \myassembly.dll
Starting with NuGet 2.0, content files and PowerShell scripts can also be grouped by Target framework, with rules in the Lib folder.
\content \net11 \mycontent.txt \net20 \mycontent20.txt \net40 \sl40 \ Mysilverlightcontent.html\tools init.ps1 \net40 install.ps1 uninstall.ps1 \sl40 INSTALL.PS1 Uninstall.ps1
INIT.PS1 is run at the solution level, regardless of the project and target framework, and should be placed directly in the Tools folder.
Frame name
NuGet resolves a folder name to a FrameworkName object, the name is case-sensitive, and the name and version number can be abbreviated.
If you omit the frame name, it is assumed to be the. Net framework. For example, the following folder structure is synonymous with the above:
\lib \11 \myassembly.dll \20 \myassembly.dll \40 \myassembly.dll \sl4 \myassembly.dll
The following table is a valid frame name and abbreviation
Frame name |
Abbreviation |
. NET Framework |
Net |
Silverlight |
Sl |
. Netmicroframework |
Netmf |
Windows Store |
Win |
Windows Phone (silverlight-based) |
Wp |
Windows Phone App (winrt-based) |
Wpa |
Framework version-Independent assemblies
Assemblies that are not related to the framework version are placed directly in the Lib folder.
Match of the Assembly version and the project's target framework
When you install a package with multiple assemblies to a project, NuGet matches the framework name of the Assembly with the project's target framework. If no match is found, NuGet excludes the assembly that is larger than the project framework version, and then selects the highest version from the remaining assemblies. Suppose you want to install the package in the example above into a project that targets. NET 3.5, and the assembly in the Net20 folder is actually installed.
Grouping assemblies by framework version
NuGet copies files from only one library directory, assuming the following directories
\lib \net20 \myassembly.dll (v1.0) \myassembly.core.dll (v1.0) \NET40 \myassembly.dll (v2.0)
When you install to a project that targets a. Net4, only MyAssembly.dll (v2.0) is installed, and MyAssembly.Core.dll (v1.0) is not installed. To install MyAssembly.Core.dll, include it again in NET40.
Rules that are replicated only from one directory also apply to the root Lib folder. Has the following folder structure
\lib \myassembly.dll (v1.0) \myassembly.core.dll (v1.0) \NET40 \myassembly.dll (v2.0)
For projects that target. net2.0 or 3.5, NuGet replicates MyAssembly.dll and MyAssembly.Core.dll. For projects that target the. net4.0, only MyAssembly.dll in NET40 are copied.
Automatically run PowerShell scripts when installing and uninstalling
NuGet automatically runs PowerShell scripts by naming conventions:
- Init.ps1 runs when the package is first installed to the solution. The
- package does not run when it packages to other projects of the solution. The
- will run every time the solution is opened (the Package Manager Console window must be open).
- Install.ps1 runs when a package is installed to a project.
- If a package is installed into multiple projects in a solution, it will run once for each project. The content or Lib directory of the
- package does not run until the file exists. Files that exist only in the Tools folder do not run.
- if INIT.PS1 exists, INSTALL.PS2 runs after Init.ps1 .
- [NuGet 3.x] does not run in projects that are managed using Project.json.
- Uninstall.ps1 runs after the package is uninstalled.
- [NuGet 3.x] does not run in projects that are managed using Project.json. The
- script file should be placed in the tools directory of the package.
- add such a line at the top of the file: param ($installPath, $toolsPath, $package, $project)
- $installPath is the installation directory. The
- $toolsPath is the tools directory under the installation directory. The
- $package is a reference to the package object. The
- $project is a reference to the EnvDTE project object that represents the project to which the package is installed. INIT.PS1 is run at the solution level, so null in INIT.PS1.
- When you write a script, you can set it to $project = Get-project to test $project in the console.
The actual output can be learned through the nugetpsvariables package, which writes information to the log:
Install-package Nugetpsvariables
The Nugetpsvariables package is automatically uninstalled after the log file is displayed.
To create a NuGet package with command-line tools