Provide a way to prioritize dotnet installations located in user-defined environment variables on Windows

[GABRIELNGBTUC]

Description

• I have a PATH environment variable with the following two entries on Windows:: "C:\Program Files\dotnet;C:\dotnet-SDK ". Where the dotnet cli is installed.
• The first one is managed by IT, set through the system environment variables and the second one is managed by me, a developer, set through the user environment variables
• On the branch "https://github.com/Azure/azure-functions-core-tools/pull/4738", the GetMuxerPath and new Executable("dotnet", ... always return C:\Program Files\dotnet\dotnet

Essentially, what I would like the Azure function CLI (and azure function isolated worker) to do is use C:\dotnet-SDK\dotnet as it is the dotnet CLI that I want to use in my context as a user without privileged rights.

However, because the system environment variables are prepended to the user environment variables, this is an impossible scenario as trying to run dotnet or finding the dotnet CLI with Muxer will always see the system value first.

Ideally, we should be able to pass a switch to the Azure Function CLI to prefer "user" environment variables on Windows for situations where the user has a dotnet directory that they do not control in a system PATH entry and a directory they control in a user PATH entry.

When running the func start command, it would also be great if there was a way to automatically update the "worker.config.json" when using the dotnet cli found in the user environment variables entries. Or at least a reminder to manually update the file in the output folder of the function.

[umangsriv]

Hi @liliankasem , I’ve completed an analysis of this issue and wanted to share the findings for your review.

Core Tools relies on the DotnetMuxer logic from the .NET SDK, which:

• Searches for dotnet.exe based on the OS PATH resolution rules
• Does not distinguish between system PATH and user PATH
• Always selects the first matching entry

Given this, Core Tools is currently behaving as expected on Windows, though it doesn’t provide a mechanism for users to explicitly express their intent when multiple dotnet installations are present.

Proposed Solutions

1. Explicit dotnet override
   Allow users to directly specify the dotnet executable, for example:

   • CLI flag: func start --dotnet-path "C:\dotnet-SDK\dotnet.exe" or
   • Environment variable: AZURE_FUNCTIONS_DOTNET_PATH=C:\dotnet-SDK\dotnet.exe
     This would ensure Core Tools bypasses PATH-based resolution.

2. Prefer user PATH (Windows-only, opt‑in)
   Introduce a switch such as:

   • func start --prefer-user-dotnet

3. Worker config alignment
   When a non-default dotnet is used:

   • Automatically persist the chosen path to worker.config.json, or
   • Provide a clear warning prompting users to update the file to avoid mismatches.

Could you please review these proposed approaches and let me know whether any of them would be suitable for addressing the issue from your perspective? Happy to refine further based on your guidance.