dotnet

A .NET stackspace

rig.stack.jsonc            the members
Directory.Build.targets    generated by `rig stack wire`
lib/                       a library you forked   → PR to its upstream
app/                       your own app           → `rig stack push`

app references the library the way anyone would:

<PackageReference Include="Acme.Pty.Core" Version="1.0.0" />

That line is never edited. Clone app on its own and it restores from the registry exactly as it always did; the overlay only applies inside the stackspace, and -p:UseStackSources=false puts it back for a moment when you want to check.

The trap this example is built around

The library's project file is Pty.Core.csproj, and the package it produces is Acme.Pty.Core. Those differ, and they differ often.

A hand-written overlay tends to match on %(Filename), which MSBuild splits at the last dot — so a redirect meant for one package quietly matches a differently-named sibling, and the build succeeds against the wrong one. The generated overlay never names a metadata field, so it cannot go wrong that way.

rig stack wire       # writes Directory.Build.targets
rig stack doctor     # says if something would stop it applying

The failure doctor exists for: a member carrying its own root Directory.Build.targets. MSBuild stops at the first one it finds, so an overlay above it is never read and everything beneath keeps resolving packages — with no warning at all. If a member has one, it needs to import the file above it.