RDK0005 — Tool package is not installable

Severity: error · Command: redecker inspect

A package declares itself a .NET CLI tool but is missing something dotnet tool install needs.

Why this one exists

Search GitHub for DotnetToolSettings.xml and you find the same failure in repository after repository, including dotnet/runtime and unoplatform/uno:

Settings file 'DotnetToolSettings.xml' was not found in the package.

The profile is the worst kind. The project builds. It packs. It restores. It publishes. Then it fails for every single user who tries to install it — on a version that, once on nuget.org, can be unlisted but never deleted.

What it checks

For any package whose nuspec declares packageType DotnetTool:

Check	Consequence if wrong
A tools/<framework>/<runtime>/ folder exists	Nothing to install
Each such folder has DotnetToolSettings.xml	dotnet tool install fails outright
The EntryPoint it names is in that folder	Installs, then fails to run
EntryPoint is present at all	Installs, then fails to run
The command name is not a .dll	Users type something absurd

The third and fourth are the nastier pair: the install succeeds, so CI looks fine, and the tool falls over the first time anyone runs it.

Example

$ redecker inspect --file ./artifacts/dotnet-thing.1.0.0.nupkg
error RDK0005: tools/net9.0/any has no DotnetToolSettings.xml
    A tool package needs this file beside its entry point; it names the command and the assembly
    to run. Restore and publish both succeed regardless, so this is only discovered by whoever
    tries to install it.

Every tools/<tfm>/<rid>/ folder is checked independently — shipping a correct net8.0 and a broken net9.0 is a normal way for this to happen when a framework is added.

Use it before you publish

This is the rule that most argues for --file:

dotnet pack -c Release
redecker inspect --file ./artifacts/packages/*.nupkg

Redecker runs exactly that against its own tool package on every pull request.

Honest caveat

The reported occurrences of this error do not all share one root cause — some are genuine packaging defects, others turned out to be SDK-side problems that produced the same message. This rule catches the first kind, which is the kind you can do something about.