dotnet / dotnet/msbuild

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

Open
#12,895 0 comments 1 reaction 0 assignees View on GitHub
Area: Engine Area: TaskHost backlog Priority:2 triaged
Dominant language
C#
Stars
5.5k
Forks
1.5k
Avg merge
1d 8h
Merged PRs (30d)
141

Description

### 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](https://github.com/dotnet/msbuild/issues/12723) of folks using libraries like GitVersion.MSBuild (which has already [migrated entirely to .NET Tasks](https://github.com/GitTools/GitVersion/blob/main/src/GitVersion.MsBuild/msbuild/tools/GitVersion.MsBuild.targets#L21-L29) 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

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.