Build projects from the Hub

[malware-dev]

VS Code users have asked for a way to build their MDK projects from the Hub itself. The particular pain point is diagnostics: Mdk.PbAnalyzers reports whitelist violations through the normal MSBuild diagnostic channel, and VS Code's C# extension is inconsistent about surfacing them, so users discover "this API isn't allowed in a programmable block" only when a build fails somewhere they weren't looking. A Hub-owned error list would give them a reliable diagnostics view.

Feasibility

Mechanically this is straightforward, because dotnet build already does the whole job. Source/Mdk.PbPackager/build/Mal.Mdk2.PbPackager.props hooks MdkPack to AfterTargets="PostBuildEvent", so a plain build compiles, runs the analyzers, minifies and deploys. The Hub does not need to know where mdk.exe lives.

SDK preflight already exists: IUpdateManager.CheckDotNetSdkAsync detects a .NET 9 SDK and InstallDotNetSdkAsync can fetch one, so "you can't build, here's the fix" is wiring rather than new code.

Invocation details that need care

dotnet build "<csproj>" -c <Config> --tl:off -nodeReuse:false -v:m

• DOTNET_CLI_UI_LANGUAGE=en-US so the output is parseable regardless of system locale (same trick as UpdateManager.GetInstalledTemplateVersionAsync)
• --tl:off so the terminal logger doesn't spray ANSI control codes into the captured stream
• -nodeReuse:false so MSBuild worker nodes don't linger holding locks on obj/
• -p:MdkInteractive=no (maps to -interactive DoNothing) so the CLI doesn't launch Hub.exe to IPC a deployment notification back at the Hub that started the build - see Mdk.CommandLine/Interaction.cs
• Cancellation needs Process.Kill(entireProcessTree: true), since dotnet spawns MSBuild children
• Error parsing: file(line,col): error CS0103: message [project]

UI

The Hub has no output surface today. Overlays, toasts, snackbars and the options drawer are all it has, and none of them stream text. The natural home is the right pane (ProjectActionsView), either as a second drawer alongside the options drawer or as an expandable panel.

Scope - not yet decided

Tier 1 (~1 day): IBuildService plus a Build button, busy overlay while it runs, and the existing ErrorDetailsViewModel for failures. Functionally this is just "the terminal command, but as a button".

Tier 2 (~3-4 days): build output drawer with live streaming, cancel, a parsed error/warning list, configuration selector, and per-project last-build result persisted so the card shows the previous outcome. ProjectInfoAction already tracks deployed script size and last-deploy time, so a successful build gets its "deployed, 43,210 chars" confirmation for free.

Jump to error location is the piece that would matter most to the people asking. It needs a new setting: HubSettings.CustomIdePath is a bare path with no argument template, and every editor spells goto-line differently (code -g file:line:col, rider --line N file).

Out of scope

Anything global: building every registered project at once, or watching/monitoring all of them. Neither is expected to be wanted or needed by most users.

A watch mode scoped to a single project (rebuild the selected project when its sources change) is not excluded, and is worth considering as part of whichever tier gets built.

Risks

• Contention with an editor's own design-time builds over obj/ - occasional file lock errors with no real workaround beyond a clear message
• The first build needs a restore plus Mdk.References resolution, which is slow and needs the game present, so it needs a "this takes a minute the first time" affordance