Download ^NEW^ Nuget Package Explorer
Tessa Frabott
When I add a file to my Nuget package under the lib folder using the Nuget Package Explorer, I select the file via a standard file dialog. So I add all the files under the desired platforms... simple.
My question is, since there is nothing in the Nuget Package Explorer that tells me the source path of each file, do I have to re-add the files when I make changed to my files? For example, version 1.0.0 of "MyNugetPackage.nupkg" has a "net45" lib folder and 1 DLL, MyDll.dll. I make some changes to MyDll.dll and want to update MyNugetPackage to version 1.0.1. Do I have to delete the MyDll.dll from the net45 folder and re-add it? Do I need to create a whole new Nuget package? Or does the existing reference just point to the new MyDll.dll?
I have a number of VSIXs for a product of mine that I would like to distribute as a Single Nuget package. There are 3 separate Visual Studio 2013 packages that I only wish to distribute to VS 2013 IDE's (won't run in earlier versions of VS).
You need to put you VSIX-files into 'tools' folder of your package. Then you have to create init.ps1 or install.ps1 to kick the installation process of vsix.Please note that install.ps1 will not be called for 'solution wide packages' (i.e. packages which have no content or lib folder). So if your package has only 'tools' folder you'll have to put installation logic into init.ps1. But init.ps1 will be called every time you open your solution in VS. This is a breaking change NuGet team made in NuGet 2.6 or 2.7 (I don't remember exacly). So now putting installation login into init.ps1 isn't a good idea anymore :(
NuGet Package Explorer is a ClickOnce application which allows creating and exploring NuGet packages easily. After installing it, you can double click on a .nupkg file to view the package content. You can also load packages directly from the official NuGet feed.
No matter what your package does or what code it contains, you use one of the CLI tools, either nuget.exe or dotnet.exe, to package that functionality into a component that can be shared with and used by any number of other developers. To install NuGet CLI tools, see Install NuGet client tools. Note that Visual Studio does not automatically include a CLI tool.
For non-SDK-style projects, typically .NET Framework projects, follow the steps described in this article to create a package. For step-by-step instructions using Visual Studio and the nuget.exe CLI, see Create and publish a .NET Framework package.
Technically speaking, a NuGet package is just a ZIP file that's been renamed with the .nupkg extension and whose contents match certain conventions. This topic describes the detailed process of creating a package that meets those conventions.
Packaging begins with the compiled code (assemblies), symbols, and/or other files that you want to deliver as a package (see Overview and workflow). This process is independent from compiling or otherwise generating the files that go into the package, although you can draw from information in a project file to keep the compiled assemblies and packages in sync.
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.
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.
For details on declaring dependencies and specifying version numbers, see packages.config and Package versioning. It is also possible to surface assets from dependencies directly in the package by using the include and exclude attributes on the dependency element. See .nuspec Reference - Dependencies.
Because the manifest is included in the package created from it, you can find any number of additional examples by examining existing packages. A good source is the global-packages folder on your computer, the location of which is returned by the following command:
When creating a .nuspec from a Visual Studio project, the manifest contains tokens that are replaced with information from the project when the package is built. See Creating the .nuspec from a Visual Studio project.
Because a NuGet package is just a ZIP file that's been renamed with the .nupkg extension, it's often easiest to create the folder structure you want on your local file system, then create the .nuspec file directly from that structure. The nuget pack command then automatically adds all files in that folder structure (excluding any folders that begin with ., allowing you to keep private files in the same structure).
The advantage to this approach is that you don't need to specify in the manifest which files you want to include in the package (as explained later in this topic). You can simply have your build process produce the exact folder structure that goes into the package, and you can easily include other files that might not be part of a project otherwise:
Again, the generated .nuspec contains no explicit references to files in the folder structure. NuGet automatically includes all files when the package is created. You still need to edit placeholder values in other parts of the manifest, however.
Creating a .nuspec from a .csproj or .vbproj file is convenient because other packages that have been installed into those project are automatically referenced as dependencies. Simply use the following command in the same folder as the project file:
NuGet 2.x supported the notion of a solution-level package that installs tools or additional commands for the Package Manager Console (the contents of the tools folder), but does not add references, content, or build customizations to any projects in the solution. Such packages contain no files in its direct lib, content, or build folders, and none of its dependencies have files in their respective lib, content, or build folders.
When you include a file named readme.txt in the package root, Visual Studio displays the contents of that file as plain text immediately after installing the package directly. (Readme files are not displayed for packages installed as dependencies). For example, here's how the readme for the HtmlAgilityPack package appears:
In some cases, you might want to add custom build targets or properties in projects that consume your package, such as running a custom tool or process during build.You can learn more about MSBuild props and targets in NuGet packages
A helpful way to examine a package after creating it is to open it in the Package Explorer tool. This gives you a graphical view of the package contents and its manifest. You can also rename the resulting .nupkg file to a .zip file and explore its contents directly.
You can use various command-line switches with nuget pack to exclude files, override the version number in the manifest, and change the output folder, among other features. For a complete list, refer to the pack command reference.
Referenced projects: If the project references other projects, you can add the referenced projects as part of the package, or as dependencies, by using the -IncludeReferencedProjects option:
Before publishing a package, you typically want to test the process of installing a package into a project. The tests make sure that the necessarily files all end up in their correct places in the project.
But sometimes you want to install several packages into a project. Forexample, when you installSpecFlow into a projectyou also have to install a test framework such asNUnit orMsTest. And maybe an assertion framework or amocking framework.
Open NuGet Package Explorer and fill out the basic information aboutyour package (Id, Name, yada yada). A little gotcha is that you need togo Edit->Edit package metadata (CTRL+K) to be able to edit the package.
A big part of elmah.io is our clients for various web and logging frameworks. All of them are open-source, hosted on GitHub, and available as NuGet packages on nuget.org. I have blogged about building on GitHub Actions in the past. It struck me that I have never actually shared anything about the various steps we take for validating NuGet packages before pushing them. Let's fix that!
So, why do we need to validate NuGet packages in the first place? NuGet packages support a range of features like bundling debug symbols, providing source link, and more. Some of the features are provided out of the box when building the package while others need some custom work. The easiest way to inspect NuGet packages is the NuGet Package Explorer tool. With that installed, you can open .nupkg files and see both metadata and the actual content.
Before we start fixing the failed checks, let's extend the GitHub Actions pipeline for this repository. Inspecting packages manually and on every commit quickly becomes tedious so we want to automatically run these health checks when building the code. Luckily, the nice folks behind NuGet Package Explorer released support for running these checks from the command line too. The tool is called dotnet-validate and can be installed and run on GitHub Actions (or anywhere else really) by including the following steps to the build file:
As suggested by the names, the first step installs the tool and the next step runs it against .nupkg files. In the case of the RickrollingMiddleware repository, the NuGet package is built into the out directory but the path may vary by the way the package is built in other repositories.
f5d0e4f075