Isolate MSBuildTaskHost from the rest of MSBuild Codebase#13232
Merged
Conversation
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 20, 2026
Closed
This was referenced May 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
MSBuildTaskHost.exeprovides legacy support for running .NET Framework 3.5 tasks. It is itself a .NET Framework 3.5 application and loads theMicrosoft.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 ofGenerateResourceruns, since theBinaryFormatteroutput 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:
NET,RUNTIME_TYPE_NETCORE, orFEATURE_*flags irrelevant to .NET 3.5 (e.g.,FEATURE_VISUALSTUDIOSETUP).CLR2COMPATIBILITYorFEATURE_ASSEMBLY_LOCATION.Microsoft.Build.Framework3.5.0.0 (e.g.,IBuildEngine3,ITaskItem2,RunInSTAAttribute).Additional Changes Outside MSBuildTaskHost
Refactor handshake components to make the tools directory path deterministic by using the
MSBuildTaskHost.exedirectory 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.