Enable .NET TaskHost usage for Project types that do not import the base .NET SDK-delivered MSBuild SDK

[baronfel]

Summary

Today, resolution of the .NET version of MSBuild to use as the source of the .NET TaskHost is based on the RuntimeIdentifierGraphPath property - this is an initial implementation that was chosen for ease of use and limited scope.

Now that the feature is stable and has had good user feedback, we should make .NET TaskHost usable by all MSbuild SDKs, not just those that directly Import the 'base' .NET SDK. To do this, we need to either:

• enable other SDK types to easily locate an SDK install and pass that in via Property similarly to how RuntimeIdentifierGraphPath is today
  • we shouldn't do this, it pushes too much responsibility to MSBuild SDK authors, just noting it here as an option
• enable Framework MSBuild to do hostfxr-style SDK resolution on-demand so that it can independently locate versioned SDK installs to then use to locate its expected .NET MSBuild binaries
  • This is the correct path, but it is much more work and would expose Framework MSBuild to potential maintainability issues if we every change the way that hostfxr detects/loads SDKs.
  • Ideally we'd be able to share this logic with features like dotnetup and dotnet CLI AOT so that all of these mechanisms use the same SDK-resolution logic. @ericstj has a prototype managed library that would be ideal for this.
• make the SDKResolver inserted into the Framework MSBuild set a new property that is specifically used for this purpose
  • make it privately-named and DO NOT have the dotnet CLI also set it
  • users that try to use it for their own purposes have no expectation of that value being set, and we explicitly will not support that

In all cases, once we decide on the name, we'd need to update the TaskHost resolution logic for .NET TaskHost to prefer the new name and fall back to the existing property.

Background and Motivation

We've had a few reports of folks using libraries like GitVersion.MSBuild (which has already migrated entirely to .NET Tasks for maintainability reasons) with non-.NET-SDK-based MSBuild SDKs (like Wix, etc) that then fail at runtime due to the lack of the RuntimeIdentifierGraphPath property. To open up the overall ecosystem, we should fill this gap.

Proposed Feature

See above

Alternative Designs

See above