Unable to run Azure Functions Core Tools on Azure DevOps with .NET 10

[yijielee]

I have an issue when trying to run the Azure Functions Core Tools on Azure DevOps. It seems to be unable to start. I have a fairly basic YAML file for a pipeline to recreate.

pool:
  vmImage: "windows-latest"

jobs:
  - job: dotnet10
    steps:
      - script: |
          dotnet --list-sdks
          dotnet --list-runtimes
        displayName: 'List .NET stuff'

      - task: FuncToolsInstaller@0
        displayName: "Install Azure Functions Core Tools"

      - script: |
          func init MyFunctionProj10 --worker-runtime dotnet-isolated --target-framework net10.0
          cd MyFunctionProj10
          func new --template "Http Trigger" --name MyHttpTrigger
          func start --verbose
        displayName: 'Function Project .NET 10'
        timeoutInMinutes: 5

The logs for the script task when calling the Azure Functions Core Tools can be found in 8.txt.

I didn't seem to have the same issue when I changed the target framework to net9.0 or net8.0. I also didn't have any issues when running the same commands targetting net10.0 locally on my PC.

I'm also wary that there might be something not right with the Azure DevOps FuncToolsInstaller@0 task or the Microsoft-hosted agent based on it trying to look for x86 but I thought I would start here to begin with.

Any help would be appreciated. Thanks!

[liliankasem]

The logs show that it is not able to find .NET 10 on the machine:

2025-12-15T05:22:21.5698356Z [2025-12-15T05:22:21.569Z] You must install or update .NET to run this application.
2025-12-15T05:22:21.5701583Z [2025-12-15T05:22:21.569Z] App: D:\a\1\s\MyFunctionProj10\bin\output\MyFunctionProj10.dll
2025-12-15T05:22:21.5703125Z [2025-12-15T05:22:21.570Z] Architecture: x86
2025-12-15T05:22:21.5705439Z [2025-12-15T05:22:21.570Z] Framework: 'Microsoft.NETCore.App', version '10.0.0' (x86)
2025-12-15T05:22:21.5707662Z [2025-12-15T05:22:21.570Z] .NET location: C:\Program Files (x86)\dotnet\
2025-12-15T05:22:21.5709927Z [2025-12-15T05:22:21.570Z] The following frameworks were found:
2025-12-15T05:22:21.5711887Z [2025-12-15T05:22:21.570Z]   8.0.22 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
2025-12-15T05:22:21.5714228Z [2025-12-15T05:22:21.571Z]   9.0.11 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
2025-12-15T05:22:21.5716016Z [2025-12-15T05:22:21.571Z] Learn more:

What's the output of the "List .NET stuff" task?

If you try using npm or another installer, do you have the same issue?

[yijielee]

Thanks for the suggestions 😄

List .NET stuff task output

Running this today, the output was:

2026-01-05T23:14:05.4663377Z 8.0.122 [C:\Program Files\dotnet\sdk]
2026-01-05T23:14:05.4664887Z 8.0.206 [C:\Program Files\dotnet\sdk]
2026-01-05T23:14:05.4665935Z 8.0.319 [C:\Program Files\dotnet\sdk]
2026-01-05T23:14:05.4666945Z 8.0.416 [C:\Program Files\dotnet\sdk]
2026-01-05T23:14:05.4668997Z 9.0.112 [C:\Program Files\dotnet\sdk]
2026-01-05T23:14:05.4676964Z 9.0.205 [C:\Program Files\dotnet\sdk]
2026-01-05T23:14:05.4684308Z 9.0.308 [C:\Program Files\dotnet\sdk]
2026-01-05T23:14:05.4688528Z 10.0.101 [C:\Program Files\dotnet\sdk]
2026-01-05T23:14:05.7023009Z Microsoft.AspNetCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
2026-01-05T23:14:05.7024562Z Microsoft.AspNetCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
2026-01-05T23:14:05.7025770Z Microsoft.AspNetCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
2026-01-05T23:14:05.7028055Z Microsoft.AspNetCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
2026-01-05T23:14:05.7031354Z Microsoft.AspNetCore.App 10.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
2026-01-05T23:14:05.7034104Z Microsoft.NETCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
2026-01-05T23:14:05.7035289Z Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
2026-01-05T23:14:05.7036311Z Microsoft.NETCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
2026-01-05T23:14:05.7037253Z Microsoft.NETCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
2026-01-05T23:14:05.7038366Z Microsoft.NETCore.App 10.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
2026-01-05T23:14:05.7042528Z Microsoft.WindowsDesktop.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
2026-01-05T23:14:05.7046367Z Microsoft.WindowsDesktop.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
2026-01-05T23:14:05.7047698Z Microsoft.WindowsDesktop.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
2026-01-05T23:14:05.7049110Z Microsoft.WindowsDesktop.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
2026-01-05T23:14:05.7050516Z Microsoft.WindowsDesktop.App 10.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

The raw log with diagnostics can be found here: 6.txt

Other installers

It looks to have worked with installing the tools via npm and choco. I can provide the pipeline YAML I used and the resulting logs if required.

[liliankasem]

