Check for Muxer path relative to base directory

[elinor-fung]

When determining the muxer (dotnet) path, search relative to the app base directory first. In most scenarios, this should correspond to the dotnet.dll directory of <root>/sdk/<version> where the dotnet executable is under <root>. If it doesn't exist, fall back to the existing logic.

With custom SDK search paths in global.json (dotnet/runtime#113512), the running dotnet process may not be the same as that corresponding to the running SDK. This updated logic finds the dotnet corresponding to the running SDK such that it can be properly propagated to anything launched via SDK commands (for example, build).

Part of https://github.com/dotnet/designs/blob/main/proposed/local-sdk-global-json.md.
Contributes to #8254

cc @dotnet/appmodel @jaredpar @rainersigwald

[Copilot]

Pull Request Overview

This PR enhances the muxer path resolution logic by first checking a directory relative to the app base directory before falling back to the existing best-effort search.

• Introduces a new constructor for Muxer to compute the path based on the app’s base directory.
• Retains fallback logic if the computed muxer path is not found.

Comments suppressed due to low confidence (1)

src/Cli/Microsoft.DotNet.Cli.Utils/Muxer.cs:38

• [nitpick] Consider adding unit tests to validate that the muxer path is correctly determined based on the app base directory across different directory structures and scenarios.

public Muxer()

[elinor-fung]

The sdk-unified-build failure is known/unrelated: #47580 (comment), dotnet/source-build#4952

Can we merge on red?

[richlander]

FYI @dotnet/distro-maintainers

[mateusrodrigues]

Hi folks! On Linux/macOS, there is also a file called /etc/dotnet/install_location that stores the path to a global install of .NET on the machine (see design spec). Should that also be part of the fallback, which currently queries the DOTNET_ROOT environment variable?

[baronfel]

Hi folks! On Linux/macOS, there is also a file called /etc/dotnet/install_location that stores the path to a global install of .NET on the machine (see design spec). Should that also be part of the fallback, which currently queries the DOTNET_ROOT environment variable?

cc @elinor-fung thoughts?

[tmds]

DOTNET_ROOT and install_location are used by framework dependent application hosts to locate the shared runtimes.

This isn't used by the dotnet executable. The shared runtimes are expected to be relative to its location.

DOTNET_ROOT is only used here in this code as a "last resort".