Add MSBuildTask0015: require concrete MSBuild tasks to declare multithreading support

[Copilot]

Context

Once a repo finishes migrating its tasks to [MSBuildMultiThreadableTask], nothing keeps it migrated. TaskRouter.NeedsTaskHostInMultiThreadedMode routes any task lacking the attribute to an out-of-proc TaskHost — no error, no warning, just a slower build. The existing rules either skip unannotated types (scope = multithreadable_only) or only flag unsafe API usage (scope = all), so a new task that happens to touch no banned API is never told to opt in.

MSBuildTask0015 turns that silent regression into a diagnostic.

Renumbered. This rule was originally MSBuildTask0012. #14809 merged first and claimed MSBuildTask0012–MSBuildTask0014, so this branch has been merged with main and the rule moved to MSBuildTask0015. The conflicts were confined to the four shared registration points where both sides appended to the same lists (DiagnosticIds, DiagnosticDescriptors, AnalyzerReleases.Unshipped.md, README.md); both sets of rules are kept, ordered by ID.

Changes Made

New rule (RequireMultiThreadableTaskAnalyzer.cs) — reports non-abstract classes implementing ITask without a directly applied Microsoft.Build.Framework.MSBuildMultiThreadableTaskAttribute. Attribute detection mirrors the engine: matched by namespace + name via GetAttributes() (direct only), honoring Inherited = false. Consequently:

• abstract bases and interfaces are never flagged;
• a concrete leaf deriving from an annotated base is flagged — the silent mistake seen repeatedly in the Arcade migration;
• generated code is excluded; test tasks are left to path-based .editorconfig severity.

Opting in — silent otherwise:

• msbuild_task_analyzer.scope = require_multithreadable, a third value alongside all and multithreadable_only, meaning "analyze all task types and require the attribute";
• or configuring dotnet_diagnostic.MSBuildTask0015.severity (.editorconfig per-file, .globalconfig, ruleset, <WarningsAsErrors>).

Code fix — "Declare multithreading support" adds the attribute, IMultiThreadableTask, and the TaskEnvironment property, falling back to attribute-only when the type already has a conflicting TaskEnvironment member. The other rules then take over on the newly annotated task.

Docs — the rule, and the scope option's three values, in src/TaskAnalyzer/README.md (scope was previously undocumented); a "Keeping a Migrated Repository Migrated" section in the multithreading spec; the AnalyzerReleases.Unshipped.md entry.