It looks to have worked with installing the tools via npm and choco

Then yeah I think your theory here is correct, it's likely FuncToolsInstaller is installing x86 - I don't know who owns that tool or if you can set a task option to specifiy x64 install?

[yijielee]

Unfortunately, there's nothing in the documentation about forcing it to install x64. I did manage to find microsoft/azure-pipelines-tasks#20376 but there's no indication whether it will be actioned or not.

This did lead me to test the original YAML I had posted but with .NET 8 and 9 instead and it seemed to work.

YAML pipeline with .NET 8

pool:
  vmImage: "windows-latest"

jobs:
  - job: dotnet8
    steps:
      - script: |
          dotnet --list-sdks
          dotnet --list-runtimes
        displayName: 'List .NET stuff'

      - task: FuncToolsInstaller@0
        displayName: "Install Azure Functions Core Tools"

      - script: |
          func init MyFunctionProj8 --worker-runtime dotnet-isolated --target-framework net8.0
          cd MyFunctionProj8
          func new --template "Http Trigger" --name MyHttpTrigger
          func start --verbose
        displayName: 'Function Project .NET 8'
        timeoutInMinutes: 5

YAML pipeline with .NET 9

pool:
  vmImage: "windows-latest"

jobs:
  - job: dotnet9
    steps:
      - script: |
          dotnet --list-sdks
          dotnet --list-runtimes
        displayName: 'List .NET stuff'

      - task: FuncToolsInstaller@0
        displayName: "Install Azure Functions Core Tools"

      - script: |
          func init MyFunctionProj9 --worker-runtime dotnet-isolated --target-framework net9.0
          cd MyFunctionProj9
          func new --template "Http Trigger" --name MyHttpTrigger
          func start --verbose
        displayName: 'Function Project .NET 9'
        timeoutInMinutes: 5

Based on FuncToolsInstaller task code on how it chooses to download the Azure Functions Core Tools on a Windows-based runner it is picking the x86 artifact. Is there any reason why it would work with .NET 8 and 9 but not 10?

[liliankasem]

@yijielee can you share the script task logs for those runs?

[yijielee]

• dotnet8.txt
• dotnet9.txt

[liliankasem]

The .NET 8 and .NET 9 apps working makes sense, we can see in the logs that it is able to find those dotnet installs at C:\Program Files (x86)\dotnet

2025-12-15T05:22:21.5709927Z [2025-12-15T05:22:21.570Z] The following frameworks were found:
2025-12-15T05:22:21.5711887Z [2025-12-15T05:22:21.570Z]   8.0.22 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
2025-12-15T05:22:21.5714228Z [2025-12-15T05:22:21.571Z]   9.0.11 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]

It's still not able to find a .NET 10 x86 install which remains the issue - so perhaps its just not installed in the ADO environment by default? If you install .NET 10 x86 manually, it should work - I just tested this myself using your pipeline sample with that additional step:

pool:
  vmImage: "windows-latest"

jobs:
  - job: dotnet10
    steps:
      - task: FuncToolsInstaller@0
        displayName: "Install Azure Functions Core Tools"

      - pwsh: |
          $dotnetVersion = "10.0.101"
          $installDir = "C:\Program Files (x86)\dotnet"
          $downloadUrl = "https://builds.dotnet.microsoft.com/dotnet/Sdk/$dotnetVersion/dotnet-sdk-$dotnetVersion-win-x86.zip"
          $zipPath = "$env:TEMP\dotnet-sdk-x86.zip"
          
          Write-Host "Downloading .NET SDK $dotnetVersion (x86)..."
          Invoke-WebRequest -Uri $downloadUrl -OutFile $zipPath
          
          Write-Host "Extracting .NET SDK to: $installDir"
          Expand-Archive -Path $zipPath -DestinationPath $installDir -Force
          
          Write-Host "`nSetting DOTNET_ROOT and PATH..."
          Write-Host "##vso[task.setvariable variable=DOTNET_ROOT]$installDir"
          Write-Host "##vso[task.prependpath]$installDir"
          
          Write-Host ".NET SDK x86 installed successfully"
        displayName: 'Install .NET 10 SDK (x86)'

      - script: |
          func init MyFunctionProj10 --worker-runtime dotnet-isolated --target-framework net10.0
          cd MyFunctionProj10
          func new --template "Http Trigger" --name MyHttpTrigger
          func start --verbose
        displayName: 'Function Project .NET 10'
        timeoutInMinutes: 5

So your options to resolve:

1. If you want to keep using FuncToolsInstaller, you will need to add a task to install .NET 10 x86 manually
2. If you're not attached to FuncToolsInstaller, you can use npm or another installer to download the x64 bit version of the CLI

I did manage to find microsoft/azure-pipelines-tasks#20376 but there's no indication whether it will be actioned or not.

I threw in a PR for this to make x64 the default, but not sure if we will have any luck getting it in: microsoft/azure-pipelines-tasks#21685

In any case, I don't think there are any issues with the CLI itself.

[yijielee]

Thanks @liliankasem for the explanation, workarounds and the PR.

I'm happy to close this issue.