Multi-target Microsoft.NET.HostModel

[ViktorHofer]

Multi-targeting allows using latest on .NETCoreApp and LKG (toolset) on .NETFramework. Should partially unblock the m-p packages dependency flow in dotnet/sdk: dotnet/sdk#48034

[Copilot]

Copilot reviewed 2 out of 4 changed files in this pull request and generated no comments.

Files not reviewed (2)

• eng/Versions.props: Language not supported
• src/installer/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj: Language not supported

[ericstj]

LGTM

[ViktorHofer]

@elinor-fung @agocke some more context for you. I verified that all consumers of this package (just dotnet/sdk) are targeting the compatible TFMs. The package is non-shipping and just a transport from runtime to sdk - you probably know that.

The problem that I'm working around here is that this library's references needs to be in sync with sdk dependencies as it gets loaded into msbuild. Because we were targeting .NET Standard, the assembly versions didn't match (as we don't rev the assembly version on .NET Standard for System.Memory and others). By targeting runtime TFMs and downgrading the version of dependencies on .NET Framework, we should be better aligned with sdk's references.

[am11]

Nice! AFAICT, only four projects in dotnet org directly reference its package:

# sdk
src/Cli/dotnet/dotnet.csproj:    <TargetFramework>$(SdkTargetFramework)</TargetFramework>
src/Tasks/Microsoft.NET.Build.Tasks/Microsoft.NET.Build.Tasks.csproj:    <TargetFrameworks>$(SdkTargetFramework);net472</TargetFrameworks>
test/Microsoft.NET.ToolPack.Tests/Microsoft.NET.ToolPack.Tests.csproj:    <TargetFramework>$(SdkTargetFramework)</TargetFramework>

# runtime (TestInfraTargetFramework = NetCoreAppToolCurrent)
src/installer/tests/Microsoft.NET.HostModel.Tests/Microsoft.NET.HostModel.Tests.csproj:    <TargetFramework>$(TestInfraTargetFramework)</TargetFramework>

so one net472 and the rest are net8+.
Are there any other direct consumers of this project? (VS etc.)

[agocke]

I can't remember -- what's the reason we need to provide netstandard2.0 surface area for a transport package? When do we need to run on desktop FX?

[elinor-fung]

The build tasks running in VS, I believe.

[ViktorHofer]

I can't remember -- what's the reason we need to provide netstandard2.0 surface area for a transport package? When do we need to run on desktop FX?

The build tasks running in VS, I believe.

We previously provided a netstandard2.0 assembly so that we didn't have to multi-target. These days, when talking to customers we actually recommend to multi-target to reduce the number of external dependencies and for efficiency.

For this library, the netstandard2.0 TFM was chosen for build authoring simplicity.

Are there any other direct consumers of this project? (VS etc.)

No. It's just dotnet/sdk.

[agocke]

LGTM. I can't see any problems with multi-targeting vs netstandard

[carlossanlop]

/ba-g All failures are known. The only other one was a timeout. I'll update the nit and merge right away.