Add default fallback TaskEnvironment to all IMultiThreadableTask implementations

[JanProvaznik]

fixes #13374

Summary

All 19 built-in tasks implementing \IMultiThreadableTask\ now initialize their \TaskEnvironment\ property with a \MultiProcessTaskEnvironmentDriver-backed default. This prevents \NullReferenceException\ when tasks are:

• Explicitly instantiated (e.g.
  ew Copy()) outside the engine
• Run in the out-of-proc task host via \TaskHostFactory\

The engine's in-proc path overwrites this default in \TaskExecutionHost.InitializeForBatch(), so it is purely a safety net.

Changes

• 19 task files: Changed \TaskEnvironment { get; set; }\ → \TaskEnvironment { get; set; } = new TaskEnvironment(MultiProcessTaskEnvironmentDriver.Instance);\
• New test file: \TaskHost_MultiThreadableTask_Tests.cs\ with 2 tests validating both explicit instantiation and task host scenarios via inheritance from \MakeDir\

Testing

• Both new tests pass (RED→GREEN TDD)
• 7/7 \TaskRouter_IntegrationTests\ pass (no regressions)
• 84/84 \TaskExecutionHost_Tests\ pass (no regressions)

[Copilot]

Pull request overview

This PR adds a defensive default TaskEnvironment initialization to all built-in tasks that implement IMultiThreadableTask, preventing NullReferenceException when such tasks are instantiated outside the engine or executed in the out-of-proc task host.

Changes:

• Initialize TaskEnvironment to a MultiProcessTaskEnvironmentDriver-backed default across 19 built-in IMultiThreadableTask implementations.
• Add unit tests validating TaskEnvironment is non-null/usable for explicit instantiation and TaskHostFactory execution.

Reviewed changes

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

Show a summary per file

File	Description
src/Tasks/ZipDirectory.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/XslTransformation.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/XmlPoke.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/XmlPeek.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/WriteCodeFragment.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/Unzip.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/Touch.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/RemoveDir.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/Move.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/MakeDir.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/ListOperators/FindUnderPath.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/FileIO/WriteLinesToFile.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/FileIO/VerifyFileHash.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/FileIO/ReadLinesFromFile.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/FileIO/GetFileHash.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/DownloadFile.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/Delete.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/Copy.cs	Initialize TaskEnvironment with a default fallback instance.
src/Tasks/AssignTargetPath.cs	Initialize TaskEnvironment with a default fallback instance.
src/Build.UnitTests/BackEnd/TaskHost_MultiThreadableTask_Tests.cs	Add tests validating TaskEnvironment fallback works for explicit instantiation and TaskHostFactory execution.

---

You can also share your feedback on Copilot code review. Take the survey.

[ViktorHofer]

Doesn't that imply that every task that implements the interface should now do this? Means customer tasks would need to do this as well. Why can't we provide this by default when instantiating the task?

[JanProvaznik]

Yes it implies that.
For NET10 it could work by having a default value on the interface, however we also target net472 where that's not possible.

We can't provide it by default because the problematic case is where customers instantiate it themselves.
(and since they can inherit our task with the new interface, that new requirement would be a breaking change)

[ViktorHofer]

Yes it implies that.

Sad panda face :( Did we ever require such a thing in the past from task authors?

Is the fundamental problem here that the property on the already shipped interface has a setter and so customers can mutate it?

[JanProvaznik]

Did we ever require such a thing in the past from task authors?

we don't have other capability extending interfaces for Tasks so this is new. It modifies our ask from task authors "if you want your task to be multithreadable you should not only implement the interface but also set the default to multiproc"

Is the fundamental problem here that the property on the already shipped interface has a setter and so customers can mutate it?

No, the problem is that the internals of our tasks can't work without the environment. It's our recommended migration path is to replace cwd-based calls by our APIs, and those can't work without the environment.
It blows up when a 2nd order task author decides to directly instantiate an IMultithreadable task in their task that is naive about TaskEnvironments so it can't pass though it's own (and would be a breaking chage to require it). Tthis happened in VMR for Exec

[ViktorHofer]

@rainersigwald & @baronfel I would love to hear your opinion on this. I'm not happy with this API shape honestly but sounds like there isn't a better option.