Provide environment variables overriding routing decision for tasks

[JanProvaznik]

Summary

when reviewing #13660 it occured to me customers may want an escape hatch to use multithreaded mode with an unchangeable task that relies on static variables

Background and Motivation

There are 3 places a task can run in multithreaded mode: in process taskhost, out of process taskhost that remains after build (sidecar), out of process taskhost that dies after build (transient)

• Ease of testing existing tests do complicated setups to get the correct taskhost
• routing tasks that you don't control but are confident they're MT-safe to get pref benefit

Proposed Feature

provide environment variables that override routing decision by engine:
(there is precedent with env var MSBUILDFORCEALLTASKSOUTOFPROC)

MSBUILDFORCETASKSINPROCHOSTLIST="Fullname.T1,Fullnamespace.T2"
MSBUILDFORCETASKSTRANSIENTHOSTLIST="Fullname.T1,Fullnamespace.T2"
MSBUILDFORCETASKSSIDECARHOSTLIST="Fullname.T1,Fullnamespace.T2"

Alternative Designs

No response

[jankratochvilcz]

Quick note - we agree with problem statement, we need a bit more design

[jankratochvilcz]

Grooming notes (2026-05-13)

Outcome: needs more design before implementation. Not ready for external dogfooding as proposed.

Discussion summary

• The motivating scenario is real: today the only way to keep a task that isn't multithread-safe out of the multithreaded path is the hard-coded engine list (used for Restore). If other tasks turn out to need the same treatment, customers currently have no escape hatch short of an engine release.
• Open question is whether we expect more such tasks. Restore's execution constraints (first node, lifetime, caching) are unusual; we don't have a known second case today, but we also don't have a list.
• Preferred direction is XML, not environment variables. Adding metadata on UsingTask (analogous to existing Runtime/Architecture) and leveraging the override-UsingTask mechanism lets a build engineer pin a specific task to in-proc / sidecar / transient without touching the engine. This matches the precedent set when we shipped override UsingTask after the VS 64-bit move surfaced x86-only tasks in third-party packages.
• Persona is the build/repo engineer, not the end developer. The reasoning required ("is this task safe in-proc?", "does it tolerate a transient host?") is too specialized for general consumers, which argues against an env-var-only surface that's easy to copy/paste without understanding.

Follow-ups before this can move

1. Sketch the UsingTask metadata design (attribute names, allowed values, interaction with override UsingTask, precedence vs. engine routing).
2. Decide whether env vars are still useful as a debugging/testing convenience alongside the XML knob, or whether XML is sufficient.
3. Reassess priority once we know whether we want to expose this externally for the multithreading public preview.