Skip to content

Isolate MSBuildTaskHost from the rest of MSBuild Codebase#13232

Merged
rainersigwald merged 143 commits into
mainfrom
dev/dustinca/isolate-taskhost
Feb 27, 2026
Merged

Isolate MSBuildTaskHost from the rest of MSBuild Codebase#13232
rainersigwald merged 143 commits into
mainfrom
dev/dustinca/isolate-taskhost

Conversation

@DustinCampbell
Copy link
Copy Markdown
Member

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.

Copies all shared files and files linked from other projects directly into MSBuildTaskHost. In addition, all <Compile> items in MSBuildTaskHost.csproj have been updated to point to the new files.
Split the PropertyGroup for $(DefineConstants) into two: one for net3* and one for net4*
This polyfill is unused in MSBuildTaskHost.
Since MSBuildTaskHost only targets .NET 3.5, it does not require conditional compilation for FEATURE_LEGACY_GETCURRENTDIRECTORY. It *always* includes the code path that provides an optimized GetCurrentDirectory on .NET Framework targets earlier than 4.6.2.
Since MSBuildTaskHost only targets .NET 3.5, it does not require conditional compilation for FEATURE_LEGACY_GETFULLPATH. It *always* includes the code path that provides an optimized GetFullPath on .NET Framework targets earlier than 4.6.2.
Since MSBuildTaskHost only targets .NET 3.5, System.Reflection.Assembly.Location is always available.
The FEATURE_CULTUREINFO_GETCULTURES code path is unused by MSBuildTaskHost.
The FEATURE_APM code path is always used by MSBuildTaskHost. .NET Framework 3.5 does support System.Threading.Tasks, so MSBuildTaskHost uses the older "asynchronous programming model (APM)".
…Host

Many of the FEATURE_* conditional compilation constants defined for .NET 3.5 builds never appear in code compiled within MSBuildTaskHost. This change removes all of those for .NET 3.5 builds.
The FEATURE_PIPE_SECURITY and FEATURE_NAMED_PIPE_SECURITY_CONSTRUCTOR code paths is always used by MSBuildTaskHost.
The FEATURE_SECURITY_PERMISSIONS code paths are always available in MSBuildTaskHost.
The FEATURE_SECURITY_PRINCIPAL_WINDOWS code paths are always available in MSBuildTaskHost.
The FEATURE_THREAD_ABORT code paths are always available in MSBuildTaskHost.
The FEATURE_VISUALSTUDIOSETUP code paths are never available in MSBuildTaskHost. This constant is always removed from .NET 3.5 builds.
The FeatureAppDomain, FeatureSystemConfiguration, and FeatureXamlTypes properties are not used in .NET 3.5 builds.

NOTE: It seems that FeatureAppDomain is the only one of these properties that are used anywhere. However, it is used in a target in Microsoft.Build, which is not built for .NET 3.5.
The FEATURE_REPORTFILEACCESSES code paths are not available in MSBuildTaskHost. This constant was never included in .NET 3.5 builds.
BuildEnvironmentHelper includes a check for AppContext.BaseDirectory that is always returns null on .NET 3.5 and the MSBuildTaskHost. This change removes that check and related code.
VisualStudioLocationHelper.GetInstances() always returns an empty list on .NET 3.5. So, BuildEnvironmentHelper.TryFromSetupApi (the only caller) can be removed from MSBuildTaskHost along with all of VisualStuiodLocationHelper.
RUNTIME_TYPE_NETCORE code paths aren't ever compiled in .NET 3.5 builds.
CopyOnWriteDictionary, ReadOnlyEmptyCollection, and ReadOnlyEmptyDictionary are never used in MSBuildTaskHost and can be safely removed.
Since MSBuildTaskHost only builds for .NET 3.5, there are many code blocks specific to other .NET versions that can be removed.

NOTE: Disabled code blocks were intentionally NOT removed from polyfill types.
BUILDINGAPPXTASKS is not relevant when building MSBuildTaskHost, so code compiled with BUILDINGAPPXTASKS can be removed.
MSBuildTaskHost is always compiled with CLR2COMPATIBILITY, so code blocks that aren't compiled with that conditional compilation constant can be removed.
MSBuildTaskHost is always compiled with TASKHOST. So, code blocks disabled when compiled with TASKHOST can be removed.
MSBuildTaskHost is never compiled with FEATURE_ASSEMBLYLOADCONTEXT.
MSBuildTaskHost is never compiled with FEATURE_PIPEOPTIONS_CURRENTUSERONLY. So, code blocks disabled with FEATURE_PIPEOPTIONS_CURRENTUSERONLY can be removed.
MSBuildTaskHost is always compiled with FEATURE_NET35_TASKHOST.
MSBuildTaskHost is always compiled with NO_FRAMEWORK_IVT. So, code blocks disabled under NO_FRAMEWORK_IVT can be removed.
This was referenced May 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants