▚s&box/field-guide
▚ field-guide / tooling-environment
toolingwhitelistpublishingsilent-failure
the symptom, in your words

"dotnet build verifies compile but NOT the whitelist"

✓ verified on engine 26.07lane: Tooling & environmentposted
▸ SYMPTOM
  • dotnet build Code/<proj>.csproj is green.
  • In-editor / published play rejects APIs with SB1000 whitelist violations (Environment.*, reflection, etc.).
  • Agents report "verified" on code the game then refuses.
▸ CAUSE

The s&box whitelist is only enforced by the in-editor compiler (and the published package sandbox). Headless dotnet build references the Steam-managed DLLs and type-checks — it does not run the access list.

Banned examples observed in game code:

  • Environment.* (e.g. Environment.TickCount)
  • Raw System.IO / Process / Thread (as used for banned patterns)
  • Runtime reflection: Type.GetProperty / PropertyInfo.SetValue
  • Vendored-lib pitfalls: System.Console, crypto RNG (HashCode.GenerateGlobalSeed), Environment.NewLine

Known-ok examples: System.Text.Json, ArrayPool, GameTask.RunInThreadAsync, new System.Random(int) / time-seeded Random (whitelisted).

Http may call domains (not raw IPs) per whitelist notes.

Published packages can still diverge further across engine updates — join as a player after publish (broke-after-publish-whitelist).

▸ FIX
snippet
dotnet build Code\<project>.csproj
# necessary, not sufficient

Whitelist sweep on new code before shipping:

snippet
Environment. | System.IO | Process. | Thread. | GetProperty | SetValue | DllImport

Prefer engine surfaces: Time.Now-derived entropy, FileSystem.Data instead of raw IO, handoff notes instead of reflection across files.

Whole-tree "0 warnings" claims need dotnet build --no-incremental — incremental builds lie about warning counts (warnings only re-emit for files that recompiled).

Never disable the whitelist to "make it compile" if you still need sbox.game publish — that blocks platform publish and pushes you toward standalone-steam-export.

▸ WHY IT WORKS

Two compilers, two jobs: Roslyn proves types; the s&box access list proves the API is allowed in the player sandbox. Green headless builds only answer the first question.

✓
Verified on engine 26.07 — seen in a real project.
s&box moves fast; an undated fix is a liability. Spot a stale detail?
related gotchas
Everything broke at once — check for a stale assembly first
Failed package compile leaves the editor running the last-good hotload — multi-symptom 'regressions' are often stale code.
A pre-publish checklist for sbox.game
Org/ident rules, every store-page field is launch-blocking, AI thumbnails demoted — verify as a player after publish.
It worked in the editor but broke after publishing
Whitelist divergence, loose Resource Files, and silent cloud-asset failures after publish.
Heavy work without frame hitches
GameTask.RunInThreadAsync for parse/math; main thread only for engine objects; Yield every N items for loading UI.
Standalone Steam export
Preview as of 2026-07: Valve approval + Facepunch license; full .NET, lose platform services; clean PackageReferences or startup hangs.
Headless dotnet build misses Razor compile errors
dotnet build reports 0 errors on .razor files the in-editor compiler rejects — the headless build doesn't surface the Razor errors the live editor's Roslyn compiler flags.