RDK0001 — Dangling asset reference

Severity: error · Command: redecker inspect

A package ships MSBuild logic that points at a file the package does not contain.

Why it matters

This is the rule Redecker was written for. SQLitePCLRaw.lib.e_sqlite3 2.1.12 stopped shipping runtimes/win-arm/native/e_sqlite3.dll, but kept the buildTransitive/net461 targets file that copies it. The result:

• dotnet restore succeeds
• Version resolution succeeds
• Every target framework builds — except net48 on Windows, which fails with MSB3030

Nothing about that is expressed in the dependency graph, so no amount of version reasoning finds it. Reading the package finds it immediately.

What it checks

For every .props and .targets file under build/, buildTransitive/ and buildMultiTargeting/ — the files a consuming project imports — Redecker resolves every path anchored to $(MSBuildThisFileDirectory) and asserts the package actually contains it.

What it deliberately ignores

A reference is skipped when it still holds an unexpanded MSBuild property, item metadata, or a wildcard:

<None Include="$(MSBuildThisFileDirectory)../../runtimes/$(RuntimeIdentifier)/native/x.dll" />

The value there depends on evaluation context the rule does not have, and guessing would produce false positives. Reporting only what can be resolved with certainty is what keeps this usable as a gate: a finding means a file really is missing.

References with no $(MSBuildThisFileDirectory) anchor are also skipped, because they are relative to the consuming project rather than to the package.

Example

$ redecker inspect SQLitePCLRaw.lib.e_sqlite3 --to 2.1.12
error RDK0001: buildTransitive/net461/SQLitePCLRaw.lib.e_sqlite3.targets references
    runtimes/win-arm/native/e_sqlite3.dll, which the package does not contain

If you hit this in your own package

You are shipping a broken package — fix it before publishing rather than suppressing the rule. Redecker's own Redecker.MSBuild package is checked against this rule for exactly that reason.