Azure DevOps: Azure Functions Core Tools Can't Find .NET 10 Installed by UseDotNet@2 Task on Windows Agents

[jaliyaudagedara]

Version

I was upgrading an Azure Durable Function Application from .NET 9 to .NET 10. Our Azure DevOps pipeline have a job that executes set of integration tests by spinning up the function using func. Since we were using MSSQLLocalDB, the agent is Windows.

After the upgrade, the integration tests was failing to spin up func with a frustrating error.

You must install or update .NET to run this application.
App: D:\a\1\s\tests\...\bin\Debug\net10.0\FunctionApp.dll
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '10.0.0' (x64)
.NET location: C:\Program Files\dotnet\
The following frameworks were found:
  8.0.6 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  8.0.21 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  9.0.6 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  9.0.10 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
 
Learn more:
https://aka.ms/dotnet/app-launch-failed
To install missing framework, download:

Description

Install func

- bash: |
    npm i -g azure-functions-core-tools@4 --unsafe-perm true
  displayName: Install Azure Func Core Tools

Installed version: Core Tools Version: 4.4.1+e4b8a4bdc8fd3b73143908be867f029865b74647 (64-bit)

The pipeline uses the UseDotNet@2 task to install .NET 10.

- task: UseDotNet@2
  displayName: Install .NET 10.0.x
  inputs:
    packageType: 'sdk'
    version: '10.0.x'

The pipeline debug logs showed UseDotNet@2 task was setting DOTNET_ROOT and updating PATH correctly:

##[debug]Absolute path for pathSegments: C:\hostedtoolcache\windows\dotnet\sdk
Successfully installed .NET Core sdk version 10.0.100.
##[debug]Processed: ##vso[task.prependpath]C:\hostedtoolcache\windows/dotnet
##[debug]set DOTNET_ROOT=C:\hostedtoolcache\windows/dotnet

And dotnet --info confirmed .NET 10 was installed.

However func.exe doesn't seem to recognize it, it kept looking at C:\Program Files\dotnet.
When starting the worker process, it ignores:

• The DOTNET_ROOT environment variable
• The PATH environment variable

Since .NET 10 isn't yet pre-installed on DevOps agents, Azure Functions can't find it.

Shouldn't func consider DOTNET_ROOT or PATH to determine dotnet?

Workaround:

When installing .NET 10, override the default installation path which is $(Agent.ToolsDirectory)/dotnet (C:\hostedtoolcache\windows\dotnet in Windows) to C:\Program Files\dotnet where Azure Functions expects to find it.

- task: UseDotNet@2
  displayName: Install .NET 10.0.x
  inputs:
    packageType: 'sdk'
    version: '10.0.x'
    installationPath: 'C:\Program Files\dotnet'

Steps to reproduce

• Spin up a .NET 10 function app using func in an Azure DevOps Pipeline that runs on windows-latest
• Install .NET SDK

- task: UseDotNet@2
  displayName: Install .NET 10.0.x
  inputs:
    packageType: 'sdk'
    version: '10.0.x'

[GABRIELNGBTUC]

I believe the underlying problem is the same issue as this #3285.

Dotnet is installed in multiple paths, but the tool will only try one of them (usually the first one in the PATH or in the default installation location).

[Frulfump]

What is the reason for using the Core Tools in a pipeline? I thought it was only intended for local dev use.

[liliankasem]

I believe the underlying problem is the same issue as this #3285.

Dotnet is installed in multiple paths, but the tool will only try one of them (usually the first one in the PATH or in the default installation location).

Yeah this is the real issue here, this should be easy to fix - we can utilize a similar approach to the dotnet sdk to resolve if dotnet exits

[GABRIELNGBTUC]

@liliankasem I don't think the following PR fixes this issue #4732.

I tried running the main branch on my machine with two dotnet executables installed:

1. One managed by my org in the default installation directory
2. One managed by me in a non-privileged installation path that was added to the user $env:PATH

While the muxer function recovers the path of the dotnet executable I want to use (the one in the user $env:PATH), the CLI methods still use the one in the default installation directory.

I believe this is because all instances of new Executable("dotnet", ... were not replaced by new Executable(DotnetMuxer.GetMuxerPath(), .... So theexecutable used ends up being different than the one found by the Muxer function.

Furthermore, after doing this adjustment myself, I am still unable to start dotnet-isolated functions due to the same issue of the wrong dotnet executable being used. I assume this is because the dotnet-isolated worker should also use Muxer to find the dotnet cli location? So if you could redirect me to the correct repository to ask for this change, it would be great.

Language Worker Process exited. Pid=26128.
C:\Program Files\dotnet\dotnet.exe exited with code -2147450730 (0x80008096). https://aka.ms/dotnet/app-launch-failed.

[liliankasem]

@GABRIELNGBTUC do you face the same issues from this branch "#4738" ? I forgot to have PATH search fallback which is what the PR is bringing in

[GABRIELNGBTUC]

@liliankasem I still have the issue using that branch.

D:/Users/User/RiderProjects/azure-functions-core-tools/out/bin/Azure.Functions.Cli/debug/func.exe start
'local.settings.json' found in root directory (D:\Users\User\RiderProjects\Project\Project\Project).
Resolving worker runtime to 'dotnet-isolated'.
Microsoft (R) Build Engine version 17.1.0+ae57d105c for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
C:\Program Files\dotnet\sdk\6.0.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(144,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 10.0.  Either target .NET 6.0 or lower, or use a version of the .NET SDK that supports .NET 10.0.

I noticed that in my previous test I had the env variable "DOTNET_HOME" so I removed it and retried the test with the above result.

This is my current situation:

• 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 "Update DotnetMuxer to also check PATH #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.

[liliankasem]

Okay I think this is a different feature request, the fix for this right now is to make sure it's checking for a dotnet installation in other places besides PATH, but you're asking to be able to choose which dotnet installation to use which is not something we currently support. Can you open a new issue for this feature request? Thanks!

[GABRIELNGBTUC]

I have created a new issue but I still don't understand why the new Executable("dotnet", ... weren't changed to use the path found by Muxer.

Let's assume DOTNET_ROOT to C:/LocationToDotnetCLI is set but PATH does not contain C:/LocationToDotnetCLI. Which could happen in a misconfiguration of the environment variables by the user after using the dotnet-install scripts.

From my understanding, the Azure Function CLI would accept that a dotnet CLI is installed on the machine and proceed with whatever command it was asked to do. Then when trying to run dotnet, the command would fail because no entry in the PATH contains a dotnet executable.

[supertopi]

What is the reason for using the Core Tools in a pipeline? I thought it was only intended for local dev use.

One example is running the function app to generate a swagger file (through API endpoint) to the build artifact.