4.0.5530: Could not load file or assembly 'Microsoft.Azure.WebJobs.Script.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c5b9424214e8f8c'. The system cannot find the file specified.

[jaliyaudagedara]

I have just updated Azure Functions Core Tools version in my local machine to the latest (4.0.5530) and now func start is failing.

> func --version
4.0.5530

> func init --worker-runtime dotnet-isolated
Writing C:\Users\Jaliya\Desktop\test-function\.vscode\extensions.json

> func new --template "Http Trigger" --name HttpStart
Template: Http Trigger
Function name: HttpStart

Creating dotnet function...
The function "HttpStart" was created successfully from the "Http Trigger" template.

> func start --verbose
MSBuild version 17.9.4+90725d08d for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  test-function -> C:\Users\Jaliya\Desktop\test-function\bin\output\test-function.dll
  Determining projects to restore...
  Restored C:\Users\Jaliya\AppData\Local\Temp\szmnpezk.rm0\WorkerExtensions.csproj (in 669 ms).
  WorkerExtensions -> C:\Users\Jaliya\AppData\Local\Temp\szmnpezk.rm0\buildout\Microsoft.Azure.Functions.Worker.Extensions.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:03.43



                  %%%%%%
                 %%%%%%
            @   %%%%%%    @
          @@   %%%%%%      @@
       @@@    %%%%%%%%%%%    @@@
     @@      %%%%%%%%%%        @@
       @@         %%%%       @@
         @@      %%%       @@
           @@    %%      @@
                %%
                %


Azure Functions Core Tools
Core Tools Version:       4.0.5530 Commit hash: N/A +c8883e7f3c06e2b424fbac033806c19d8d91418c (64-bit)
Function Runtime Version: 4.28.5.21962

Could not load file or assembly 'Microsoft.Azure.WebJobs.Script.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c5b9424214e8f8c'. The system cannot find the file specified.

However, it runs fine with in Visual Studio:

[jaliyaudagedara]

Downgraded Azure Functions Core Tools back to 4.0.5455, it works.

I am sorry guys, this isn't cool. Lately, there seem to be a lot of breaks.

>  func start
MSBuild version 17.9.4+90725d08d for .NET
  Determining projects to restore...
  Restored C:\Users\Jaliya\Desktop\test-function\test-function.csproj (in 334 ms).
  test-function -> C:\Users\Jaliya\Desktop\test-function\bin\output\test-function.dll
  Determining projects to restore...
  Restored C:\Users\Jaliya\AppData\Local\Temp\crxzujxi.c5l\WorkerExtensions.csproj (in 423 ms).
  WorkerExtensions -> C:\Users\Jaliya\AppData\Local\Temp\crxzujxi.c5l\buildout\Microsoft.Azure.Functions.Worker.Extensions.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:03.29


Azure Functions Core Tools
Core Tools Version:       4.0.5455 Commit hash: N/A  (64-bit)
Function Runtime Version: 4.27.5.21554

[2024-02-20T17:34:19.597Z] Found C:\Users\Jaliya\Desktop\test-function\test-function.csproj. Using for user secrets file configuration.

Functions:

        HttpStart: [GET,POST] http://localhost:7071/api/HttpStart

For detailed output, run func with --verbose flag.
[2024-02-20T17:34:21.216Z] Worker process started and initialized.
[2024-02-20T17:34:25.851Z] Host lock lease acquired by instance ID '000000000000000000000000CF6A328F'.

[mattchenderson]

@jaliyaudagedara Thanks for opening this and providing those repro steps! I can confirm the repro on my setup. I agree with your suggested mitigation of pinning back for anyone impacted by this until it can be resolved.

Edit: Also able to confirm that VS has been working fine with this version, which is indeed curious. As a coherence check, I took a working VS project and manually ran func start on the command line. Same issue. And if I open the project created by the Core Tools in VS and run it there, it works fine. VS does have its own installation of the Core Tools, but the stated commit hashes seem to match, too, so in theory it's the same bits in both contexts...

[jaliyaudagedara]

@mattchenderson,

No problem.

but the stated commit hashes seem to match, too, so in theory it's the same bits in both contexts...

Yeah, I checked that as well, have no clue what the difference is.

[mattchenderson]

