Add MonoGame 3.8.5 Content Builder export mode (closes DX12/Vulkan shader gate)

[vchelaru]

Summary

• Adds an opt-in ContentBuildMode.ContentBuilder export choice, available for every MonoGame target. It routes both assets and shipped .fx shaders through MonoGame 3.8.5 GA's new code-first Content Builder (a generated {ProjectName}.Content console project + Builder.cs + BuildContent.targets) instead of raw/ShadowDusk/MGCB, superseding ShaderCompileMode for that export.
• Unlike the legacy mgcb.exe, the new Content Builder isn't limited to a fixed platform list — so this is the mechanism that finally closes the DX12/Vulkan shader gate from issue Export shaders to gated targets: iOS, MonoGame DX12/Vulkan #52 (CompilesShippedShaders now returns true there under Content Builder mode).
• MonoGame.Content.Builder.Task stays installed on classic MonoGame targets even in Content Builder mode: Apos.Shapes/Gum ship their own .fx + Content.mgcb via buildTransitive, invisible to the new pipeline (which only walks the fiddle's own Assets/ folder). Both pipelines deliberately coexist there.
• New export-dialog "Content pipeline" radio (Raw / Content Builder), gated to ExportRuntime.MonoGame; picking Content Builder hides the now-superseded shader-compilation radio and updates the status banner.

Stacks on #119 (chore/monogame-3.8.5-ga, not yet merged) — this branch is based on that PR's HEAD, so the diff includes its commit until #119 merges.

Implementation notes / deviations from the plan

• Asset exclusion list widened from 2 to 13 extensions. The plan named only .achx/.fnt as needing to stay raw (no pipeline importer). A grep of Index.razor.cs's SupportedAssetExtensions (broadened by Broaden asset allowlist to include tilemap/level and text-data formats #115, the commit right before this stack) turned up the full set that XnaFiddle ships raw via TitleContainer.OpenStream/dedicated loaders rather than ContentManager.Load<T>: .achx .fnt .ttf .ember .xnb .tmx .tsx .world .ldtk .ogmo .json .txt .xml. Only .png/.wav are actually ContentManager-loadable, so those are the only ones routed into {ProjectName}.Content/Assets/; everything else keeps shipping into the head's own Content/ folder as before.
• Fixed a real bug in the plan's own predicate spec. The plan's verbatim UsesShadowDuskShaders/UsesMgcbShaders guarded on contentMode != ContentBuildMode.ContentBuilder (global), which would have gated all shaders — including KNI/FNA — to "unsupported" the moment ContentBuildMode.ContentBuilder was passed to Export(), even for a non-MonoGame target. Changed the guard to !UsesContentBuilder(target, contentMode) (target-aware) so KNI/FNA stay a true no-op, matching the plan's own required "KNI/FNA no-op" test.
• GenerateCsproj's raw-copy suppression is conditional, not unconditional. The plan said to unconditionally suppress the <None Include>/<AndroidAsset Include> raw-copy block under Content Builder mode. That would silently drop the .achx/.fnt-style excluded files from the build output entirely (they'd still be zipped into the head's Content/ folder, but never copied to the output dir). Instead the block now stays gated on whether there's any Content-Builder-excluded content left (hasRawContentBuilderAssets), so those files still copy correctly.

Verification

• dotnet test — 337/337 passing (7 new facts + 5 new Theory rows for Content Builder mode).
• dotnet build — XnaFiddle.Core, XnaFiddle.Tests, XnaFiddle.BlazorGL all clean.
• Real end-to-end build attempted (network/NuGet was reachable in this sandbox, including the brand-new MonoGame.Tool.Dxc etc. packages): generated a real Content-Builder-mode zip for a classic target (MonoGameDesktopGL) and a next-gen target (MonoGameWindowsDX12), dotnet restore + dotnet build both.
  • Classic target: asset (.png) and shader (.fx) both correctly picked up by WildcardRule("*") and compiled to .xnb. Confirms the asset-routing/exclusion logic is correct and there's no MonoGame.Content.Builder.Task vs. Content Builder target-name collision.
  • DX12 target: asset compiled fine; the shader failed with a legitimate, expected error (Invalid DirectX 12 pixel profile 'ps_3_0'! Requires ps_6_0) — my throwaway test .fx used a legacy SM3 profile, which DX12's real DXC-based compiler correctly rejects. This confirms the DX12 plumbing (packages, Import, WildcardRule routing) works end-to-end; it's not an exporter bug, just a reminder that a real shipped .fx needs an SM6-compatible technique to build on DX12.
  • Found a real, reproducible issue (not a target-name collision, but the same category of risk): running dotnet build on the whole .slnx (default multi-core parallelism) races — the Content project is both a normal top-level .slnx member and invoked via a nested <MSBuild Projects="...Content.csproj"> inside BuildContent.targets, and the two concurrent builds of the same project collide on the output DLL (CS2012: ... being used by another process). Verified this is not something this PR introduced — MonoGame's own official 3.8.5 GA template (fetched from MonoGame/MonoGame.Templates) has the exact same structure (byte-for-byte matching BuildContent.targets/{Name}.Content.csproj, confirmed by direct comparison) and would hit the identical race. Two verified workarounds: dotnet build *.slnx -maxcpucount:1, or dotnet restore *.slnx once followed by dotnet build on just the single head .csproj. A ProjectReference ReferenceOutputAssembly="false" fix doesn't work as-is (cross-TFM error: head is net8.0, Content project is net9.0 per the reference template). Flagging this for follow-up rather than fixing here, since it's an upstream MonoGame template characteristic, not specific to this PR's logic.

Test plan

• dotnet test (337/337)
• dotnet build across XnaFiddle.Core/XnaFiddle.Tests/XnaFiddle.BlazorGL
• Real dotnet restore/dotnet build of a generated Content-Builder-mode export (classic + DX12 targets)
• Manual verification in the running app (export dialog UI)

Update: reworked into two independent axes

The design above conflated "how assets build" and "how shaders compile" into one 3-way choice — picking Content Builder unconditionally forced shaders through its native DXC pipeline and hid ShadowDusk entirely. Reworked into two orthogonal enums:

• ContentBuildMode: Raw / ClassicMgcb (new) / ContentBuilder — how non-shader assets build.
• ShaderCompileMode: ShadowDusk / Native (renamed from ContentPipeline) — how .fx compiles, independent of asset strategy.

ShadowDusk is now the default shader compiler under every content strategy, not just Raw. ClassicMgcb is a real asset pipeline for the first time (previously it only ever touched .fx) — .png/.wav now compile via TextureImporter/WavImporter, with ColorKeyEnabled=False forced (MonoGame's TextureProcessor defaults to color-keying pure magenta to transparent, which would otherwise silently punch holes in shipped textures — confirmed with a real end-to-end build, see Verification below).

DX12 + ShadowDusk: per the plan, checked ShadowDusk's NuGet feed and PlatformTarget.cs for a DX12 backend before wiring MonoGameWindowsDX12 into GetShaderExportInfo. Still at 0.12.0, no DirectX12 enum member, README lists DX12 as "Not yet". Left the existing _ => default fallthrough as-is; CompilesShippedShaders(DX12, ShadowDusk, ContentBuilder) stays false. Test DX12_ContentBuilder_ShadowDusk_StaysGated_UntilShadowDuskAddsDx12 pins this and documents the flip: once ShadowDusk ships DX12, add the MonoGameWindowsDX12 case and this assertion flips to true with no other code change needed.

Bug found during implementation (not called out in the plan): decoupling the axes means a ShadowDusk-mode .fx can now stay in the head's own Content/ folder even under ContentBuildMode.ContentBuilder (previously Content Builder always redirected shaders too, so this case never existed). The csproj's wholesale-copy-to-output gate assumed nothing was ever left in Content/ under Content Builder mode, so that .fx would ship in the zip but never get CopyToOutputDirectory — build succeeds, but the shader fails to load at runtime. Fixed by broadening hasNonPipelineContentBuilderAssets's computation to also cover hasShaders && !useContentBuilderShaders; regression-tested by SinglePlatform_ContentBuilder_ShadowDuskShaders_HeadContentShaderStillWiredForCopyToOutput.

Verification (this update):

• dotnet test XnaFiddle.Tests — 350/350 passing (76 tests in ProjectExporterTests).
• dotnet build XnaFiddle.sln — clean.
• Manual end-to-end: exported the new default combo (ClassicMgcb + ShadowDusk, one magenta .png asset) via a throwaway console driver calling ProjectExporter.Export directly, extracted the zip, ran a real dotnet restore/dotnet build, then parsed the compiled magenta.xnb's raw pixel bytes directly — all 4 texels stayed opaque magenta (alpha=255), confirming ColorKeyEnabled=False works end-to-end, not just structurally in the generated Content.mgcb text.

Scope: this update covers the core enum/predicate rework, GenerateContentMgcb/asset-routing/GenerateCsproj, the UI (two independent radio groups), and the ProjectExporterTests.cs rewrite. The automated build-verification test suite (XnaFiddle.ExportBuild.Tests) remains a separate, deferred follow-up.

🤖 Generated with Claude Code