Isolate MSBuildTaskHost from the rest of MSBuild Codebase

[DustinCampbell]

Summary

MSBuildTaskHost.exe provides legacy support for running .NET Framework 3.5 tasks. It is itself a .NET Framework 3.5 application and loads the Microsoft.Build.* 3.5.0.0 assemblies from the GAC when .NET 3.5 is installed. Today, common targets force three .NET 3.5 tasks to run in MSBuildTaskHost: RegisterAssembly, UnregisterAssembly, and especially, GenerateResource. For .NET 3.5 builds, it is essentially that the 3.5 version of GenerateResource runs, since the BinaryFormatter output format changed between CLR 2.0 and CLR 4.0.

For more than 15 years, MSBuildTaskHost has been compiled from the same shared source files as the rest of MSBuild. This made sense in the .NET Framework 4.0 era, when the delta between 3.5 and 4.0 was small. But as MSBuild has evolved, this arrangement has become increasingly restrictive. Any shared code that uses modern .NET features (Span<T>, Task<T>, immutable collections, etc.) becomes problematic because MSBuildTaskHost cannot consume them. Shared code changes also risk breaking MSBuildTaskHost and, by extension, the ability to build legacy .NET 3.5 projects.

This PR isolates MSBuildTaskHost into its own self‑contained codebase, decoupled from the rest of MSBuild.

Approach

The isolation work follows these steps:

1. Copy all shared files into MSBuildTaskHost.
2. Remove conditional compilation constants from MSBuildTaskHost’s sources:
   • Dead code paths, including those under NET, RUNTIME_TYPE_NETCORE, or FEATURE_* flags irrelevant to .NET 3.5 (e.g., FEATURE_VISUALSTUDIOSETUP).
   • Always‑true code paths, such as those under CLR2COMPATIBILITY or FEATURE_ASSEMBLY_LOCATION.
3. Remove OS/architecture‑specific code that MSBuildTaskHost does not support (i.e., anything outside Windows/x86/x64).
4. Remove uncalled members and unused types.
5. Remove MSBuild public API types that were added solely to make MSBuildTaskHost compile but do not exist in Microsoft.Build.Framework 3.5.0.0 (e.g., IBuildEngine3, ITaskItem2, RunInSTAAttribute).
6. Clean up each file to reflect its new, isolated context.

Additional Changes Outside MSBuildTaskHost

Refactor handshake components to make the tools directory path deterministic by using the MSBuildTaskHost.exe directory when computing handshake salt. (22fb64e)
Add a test that verifies building a .NET 3.5 WinForms application on Windows/.NET Framework when .NET 3.5 is installed. (9941c15)

Next Steps

Remove dead code paths from all shared MSBuild files now that .NET 3.5 compatibility is no longer required. (In progress)
Audit conditional compilation constants across MSBuild. (In progress)
Move remaining shared code into a dedicated shared binary (Microsoft.Build.Framework). (Requires reworking how string resources are consumed across MSBuild binaries.)

Future Work

Refactor task host communication to introduce a “protocol adapter” layer. Now that MSBuildTaskHost is effectively frozen in time, this adapter would shield it from future protocol changes while allowing MSBuild to evolve independently.

[SimaTian]

review progress:
~110/141 (commit 5487183)
let me correct myself. This PR is amazing and I'm sad I'm almost half done. I want more.

[SimaTian]

MSBuildTaskHost doesn't get much benefit from MSBuildNameIgnoreCaseComparer over using StringComparer.OrdinalIgnoreCase. So, this change removes MSBuildNameIgnoreCaseComparer.cs and IConstrainedEqualityComparer.cs from MSBuildTaskHost rather than include the extra complexity.

I'm not disputing this claim but I would love to know a bit more about the reasoning.
(or if we have some sort of benchmark data for this, even better)

