RDK0006 — Unimportable build file

Severity: warning · Command: redecker inspect

A package ships MSBuild logic that nothing inside the package can reach.

The convention

NuGet imports exactly two file names from the build folder it selects:

build/<PackageId>.props
build/<PackageId>.targets

Everything else is reachable only if one of those imports it, directly or transitively. Ship this in a package called Contoso.Widgets:

build/Common.targets      ← nothing in the package imports it

and NuGet will never open it. Restore succeeds, the package installs, and the build logic does nothing.

It follows the import graph, not the file name

Judging by name alone is wrong in both directions, and real packages go both ways:

# Grpc.Tools — entry point at the root, helpers beneath it
build/Grpc.Tools.props            ← imports _grpc/ and _protobuf/
build/_grpc/_Grpc.Tools.props     ← reachable, fine

# Win2D — shared helper at the root, entry points in framework folders
build/Win2D.common.targets                     ← imported from below, fine
build/win10/Microsoft.Graphics.Win2D.targets   ← imports ../Win2D.common.targets

Both were false positives in earlier versions of this rule. It now walks imports from every entry point and reports only what is left over.

When an import path cannot be resolved — computed from a property the rule cannot evaluate — the package is left alone entirely. An unresolvable import could reach anything.

Known limitation: this rule cannot see outside the package

A build file can also be imported by the .NET SDK, a workload, another package, or a consumer writing an explicit <Import>. None of that is in the package, so SDK-shipped packages produce findings they do not deserve — Microsoft.NET.Sdk.Razor, Microsoft.DotNet.ILCompiler, Microsoft.Maui.Controls.Build.Tasks and others are all reported despite working correctly.

There is no reliable marker separating them. Microsoft.DotNet.ILCompiler carries no packageType and no Sdk/ folder, yet its Microsoft.NETCore.Native.targets is imported by the SDK's publish pipeline.

This is why the rule is a warning, not an error.

Where it earns its place

On your own package, before you publish it:

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

You know whether the SDK imports your targets by path. The rule does not, and cannot. Run against your own output the signal is clean; run across other people's packages it needs the caveat above.

A genuine example from the wild: Microsoft.Azure.StreamAnalytics.CICD ships build/StreamAnalytics.targets, whose name does not match the package id, and which imports only Microsoft.Common.targets. Nothing auto-imports it.

Example

error RDK0006: build/Orphan.targets is not imported by anything inside the package
    NuGet imports only Contoso.Widgets.props or Contoso.Widgets.targets from a build folder, and
    nothing that is imported goes on to import this file. If the SDK, a workload, or your
    consumers import it by path then this is expected; otherwise it ships and is never opened.

The wording deliberately names the benign explanation. A warning that pretends to be certain is worse than one that tells you what to check.