Issue Description

In 18.0 we lit up support for Tasks declared with Runtime="NET" - but MSBuild Task Authors bulk-updating their UsingTasks to specify this Runtime may not give good error experiences to end users running those tasks on older VS versions.

Steps to Reproduce

Create a .NET (not Framework) Task with `Runtime="NET" in its UsingTask and attempt to run it from a vs17.14 version of MSBuild.exe.

Expected Behavior

The build (not evaluation) should fail at run-time with a clear error along the lines of:

The Task {TaskName} was specified to load with the .NET Runtime, but this version of MSBuild does not support loading Tasks with that Runtime. To load .NET Tasks, MSBuild.exe 18.0 or Visual Studio 2026 must be used.

Actual Behavior

The build fails at run-time with the following error:

System.AggregateException: One or more errors occurred. ---> Microsoft.Build.Exceptions.BuildAbortedException: Build was canceled.
        MSBuild.exe could not be launched as a child node as it could not be found at the location "C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\MSBuild.dll". If necessary, specify the correct location in the BuildParameters, or with the MSBUILD_EXE_PATH environment variable.
  at Microsoft.Build.BackEnd.NodeLauncher.StartInternal(String msbuildLocation, String commandLineArgs)
  at Microsoft.Build.BackEnd.NodeLauncher.DisableMSBuildServer(Func`1 func)
  at Microsoft.Build.BackEnd.NodeProviderOutOfProcBase.<>c__DisplayClass14_0.<GetNodes>g__StartNewNode|2(Int32 nodeId)
  at Microsoft.Build.BackEnd.NodeProviderOutOfProcBase.<>c__DisplayClass14_0.<GetNodes>b__0(Int32 nodeId)

Analysis

We don't want to fail at evaluation time, because this would break clients pretty badly. Instead, we should fail when trying to execute the mismatched Task. This means I think one of two places:

• task host node creation (NodeProviderOutOfProcBase.AcquireAndSetUpHost), or
• TaskHostTask creation (which internally calls NodeProviderOutOfProcBase.AcquireAndSetUpHost)
  • TaskHostTask's constructor, or
  • AssemblyTaskFactory.CreateTaskInstance

There may be more options, these are just the two that stand out to me.

In any case, we need additional test cases to show the behavior of throwing the new exception when a NET-Runtime Task is loaded from .NET Framework MSBuild. Ideally the tests would show the behavior being triggered both from MSBuild.exe invocations directly and from usage of the MSBuild APIs.

Versions & Configurations

No response