Thread-Safe Tasks spec

[AR-May]

Related to #11828.

This spec defines the API contract for the new kind of Task that would be safe to use in multithreaded mode of execution.

[AR-May]

We found probably some better way to deal with file system rather than re-implement it. Re-wrote our concept.

[Copilot]

Pull Request Overview

This PR introduces a comprehensive specification for thread-safe tasks in MSBuild's multithreading execution model. The purpose is to enable tasks to run concurrently within a single MSBuild process while maintaining safety and correctness.

• Defines thread-safe task capabilities through interfaces and attributes
• Introduces TaskEnvironment API for safe access to process-level state
• Provides detailed API analysis for identifying threading issues in existing code

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
thread-safe-tasks.md	Main specification document defining thread-safe task interfaces, TaskEnvironment API, and implementation approaches
thread-safe-tasks-api-analysis.md	Comprehensive reference of .NET APIs that are problematic for thread-safe tasks with recommendations
multithreaded-msbuild.md	Minor correction updating TaskExecutionContext reference to TaskEnvironment

[AraHaan]

I feel like an explicit conversion operator from string -> AbsolutePath would be a good shorthand as well for large codebases.

[AR-May]

We might consider adding it later if the need for this shortcut would appear.This conversion would need to check that the string is indeed already an absolute path, otherwise we do not have enough data to make a conversion. I am afraid it might be still confusing that the conversion may fail if the path is not rooted.

[AraHaan]

I feel like it should also be able to resolve shorthanded paths like ./somefile.txt to it's absolute path as well (by replacing the . in the string with the current directory in the ctor.

[AR-May]

The conversion operator would not have enough context to access correct current directory - so the only way to do that now would be using the TaskEnvironement object created specifically so it has this context and allows the absolute path resolution. Besides, parsing dots in paths feels kind of too hacky to me.

However, MSBuild tasks often work not with stings but with MSBuild items, which should have enough data in many cases, and we might consider having conversion operators for them in version 2.

[baronfel]

Approving so we can get this merged - we can always revise it as we go through implementation.

[AR-May]

Merged the PR as we are feeling pretty good about the decisions made for this spec.
Feel free to open issues / discussions or still ping me here if you need to discuss this spec.