How had you performed the update? I did it through winget for mine, which ultimately uses the MSI.

VS actually pulls down everything directly as a zip. Comparing the two, it seems like the MSI is just not including Microsoft.Azure.WebJobs.Script.Abstractions.dll for some reason, but the version VS has includes that.

[jaliyaudagedara]

Interesting. I used winget as well.

[mattchenderson]

I just attempted a repair through the MSI and that seems to have fixed it. I have no idea why the initial installation would have missed that. I wonder if a clean first install as opposed to the winget update Microsoft.Azure.FunctionsCoreTools path would be different? I might give that a try tomorrow to see.

[jaliyaudagedara]

Did some testing.

1. I am on 4.0.5455 (C:\Program Files\Microsoft\Azure Functions Core Tools is not empty). Downloaded the 4.0.5530 MSI, and installed (technically this is an update from 4.0.5455 to 4.0.5530).

Same error :(

2. Ran the MSI again (C:\Program Files\Microsoft\Azure Functions Core Tools is not empty of course), but this time (like you) did a Repair.

That worked :)

3. Uninstalled Azure Functions Core Tools (C:\Program Files\Microsoft\Azure Functions Core Tools was deleted by the uninstaller). Installed 4.0.5530 from MSI.

That worked :)

Findings

Copied C:\Program Files\Microsoft\Azure Functions Core Tools at each scenario and compared.

Missing Files/Folders

$notWorkingDirPath = "C:\Users\Jaliya\Desktop\Azure Functions Core Tools-AfterUpdate"
$workingDirPath = "C:\Users\Jaliya\Desktop\Azure Functions Core Tools-AfterRepair"
robocopy $workingDirPath $notWorkingDirPath /e /l /ns /njs /njh /ndl /fp

So it's definitely something to do with the installer when doing an update.

[thomasneuberger]

Uninstalling and reinstalling via winget did the trick for me.

winget uninstall Microsoft.Azure.FunctionsCoreTools
winget install Microsoft.Azure.FunctionsCoreTools

[mattchenderson]

Noting that I just got a separate report of this happening on npm / via the VS Code install path. I have not attempted that repro myself.

[levalencia]

I am having the same issue but my core tools is: Azure Functions Core Tools Core Tools Version: 4.0.5571 Commit hash: N/A +9a5b604f0b846df7de3eb37b423a9eba8baa1152 (64-bit) Function Runtime Version: 4.30.0.22097

I get the error when I do func host start

[levalencia]

strange: this winget install Microsoft.Azure.FunctionsCoreTools downloads the 530 version but the link above downloads 571!

[yooakim]

Same issue for me as well:

Azure Functions Core Tools
Core Tools Version:       4.0.5530 Commit hash: N/A +c8883e7f3c06e2b424fbac033806c19d8d91418c (64-bit)
Function Runtime Version: 4.28.5.21962

following @thomasneuberger advice on uninstall/reinstall using winget solved it for me.

[hajkio]

Hello, we experience the same problem with version 4.0.7317. Downgrading to version 4.0.7030 works for now.

[wbaker23]

Experienced this with version 4.0.7317 installed via MSI. Running the 'Repair' option on the installer after the initial installation solved the issue.

[mthierba]

Ran into this with 4.0.7317 via WinGet and resolved by un-installing and re-installing. 😒

[Liszet]

I am on version 4.1.0.25362 (installed via MSI) and I am facing the same issue when running the function via func start --verbose in a the developer powershell terminal in VS 2022 17.14.11 Preview 1.0

Azure Functions Core Tools Core Tools Version: 4.1.0+7ff2567e43c1ae7471cea7394452c1447661e175 (64-bit) Function Runtime Version: 4.1040.300.25317

Could not load file or assembly 'Microsoft.Azure.WebJobs.Script.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c5b9424214e8f8c'. The system cannot find the file specified.

Update: Uninstalling (via add/remove programs) and reinstalling (via MSI) fixed the problem

[mattchenderson]

Hi all - we believe this is now addressed such that it will no longer be a problem in future releases.

This was all due to an issue with our CI/CD pipelines, resulting in a bad installer build. This has been addressed for future releases.

[fabiocav]

The build process has been fixed and this should be addressed in the next release. Thank you all for the patience and the information shared here.