NuGet Package Explorer: a GUI for building, inspecting and signing .nupkg files

The gap NPE fills between nuspec, nupkg and a feed

A .nupkg is a zip archive with a .nuspec manifest inside, and that structure is easy to produce with the NuGet command-line tools but awkward to inspect. NuGet Package Explorer, usually shortened to NPE, is a GUI built for exactly that gap. The README describes it as an application that makes it easy to create and explore NuGet packages, loading a .nupkg or .snupkg either from disk or directly from a feed such as nuget.org.

The audience is narrow and specific. Package authors who want to see what they are about to publish, reviewers who need to open someone else's package and read its layout, and anyone who has to sign a package with a code signing certificate. If your build already produces a correct package and you never open it, NPE adds nothing to your day. The README is explicit that command-line package creation belongs to the NuGet command-line tools, so NPE is not positioned as a CI component.

How the package contents pane infers where files belong

The core interaction is drag and drop with a placement prompt. According to the README, you open the files you want to include in Windows Explorer and drag them into the Package contents pane. NPE then attempts to infer where the content belongs and asks you to confirm the directory inside the package. The README gives one worked example: dragging an assembly prompts you to place it in the lib folder. Folders can also be added explicitly through the Content menu.

That inference is the interesting design choice, and it is also the one to be sceptical about. A package layout is a contract with the consuming project, and the folder a file lands in (lib, tools, content, build) decides whether it is referenced, executed or copied. An automatic guess that you confirm is faster than typing paths, but it puts the tool's heuristic between you and the archive. The metadata side is less magical: Edit > Edit Package Metadata opens an editor for the underlying .nuspec file, and the README points to the nuspec reference for the fields.

The repository layout shows the project is not one binary. There are PackageExplorer/ and PackageViewModel/ directories for the Windows implementation, a Uno/ tree for the cross-platform and WebAssembly work, Core/, Common/, Types/, and a separate dotnet-validate/ project. The build files include Directory.Build.props, Directory.Packages.props and a global.json, so the solution pins its SDK and package versions rather than floating them.

Installing NuGet Package Explorer on Windows, and the winget command

The README names four install paths: the Microsoft Store, Chocolatey, winget (which acquires the Store build), and the web app. The Store version is called the preferred one because it auto-updates and is the full application. If winget is already installed, the README gives this command:

winget install "NuGet Package Explorer"

For Chocolatey, the README's steps are to run PowerShell as Administrator, install Chocolatey itself, then install the package:

choco install nugetpackageexplorer

There is also a nightly Windows build distributed as an app installer, which the README says installs alongside the release version without interference and updates automatically. The web version at nuget.info runs on any platform and is also available as a PWA; the README describes it as a subset covering browsing, inspecting and uploading packages, implemented with Uno Platform WebAssembly support.

For a first real use, the README's own sequence is: launch NPE, choose File > New (Ctrl-N) or Create a new package from the Common tasks dialog, open Edit > Edit Package Metadata (Ctrl-K) to write the .nuspec, drag your files into the Package contents pane and confirm the placement prompt, then save with File > Save (Ctrl-S). Signing is a separate step, File > Sign and Save As, and requires a code signing certificate.

dotnet-validate: the cross-platform CLI and its documented gaps

A subset of the checking functionality exists outside the GUI as a .NET CLI tool. The README gives the install command with a preview version and adds a note to use the latest version:

dotnet tool install -g dotnet-validate --version 0.0.1-preview.42

There is one command, package, with two subcommands, so that dotnet validate can be extended later. Local validation takes a file path; remote validation takes a package ID and accepts a version, a V3 feed source (defaulting to https://api.nuget.org/v3/index.json) and help flags. The README states the tool returns -1 if the package is not fully valid, with details printed to the console.

Two limitations are stated in the README rather than discovered by users. First, the tool should eventually emit results in a machine-parsable way (json), which means today's output is for humans reading a terminal, not for a build step that parses it. Second, exact versions for remote packages are listed as a known issue: only the latest is checked. If you need to validate a specific published version, the README says that is not working yet. Both of those are disqualifying for anyone hoping to wire the CLI into a release gate right now.

Where NPE is the wrong tool, and what to use instead

The clearest boundary is automation. The README tells readers who want to build packages from the command line to use the NuGet command-line tools, as documented on the official NuGet site. That is not a hedge, it is a division of labour: NPE is for the moments when a human needs to look at or assemble a package, and nuget.exe or dotnet pack is for the moments when a machine does it repeatedly.

A second boundary is platform and feature coverage. The full application is the Windows build; the web version is described as a subset, and the README notes that the current Windows/WPF implementation will remain in the Windows store indefinitely, or at least until the new version fully replaces its functionality. That sentence is worth reading twice. It means the Uno-based rewrite is not yet at parity, and a reader on macOS or Linux is choosing the subset deliberately, not getting the same product in a browser tab.

A third boundary is validation depth. If your goal is checking package health rather than exploring contents, dotnet-validate is the relevant piece, but the README itself flags that it is early ("A subset of functionality") and that version-specific remote checks do not work. For a pipeline that must fail a build on a bad package, the mature path is the NuGet CLI and your own checks, not this preview tool.

Maintenance, licensing and what upgrading costs you

The repository is not archived, and the last push was on 2026-08-05, which is recent enough that the codebase is being touched. The release history is more uneven than the push date suggests: v6.2.19 was tagged on 2025-04-03, the previous release before it was v6.0.64 on 2022-08-22, and v6.0.27 on 2021-12-07. Long gaps between tagged releases are visible in that list, so a user who depends on release notes rather than the main branch should expect quiet periods.

Upgrade cost depends on which install path you chose. The Microsoft Store build auto-updates, which the README presents as the reason it is preferred; the nightly build also updates automatically and installs side by side with the release version. The Chocolatey package is updated through choco, so it follows the maintainers' publishing cadence rather than the Store's. The dotnet-validate tool is a global .NET tool, and because the README's example pins a preview version, upgrading means reinstalling with a newer version rather than assuming an automatic update.

Licensing is MIT, per the repository. That is permissive and typical for .NET ecosystem tooling, and the LICENSE.txt file sits at the repository root. This is a description of the licence identifier, not legal advice; if you redistribute the application or bundle it into a commercial product, read the licence text yourself. The repository also carries a PrivacyPolicy.md, which matters for the web version, since uploading and inspecting packages happens through a hosted service.

Editorial conclusion

Adopt NuGet Package Explorer if you build or audit .nupkg and .snupkg files by hand and want to see the contents, edit the .nuspec and sign in one window, or if you only need a package health check and can use dotnet-validate from the .NET CLI. Do not adopt it as your release pipeline: the README points to the NuGet command-line tools for building packages from the command line, and the CLI is documented as incomplete, with exact-version checks for remote packages listed as a known issue. Verify first that your target platform is covered (the full application is the Microsoft Store build, the web build is described as a subset), and check the current dotnet-validate version rather than the preview number in the README.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NuGetPackageExplorer/NuGetPackageExplorer on GitHub
4. README
5. Releases