Create and document the lifetime and correct usage of static members in Tasks

[baronfel]

Summary

When MSBuild Server (and to a lesser degree Multithreaded MSBuild) is enabled, Tasks that depend on static singletons may exhibit behavior that violates some of the invariants of those modes - an example of this is the NuGet PluginManager, or the EnvironmentWrapper, both of which are static singletons that would remain alive for longer durations than expected.

Background and Motivation

These statics can leak data across builds, or simply cache data for a duration not expected by the Task authors, and implicitly violate the lifetime expectations of the MSBuild Server node/Multithreaded build nodes.

Proposed Feature

We need to provide guidance for Task authors about what the proper use of statics is, and how to ensure that these are cleaned up/re-initialized/etc at appropriate lifecycle points for the MSBuild Server/Multithreaded lifecycles.

We also need to expose additional MSBuild flags/properties for:

• is the build multithreaded
• is the build server mode

because in both of these cases, the central scheduler node is also a worker node, so for Tasks like RestoreTask that operate on the central node always, they will persist. To fix this, in either MT or Server, the Task needs a UsingTask change to kick out to a TaskHost.

Alternative Designs

No response

[KalleOlaviNiemitalo]

How about AsyncLocal statics

[baronfel]

AsyncLocal feels like it will be a key part of the answer here for us, but I don't want to zero in on any one solution quite yet.

[baronfel]

We have IBuildEngine4.RegisterTaskObject as a potential solution here as well - this allows registering object with a given lifetime, but I suspect just on a given TaskHost node. Would that be sufficient for Restore's needs?

[baronfel]

One potential workaround: today this is dangerous because Restore executes on the main node (which may be an MSBuild Server) node. If instead we made Restore always kick off to an out of proc node (via TaskFactory) then we'd not have to worry about the lifecycle. This could introduce perf regressions so we should still find a real solution to the underlying problem.

[JanProvaznik]

Cross-referencing the broader MSBuild Server default-on analysis at #9379 (overnight investigation summary).

This issue is Class B (within-workspace state leakage from task statics) — and it's the structural / contract-level companion to PR #13660.

Recent audit highlights:

In-tree (src/Tasks/**):

• AssemblyFoldersExResolver (HIGH) — directory-snapshot cache that can survive BuildCompleteReuse
• GetFrameworkPath.cs (MED) — static Lazy<string> pins SDK path for the server lifetime
• GlobalAssemblyCache.cs (MED) — static readonly GAC root
• Microsoft.Build.Tasks.UnregisterAssembly (REAL constraint) — process-wide mutex around COM unregister; should be on the same allow-list

In-tree engine (server-reuse-impact, beyond tasks):

• BuildManager.ProjectCacheDescriptors + static IDs (HIGH)
• CodeTaskFactory caches + AppDomain resolver hook (HIGH)
• TaskLoader.s_resolverLoadedType + AssemblyResolve/UnhandledException handlers (HIGH — handler accumulation)
• TaskEngineAssemblyResolver._eventHandler (HIGH)

Out-of-tree (top-priority):

• NuGet.Build.Tasks.GetRestoreSettingsTask._machineWideSettings (HIGH) — stale nuget.config after source rotation; mitigatable by adding to PR Workaround: route NuGet RestoreTask to transient TaskHost in server or mt modes #13660's allow-list
• Microsoft.NET.Build.Containers.Tasks.CreateNewImage (HIGH, security-class) — process-wide Environment.SetEnvironmentVariable for credentials in a try/finally; child processes spawned during the window inherit the credential
• Microsoft.DotNet.SdkResolver.NETCoreSdkResolver s_compatibleSdks / s_minimumMSBuildVersions (HIGH) — stale SDK selection if a patch installs while server is running. Important nuance: SDK resolution runs exclusively on the main node (MainNodeSdkResolverService), so this is the first scenario where these caches become hazardous — today's worker-node reuse delegates SDK resolution via IPC to a fresh main-node process per dotnet build, so the static caches simply never accumulate.

The transient-TaskHost routing pattern from PR #13660 is the recommended per-task mitigation while each task awaits a proper lifecycle fix. A first-class IStatefulTask.ResetForReuse() callback (or [MSBuildMainNodeOnly] attribute) would let task authors fix their own breakage without an MSBuild PR per task, but the allow-list mechanism is the right shipping vehicle for .NET 10.0.x.