Service bus binding runtime error: Could not load file or assembly

[preslavgerchev]

Deploying a new function app with a service bus binding leads to the following error:

Microsoft.Azure.WebJobs.Script: Error configuring services in an external startup class. Microsoft.Azure.WebJobs.Extensions.ServiceBus: Could not load file or assembly 'Microsoft.Extensions.Configuration.Abstractions, Version=8.0.0.0, Culture=neutral, PublicKeyREDACTED (possible password or key detected)

The function uses a custom runtime as the underlying code is written in Go, excerpt from the function's env variables:

FUNCTIONS_WORKER_RUNTIME: "custom"
FUNCTIONS_EXTENSION_VERSION: "~4"

We use the latest bundle, here's the relevant bits from host.json:

"version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    },

This has started to happen recently as we've had this setup (binding and code) since a few months and the code is untouched. We deploy this function app every night as part of an integration test pipeline and this is how we've spotted the issue surfacing last week.

The app insights, hooked to the function has this log:

Microsoft.Azure.WebJobs.Script.ExternalStartupException: Error configuring services in an external startup class.
---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Extensions.Configuration.Abstractions, Version=8.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.

File name: 'Microsoft.Extensions.Configuration.Abstractions, Version=8.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
at Microsoft.Extensions.Hosting.ServiceBusHostBuilderExtensions.AddServiceBus(IWebJobsBuilder builder, Action`1 configure)
at Microsoft.Extensions.Hosting.ServiceBusHostBuilderExtensions.AddServiceBus(IWebJobsBuilder builder)
at Microsoft.Azure.WebJobs.ServiceBus.ServiceBusWebJobsStartup.Configure(IWebJobsBuilder builder)
at Microsoft.Azure.WebJobs.WebJobsBuilderExtensions.ConfigureStartup(IWebJobsStartup startup, WebJobsBuilderContext context, IWebJobsBuilder builder) in D:\a\_work\1\s\src\Microsoft.Azure.WebJobs.Host\Hosting\WebJobsBuilderExtensions.cs:line 166
at Microsoft.Azure.WebJobs.WebJobsBuilderExtensions.ConfigureAndLogUserConfiguredServices(IWebJobsStartup startup, WebJobsBuilderContext context, IWebJobsBuilder builder, ILoggerFactory loggerFactory) in D:\a\_work\1\s\src\Microsoft.Azure.WebJobs.Host\Hosting\WebJobsBuilderExtensions.cs:line 130
at Microsoft.Azure.WebJobs.WebJobsBuilderExtensions.UseWebJobsStartup(IWebJobsBuilder builder, Type startupType, WebJobsBuilderContext context, ILoggerFactory loggerFactory) in D:\a\_work\1\s\src\Microsoft.Azure.WebJobs.Host\Hosting\WebJobsBuilderExtensions.cs:line 115
at Microsoft.Azure.WebJobs.WebJobsBuilderExtensions.UseExternalStartup(IWebJobsBuilder builder, IWebJobsStartupTypeLocator startupTypeLocator, WebJobsBuilderContext context, ILoggerFactory loggerFactory) in D:\a\_work\1\s\src\Microsoft.Azure.WebJobs.Host\Hosting\WebJobsBuilderExtensions.cs:line 213
at Microsoft.Azure.WebJobs.Script.ScriptHostBuilderExtensions.<>c__DisplayClass7_0.<AddScriptHostCore>b__1(HostBuilderContext context, IWebJobsBuilder webJobsBuilder) in /_/src/WebJobs.Script/ScriptHostBuilderExtensions.cs:line 235
--- End of inner exception stack trace ---

The function.json (binding) file looks like this:

{
    "bindings": [
        {
            "name": "msg",
            "type": "serviceBusTrigger",
            "direction": "in",
            "queueName": "<redacted>",
            "connection": "ServiceBusConnection"
        }
    ]
}

The identity that the function uses has owner permissions over the service bus, so no auth issues.

The function app has a few more bindings (mostly timers), around 10, that all refuse to start because of this issue we're seeing above.

Investigative information

Please provide the following:

• Timestamp: 2025-07-21T07:09:56.6322431Z
• Function App version: shows Error in the portal, so unable to determine this from there. the app insights log has this as a detail to the error message, shown above: azurefunctions: 4.640.100.0, so I assume that this is trying to run on 4.640.100.0.
• Function App name: Unable to share as we'd like to keep this private.
• Function name(s) (as appropriate): Unable to share as we'd like to keep this private.
• Invocation ID: Unable to share this as the function does not even start
• Region: UK South

Repro steps

Provide the steps required to reproduce the problem:

1. Deploy a function app with a function, tied to a service bus binding. Use custom runtime
2. The function will not even start and throws the error, described above. This can also be seen in the portal (UI)

Expected behavior

Provide a description of the expected behavior.

1. The function to run.

Actual behavior

Provide a description of the actual behavior observed: The function does not start.

Known workarounds

Provide a description of any known workarounds: No workarounds to my knowledge, this fully blocks the function from being usable.

Related information

Provide any related information

• Programming language used: the code that the bindings use is is written in Go (1.24)
• Links to source
• Bindings used

[preslavgerchev]

We believe this is caused by this extension bundle release: https://github.com/Azure/azure-functions-extension-bundles/releases/tag/4.23.1 since our issues started right after it was released.

Downgrading the host.json version like this:

"version": "[4.0.0, 4.23.0)"

fixed the function app, it is now up and running:

Host Status: {
"id": "<redacted>",
"state": "Running",
"version": "4.641.100.0",
"versionDetails": "4.641.100-dev.0.0+4da360ab4b0815b0800ad1acc89865e07def250d",
"platformVersion": "104.0.7.217",
"instanceId": "<redacted>",
"computerName": "<redacted>",
"processUptime": 164450,
"functionAppContentEditingState": "Unknown",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "4.21.0"
}

Still think this should be fixed properly to allow us to use latest extension bundle as suggested by opening the version range as stated in the docs: [4.0.0, 5.0.0)

[jviau]

@preslavgerchev since you are using an external out of proc worker, you should aim for using functions worker 4.10* and not 4.6*. 4.6* is intended for in-proc .net6 apps only.

[preslavgerchev]

@jviau, are you referring to the version of the worker: azurefunctions: 4.640.100.0?

To my knowledge, we do not set this explicitly, the only thing we control is the extensions bundle version: "version": "[4.0.0, 5.0.0)"

[jviau]

@preslavgerchev what sku are you using / how are you hosting your function app?

[preslavgerchev]

@jviau, we're running the function app in Azure, not hosting anything.

We use bicep to declare our resources, here's the ARM template definitions we use:

resource hostingPlan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: hostingPlanName
  location: location
  kind: 'elastic'
  sku: {
    name: 'EP1'
    tier: 'ElasticPremium'
    family: 'EP'
  }
  properties: {
    maximumElasticWorkerCount: 10
    reserved: true
  }
}

resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp,linux'
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: identities
  }
  properties: {
    serverFarmId: hostingPlan.id
    siteConfig: {
      use32BitWorkerProcess: false
      appSettings: [
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'custom'
        }
      ]
      ftpsState: 'Disabled'
      minTlsVersion: '1.2'
      alwaysOn: true
      http20Enabled: true
      ipSecurityRestrictions: [
        {
          tag: 'ServiceTag'
          priority: 100
          action: 'Allow'
          name: 'AzureEventGrid'
          description: 'Allow Azure Event Grid to call the Function App'
          ipAddress: 'AzureEventGrid'
        }
      ]
    }
    publicNetworkAccess: 'Enabled'
    clientAffinityEnabled: false
    httpsOnly: true
  }
}

[jviau]

@preslavgerchev thank you for the details. We have a known issue where custom handlers with Linux Dedicated (elastic premium included) are being assigned to the wrong host version. We are still working on addressing the issue. For the time being, Linux consumption and Windows dedicated do not have this issue.