dotnet run does not work on Windows when Core Tools are installed from NPM

[DavidZidar]

Description

I just tried to run my isolated function app with dotnet run as it's supposed to be supported since version 2 but I get the following error:

Unhandled exception: System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'func' with working directory 'D:\pathtoproject\bin\debug\net9.0\'. The system cannot find the file specified.
   at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at Microsoft.DotNet.Cli.Utils.Command.Execute(Action`1 processStarted)
   at Microsoft.DotNet.Tools.Run.RunCommand.Execute()
   at System.CommandLine.Invocation.InvocationPipeline.Invoke(ParseResult parseResult)
   at System.CommandLine.ParseResult.Invoke()
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)

It seems that the RunCommand is hardcoded as func here:

azure-functions-dotnet-worker/sdk/Sdk/Targets/Microsoft.Azure.Functions.Worker.Sdk.targets

Line 86 in c4113d1

<RunCommand>func</RunCommand>

It should probably be func.cmd on Windows.

I have reproduced the problem in .NET by running Process.Start("func") which fails similarly while Process.Start("func.cmd") works.

My PATH does contain func, func.ps1 and func.cmd as installed by npm.

Steps to reproduce

npm install -g azure-functions-core-tools@4
dotnet run

[jviau]

@DavidZidar did you restart your terminal after running npm install? It is possible your path was not updated.

[DavidZidar]

I installed the function tools many months ago, so yes. 😄 And yes, they are up to date.

[jviau]

I am unable to reproduce this. On windows, path expansion automatically handles going from {file} to {file}.{exe|bin|cmd}. From a powershell terminal, can you run gcm func. Does it find a command and show the source for it?

[DavidZidar]

Isn't path expansion a feature of the shell? I could be mistaken but I don't think Process.Start has path expansion.

In any case, yes, here is some terminal output:

> Get-Command func

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
ExternalScript  func.ps1                                                      C:\Users\david\scoop\apps\nodejs-lts\curre…

> ls C:\Users\david\scoop\apps\nodejs-lts\current\bin\func*

    Directory: C:\Users\david\scoop\apps\nodejs-lts\current\bin

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          2024-12-01    16:08            445 func
-a---          2024-12-01    16:08            353 func.cmd
-a---          2024-12-01    16:08            917 func.ps1

> $env:PATH -split ';' | rg nodejs-lts
C:\Users\david\scoop\apps\nodejs-lts\current\bin
C:\Users\david\scoop\apps\nodejs-lts\current

> func --version
4.0.6610

I reproduced this on a second machine, exact same behavior.

[DavidZidar]

Like I said I get the same error from .NET. When I try running Process.Start("func") in LINQPad it throws a Win32Exception in just the same way, if I run Process.Start("func.cmd") then it actually runs the command.

[DavidZidar]

Process.Start(new ProcessStartInfo("func") { UseShellExecute = true }) works, apparently UseShellExecute used to be true by default in .NET Framework but in .NET Core it isn't.

[jviau]

@mattchenderson , @fabiocav - this only happens when func tools are installed via NPM as that method does not include a .exe entry point. What is the recommended course of action here?

@DavidZidar if you install via MSI, winget, or chocolatey you should get a func.exe which is compatible with dotnet run.

[DavidZidar]

Oh, interesting, that explains it. I just tried installing it via winget and now it works, thanks! I didn't know it was possible to install the tools without using npm.

[mattchenderson]

Ah, that's an interesting limitation. We'll have to look into that. I can add a specific callout in the documentation to help others with this.

We definitely want this to work with an NPM installation though. We'll keep this item for tracking that. We've been looking at ways to help the tool provide more specifics around acquisition in general, and I think this aligns with that.

[fabiocav]

It's possible this is an issue with the MSBuild logic handling this. We'll follow up and provide an update.