dotnet-inspect

What it inspects

dotnet-inspect is a command line tool for inspecting .NET libraries and NuGet packages. The README describes it as the .NET equivalent of docker inspect and kubectl describe, which is a useful way to set expectations: it is for looking at the shape and dependencies of compiled .NET assets, not for building them. The tool covers several sources. For NuGet packages you can inspect a package by name, with support for versions, custom sources, a nuget.config file, target frameworks, package layout, dependencies, and known vulnerabilities. For restored projects it uses an existing project.assets.json as the restored assets context, so you can look up APIs, search relationships, and pull dependency package skills without the tool running restore, build, or MSBuild evaluation itself. For platform libraries it resolves installed SDK and runtime assemblies, including runtime only implementation assemblies that have no NuGet package, by name or version, and it can diff two platform versions. For local assets it inspects a built DLL or a local nupkg, which is handy for auditing a build before you publish it. The README notes that Windows Metadata, the .winmd format, is not a supported input. Bare names are routed automatically: names that look like platform libraries resolve to installed platform assemblies, and other names resolve as NuGet packages, while explicit flags let you force a specific source.

Installing and running

Installing the tool is a standard .NET tool install. The README shows dotnet tool install with the global flag, after which you run dotnet-inspect followed by a command. If you would rather not install it, you can run it with the dnx runner and a command. The set of commands maps to the sources above: package, type, project, library, and diff, among others, and the README's table gives concrete examples such as inspecting System.Text.Json as a package or looking at a command type within a project. Because the tool reads a restored project.assets.json, the README advises you to restore or build first if your dependencies changed, so the context it uses is current. It is explicit that no restore, build, or MSBuild evaluation is run by the tool itself, which keeps inspections fast and side effect free. For API commands, common CoreLib aliases and simple type names like string, int, DateTime, and Guid resolve to System.Private.CoreLib, so you do not have to type the full assembly qualified name for everyday types. That design makes ad hoc inspection of a type or a dependency a single command rather than a dive into object browser tooling, which is the main reason to keep this tool in your path.

Building from source

For contributors, the README gives a specific setup that differs from a normal install. Published tool users get a coherent .NET 11 preview SDK, runtime, and workload pack set, but daily builds are reserved for explicit compiler or runtime work that has not reached a preview. The README tells you to first check how dotnet is installed and which SDK it selects, because on some machines dotnet resolves to a centrally managed location such as /usr/bin, /usr/local/share/dotnet, /snap, or a Program Files path. It warns not to replace or prepend another dotnet to PATH unless that is intentional, and instead to use dotnetup in command isolation mode or to ask a system administrator. dotnetup is the recommended way to install and track the latest preview SDK, and the README shows fetching its install script and running it. Once dotnetup is present, you can run repo commands through it to get the preview SDK without making it your shell default, or you can evaluate its environment script for a temporary override that affects only the current shell. The repository also enforces line ending policy through a test, with a repair procedure for stale Windows checkouts that left CRLF bytes. These details show a project that cares about reproducible contributor builds on top of the shipped tool.

Editorial conclusion

The tool is published without a standard SPDX license and is written in C#.