Relationship to MSBuildTask0013 (added by #14809) — that rule reports the same missing attribute, but only on the narrower set of tasks that declare IMultiThreadableTask, and it is off by default. MSBuildTask0015 covers every concrete task type, so it subsumes it: a repository that opts into MSBuildTask0015 does not also need to enable MSBuildTask0013. Called out in both the descriptor and the README so the two opt-ins are not enabled redundantly. MSBuildTask0013 remains useful on its own for a codebase that wants the narrower signal without the repo-wide gate.

# one line in a shared .globalconfig protects every consuming repo
msbuild_task_analyzer.scope = require_multithreadable

Testing

24 tests across RequireMultiThreadableTaskAnalyzerTests and RequireMultiThreadableTaskCodeFixProviderTests cover the scope values, each severity-configuration path, the inheritance and abstract-type scoping rules, and the code fix including the conflicting-member fallback. Also verified end to end against a real dotnet build, which is how the severity bug in the notes below surfaced.

Post-merge, the full TaskAnalyzer.Tests suite passes at 290/290, so the rules from #14809 are unaffected.

Notes

Two implementation constraints worth flagging for review:

• The descriptor is isEnabledByDefault: true, with the opt-in enforced in analyzer code. Roslyn filters disabled-by-default descriptors before an analyzer can consult its options, so isEnabledByDefault: false cannot be re-enabled by the scope setting. To keep the cost of this at zero for unmigrated repos, no symbol action is registered at compilation start when nothing opts in.
• dotnet_diagnostic.*.severity never reaches AnalyzerConfigOptions — Roslyn strips it into TreeOptions. The severity opt-in initially looked correct but did nothing in a real build; it now reads Compilation.Options.SyntaxTreeOptionsProvider (plus SpecificDiagnosticOptions for rulesets).

The doc nit in the issue does not apply here: MSBuildTask0006/0007/0008 are already Warning in both this repo's source and AnalyzerReleases.Unshipped.md; the Info severities came from the shipped 18.11.0-1.26420.118 package. Nothing changed.

• Fixes TaskAnalyzer: add an opt-in rule requiring concrete MSBuild tasks to declare multithreading support #14787

[Copilot]

Pull request overview

Adds a new opt-in TaskAuthoring analyzer rule to prevent “silent” multithreading regression by requiring concrete MSBuild tasks to explicitly opt into multithreaded execution via [MSBuildMultiThreadableTask], plus a code fix and accompanying documentation/tests.

Changes:

• Introduces MSBuildTask0012 analyzer (RequireMultiThreadableTaskAnalyzer) with opt-in via msbuild_task_analyzer.scope = require_multithreadable or explicit severity configuration.
• Adds a code fix to apply [MSBuildMultiThreadableTask] and, when safe, implement IMultiThreadableTask and add the TaskEnvironment property.
• Updates docs, release notes, and unit test infrastructure + adds new analyzer/codefix test suites.

Show a summary per file

File	Description
src/TaskAnalyzer/WellKnownTypeNames.cs	Adds constants to support attribute detection by namespace + name.
src/TaskAnalyzer/SharedAnalyzerHelpers.cs	Adds new require_multithreadable scope value and helper option readers.
src/TaskAnalyzer/RequireMultiThreadableTaskAnalyzer.cs	New MSBuildTask0012 analyzer with opt-in gating and per-tree severity support.
src/TaskAnalyzer/RequireMultiThreadableTaskCodeFixProvider.cs	New code fix to declare multithreading support (attribute + optional interface/property).
src/TaskAnalyzer/DiagnosticIds.cs	Adds MSBuildTask0012 ID constant.
src/TaskAnalyzer/DiagnosticDescriptors.cs	Adds MSBuildTask0012 descriptor and includes it in the global descriptor list.
src/TaskAnalyzer/README.md	Documents MSBuildTask0012 and the expanded scope option behavior.
src/TaskAnalyzer/AnalyzerReleases.Unshipped.md	Adds unshipped release entry for MSBuildTask0012.
src/TaskAnalyzer.Tests/TestHelpers.cs	Extends test helpers to run arbitrary analyzers with supplied global options.
src/TaskAnalyzer.Tests/RequireMultiThreadableTaskAnalyzerTests.cs	New analyzer tests covering scope/severity opt-in and inheritance/abstract behavior.
src/TaskAnalyzer.Tests/RequireMultiThreadableTaskCodeFixProviderTests.cs	New code fix tests for the various “safe to implement interface/property” cases.
documentation/specs/multithreading/thread-safe-tasks.md	Documents MSBuildTask0012 as a way to keep migrated repos from regressing.

Review details

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 12/12 changed files
• Comments generated: 2
• Review effort level: Lite

[Copilot]

Review details

Suppressed comments (4)

src/TaskAnalyzer/RequireMultiThreadableTaskCodeFixProvider.cs:85

• The conflict check only enumerates properties. If the task declares a field, event, or method named TaskEnvironment, existingProperty is null and the fixer inserts a property with the same name, producing CS0102 instead of a compiling fix. Inspect all members across the hierarchy and add the interface/property only when there is no conflicting member, while accepting an existing compatible property.

                IPropertySymbol? existingProperty = SharedAnalyzerHelpers.GetPropertiesIncludingBaseTypes(taskType)
                    .FirstOrDefault(property => string.Equals(property.Name, TaskEnvironmentPropertyName, StringComparison.Ordinal));

src/TaskAnalyzer/RequireMultiThreadableTaskAnalyzer.cs:108

• The new TryGetGlobalDiagnosticValue opt-in path is not exercised by the added tests: they cover per-tree .editorconfig and SpecificDiagnosticOptions, but not dotnet_diagnostic.MSBuildTask0015.severity in a .globalconfig. This is the subtle severity path called out in the PR description, so add a .globalconfig severity test to prevent it from silently becoming a no-op again.

            SyntaxTreeOptionsProvider? optionsProvider = compilation.Options.SyntaxTreeOptionsProvider;
            return optionsProvider is not null &&
                optionsProvider.TryGetGlobalDiagnosticValue(DiagnosticIds.RequireMultiThreadableTask, cancellationToken, out severity) &&
                IsEnabled(severity);

src/TaskAnalyzer/README.md:613

• Both new architecture entries identify these components as implementing MSBuildTask0012, but the analyzer and fixer use MSBuildTask0015. Keeping the old number here sends contributors to the wrong rule.

| `RequireMultiThreadableTaskAnalyzer.cs` | Analyzer for MSBuildTask0012 — reports concrete task types that do not declare multithreading support, once the rule is opted into |
| `RequireMultiThreadableTaskCodeFixProvider.cs` | Code fix for MSBuildTask0012 — applies the attribute, implements `IMultiThreadableTask`, and adds the `TaskEnvironment` property |

src/TaskAnalyzer/RequireMultiThreadableTaskCodeFixProvider.cs:113

• A public init accessor has a public SetMethod, but it cannot implement the interface's ordinary set accessor. This predicate therefore adds IMultiThreadableTask to a task with { get; init; } and leaves the fixed document with an interface implementation error. Exclude init-only setters.

            property.SetMethod is { DeclaredAccessibility: Accessibility.Public } &&

• Files reviewed: 17/17 changed files
• Comments generated: 4
• Review effort level: Balanced

[AR-May]

I would push back on having a fix for this error. It does not seem right to me. Adding the attribute is the last step when making a task multithread-safe. If applied without a proper understanding of the task, it can be quite harmful.

[AR-May]

This message misleads - applying the attribute is not the only thing that needs to be done if task does not opt into multithreaded execution.

[AR-May]

I think of scope as defining which tasks are analyzed, so introducing a separate scope value solely to enable one extra rule feels like overkill. My suggestion would be to remove the scope = require_multithreadable opt-in and instead control the rule through its severity configuration.

I think this rule actually can be enabled with scope all as well, since we produce mt related diagnostic for this scope for all tasks.

[AR-May]

nit: something went wrong during a merge.