is there some difference in the assumptions for the TaskHost as opposed to general MSBuild environment?
is it that we don't care about TaskHost performance since it's legacy support only and so it's "almost deprecated" and so maintainability has high enough priority?
or something else entirely?

[SimaTian]

The only bits left in XMakeAttributes are for checking MSBuild's architecture and runtime. This change formalizes that and removes XMakeAttributes.cs.

I love this. This genuinely made me laugh.
First we gut XMakeAttributes few commits ago and then we revisit, notice it is mostly hollow and kill it altogether. Yessssss.

[SimaTian]

Note that "node reuse" is always false in MSBuildTaskHost
Similar confusion about our TaskHost naming as before. Maybe we should make the naming more explicit and rename this one as a "OldTaskHost" or something?
Because sidecar taskshost (and by extension the other taskhost that is different from this one) I was working on before was definitely handling node reuse.

[rainersigwald]

commit 73e68d4: MSBuildTaskHost can only ever run on Windows. So, runtime checks for the OS platform can be completely removed.

I'm mildly confused here - part of my MSBuild mental model is most likely wrong. If taskhost doesn't run on non-windows OS, where do we kick thread-unsafe tasks in the case of Multithreaded build on *nix machines?

It could be as simple as "we have a naming overload and there are more kinds of task host around" but I never updated my model explicitly for this piece of information. Or are *nix machines to be served only by the NET taskhost?

MSBuildTaskHost.exe, the net35 taskhost, runs only on Windows (where we can have .NET Framework 3.5 installed). TaskHosts for the .NET (core) runtime can run anywhere we do.

This naming is a bit unfortunate but it's what has been used since .NET Framework 4.0 so IMO it's too late to change.

[DustinCampbell]

@SimaTian

MSBuildTaskHost doesn't get much benefit from MSBuildNameIgnoreCaseComparer over using StringComparer.OrdinalIgnoreCase. So, this change removes MSBuildNameIgnoreCaseComparer.cs and IConstrainedEqualityComparer.cs from MSBuildTaskHost rather than include the extra complexity.

I'm not disputing this claim but I would love to know a bit more about the reasoning. (or if we have some sort of benchmark data for this, even better)

is there some difference in the assumptions for the TaskHost as opposed to general MSBuild environment? is it that we don't care about TaskHost performance since it's legacy support only and so it's "almost deprecated" and so maintainability has high enough priority? or something else entirely?

As @rainersigwald mentioned, "MSBuildTaskHost.exe" only runs on Windows on .NET Framework 3.5. It's a special task host for running tasks targeting .NET 3.5 and doesn't use current versions of the other MSBuild binaries. In fact, the only MSBuild binary that it references is "Microsoft.Build.Framework, 3.5.0.0" which gets loaded from the GAC. "MSBuildTaskHost" is always launched with "nodereuse:false", so it's effectively launched for every .NET 3.5 task that's encountered. In practice, that's typically just the .NET 3.5 version of the GenerateResource task, which is legacy and doesn't build out of this repo.

As for whether MSBuildNameIgnoreCaseComparer has impact in "MSBuildTaskHost.exe", I think it's safe to say that the impact is negligible if it has any noticeable impact at all. It is only used for metadata on TaskParameters that are themselves ITaskItems. Given that just one task runs, I doubt there is enough lookup on these small metadata collections to warrant pulling all of this code into "MSBuildTaskHost.exe", especially since it's a 15-year-old legacy component.

[rainersigwald]

In general I want MSBuildTaskhost.exe to "keep working". I don't expect much need to invest in its performance.

[SimaTian]

Awesome PR. I'm all for it. This solves so many pain points.
Thank you.

[SimaTian]

I've read it as closely as I could, with the caveat that started skimming somewhere around the last 30 or so commits.
Given the scale, I was somewhat annoyed with the GH marks diffs - many of the changes are just code moves / indentation changes, but they are marked as whole code blocks being deleted and created anew, which made reading somewhat complicated.
All in all I do believe in this PR.