azure-functions-host: FunctionsStartup not being called after runtime update in Azure, causing DI failure

I had recently updated my Azure Functions from v3-preview to v3 after the .NET Core 3.1 GA announcement. Everything was running fine for development locally and in Azure.

At almost exactly 10:30PM EST on Friday (2019-12-13), all of my functions in development and production environments (two different resource groups) started failing.

Everything still runs fine locally.

The reason is that FunctionsStartup is no longer being run. I have no means by which to fix this as these functions were developed from day 1 in .NET Core 3 and have netcoreapp3.1 dependencies I can’t change. I have no way to rollback these functions to v2.

My functions app on Azure reads: Runtime version: 3.0.12939.0 (~3)

Local development reads: Azure Functions Core Tools (3.0.2009 Commit hash: 77395527a4e9c28da8400dcfd1a450f4e0d0c36c) Function Runtime Version: 3.0.12930.0

Let me reiterate - this was working after upgrading from v3-preview to v3. It stopped working after something was deployed by the Azure team

This is incredibly frustrating as a breaking changed was simply introduced by someone at Microsoft.

Investigative information

Please provide the following:

  • Timestamp: 2019-12-16T20:08:06.480
  • Function App version (1.0 or 2.0): 3.0.12939.0
  • Function App name: CavFunctions-Dev
  • Function name(s) (as appropriate): all functions
  • Invocation ID:
  • Region: East US

Repro steps

Register something in a DI Container like so:

[assembly: FunctionsStartup(typeof(MyApp.Functions.Startup))]
namespace MyApp.Functions
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            // Register things in DI container
            builder.Services.AddScoped<Greeter>();
        }
    }
}

Use it like so:

    public class MyFunction
    {
        private readonly Greeter _greeter;

        public MyFunction(Greeter greeter)
        {
            _greeter = greeter
        }

        // Every 5 minutes
        [FunctionName(nameof(MyFunction))]
        public async Task Run([TimerTrigger("0 0/5 * * * *", RunOnStartup = true)]TimerInfo myTimer, CancellationToken cancellationToken)
        {
            await _greeter.Greet();
        }
    }

Expected behavior

Constructor injection works properly

Actual behavior

FunctionsStartup ignored, Greeter isn’t registered in DI container, results in exception:

Unable to resolve service for type 'Greeter' while attempting to activate 'MyApp.MyFunction'. System.InvalidOperationException: at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.GetService (Microsoft.Extensions.DependencyInjection.Abstractions, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60) at lambda_method (Anonymously Hosted DynamicMethods Assembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null)

Known workarounds

https://github.com/Azure/azure-functions-host/issues/5401#issuecomment-566578914

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 6
  • Comments: 42 (10 by maintainers)

Commits related to this issue

Most upvoted comments

I had this issue today with a brand new functions project, the Startup.Configure(...) method was not being called at any point.

Visual Studio: 16.5.0 Preview 5.0 Azure Functions & Web Jobs Tools: 16.5.236.49856 Microsoft.NET.Sdk.Functions: 3.0.4 TargetFramework: netcoreapp3.1 AzureFunctionsVersion: v3

Downgrading Microsoft.NET.Sdk.Functions to 3.0.3 solved this, and the Startup.Configure(...) method is now called on startup as expected.

The SDK issue has been resolved in 3.0.5. If you’re running into a problem after moving to 3.0.4, please just upgrade.

I got the same issue as well. The workaround was to downgrade Microsoft.NET.Sdk.Functions from 3.0.2 to 1.0.31.

@IanKemp I hear you. We burned some time on this bug too. It hurt. OTOH, this is a open source project. It’s free. They accepts PRs. If you’ve got the talent, help them out and add some test coverage for this? We’d all benefit.

That would require me to gift some of my own time to Microsoft. Considering that time is money, and that I’ve already paid for Azure, what you’re effectively suggesting is that I pay Microsoft to write the tests that they, as a multibillion-dollar company, already should have in place as basic due diligence. Or to put it another way, Microsoft gets for free something they would normally have paid an employee for.

You can probably guess how I feel about doing that.

If we were talking about OSS from a nonprofit, my reaction would be quite different. But not only is this a for-profit company, and an extremely profitable one at that; we are literally paying for this functionality from said company. Open-source does not abrogate Microsoft of responsibility for basic quality, and it most certainly does not mean that we the paying end users should be willing to fall into the trap of doing Microsoft’s work for it.

@IanKemp I hear you. We burned some time on this bug too. It hurt. OTOH, this is a open source project. It’s free. They accepts PRs. If you’ve got the talent, help them out and add some test coverage for this? We’d all benefit.

Explicitly adding a host.json file to your solution (and set its property to copy to the output folder) should address this issue.

That works. After manually adding a global host.json file (with no extensionBundle), the startup executes.

The SDK issue has been resolved in 3.0.5. If you’re running into a problem after moving to 3.0.4, please just upgrade.

This is absolutely pathetic from Microsoft.

How is it possible that one of the world’s largest software companies managed to push an update that is completely, fundamentally broken in the simplest way possible? Do you not have any tests of any sort for this software?

And why, for the love of all that is holy, have you not pulled the broken and useless 3.0.4 from NuGet? With a corresponding blog post to notify people to avoid that version? Or even an issue pinned on this repo?

Unbelievable. Just unbelievable.

I’ve made a repo to reproduce @benmiller86 's bug. https://github.com/TroyWitthoeft/AzureFunctionsHostStartupBug

If you clone that down and debug, you’ll notice the Startup.cs is not hit. If we update the csproj file and change the Microsoft.NET.Sdk.Functions version from 3.04 to either 3.0.3 or 3.0.5, then the Startup.cs file is again hit.

Project uses Functions v3, dotnet core 3.1 Local environment = VSCode 1.42.1 func core tools = 3.0.2245

I had this issue today with a brand new functions project, the Startup.Configure(...) method was not being called at any point.

Visual Studio: 16.5.0 Preview 5.0 Azure Functions & Web Jobs Tools: 16.5.236.49856 Microsoft.NET.Sdk.Functions: 3.0.4 TargetFramework: netcoreapp3.1 AzureFunctionsVersion: v3

Downgrading Microsoft.NET.Sdk.Functions to 3.0.3 solved this, and the Startup.Configure(...) method is now called on startup as expected.

Same here, downgrading to 3.0.3 solved the issue for me.

I got it working, my issue was that I was overwriting the configuration with this line:

builder.Services.AddSingleton<IConfiguration>(configuration);

This caused me to falsely believe that Startup wasn’t called. I fixed it by removing the line and replacing it with something similar to https://github.com/Azure/azure-functions-host/issues/4464#issuecomment-554483114.

@fabiocav I do not have an extension bundle in host.json, here is the whole file:

{
    "version": "2.0"
}

Is the extensions.json file mandatory for the Startup class to be called in Azure? It works locally without.

Rebuilding the solution an manually removing the “extensionBundle” property before running the debugger allows the Startup class to execute.

Just to clarify something I said earlier, the global host.json file doesn’t initially exist until after running the function app locally. So I have to run it, then modify the host.json file, the run it again to get it to work.

Hello i had same problem on local machine, Startup class was not called anymore. I had to delete

"extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[1.*, 2.0.0)"

from host.json file to make Startup class be called again. Hope this helps !

And that’s in the built solution, correct?

Yes, i’ve checked file history, and it was created by Visual Studio Code’s Azure Function extension.

Hello i had same problem on local machine, Startup class was not called anymore. I had to delete

"extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[1.*, 2.0.0)"

from host.json file to make Startup class be called again. Hope this helps !

After another round of troubleshooting, I’ve determined that I’m experiencing this exact issue:

https://github.com/Azure/Azure-Functions/issues/972 also https://github.com/Azure/azure-functions-host/issues/3386

The only way I was able to get the functions running was to use the workarounds in both of the following comments:

https://github.com/Azure/azure-functions-host/issues/3386#issuecomment-419565714 https://github.com/Azure/Azure-Functions/issues/972#issuecomment-444436597

Adding Directory.Build.targets didn’t work on its own and manually adding extensions.json also didn’t work on its own, but together I get the proper extensions.json in the publish folder:

C:\Projects\MyApp\MyApp.Functions\obj\Release\netcoreapp3.1\win-x64\PubTmp\Out\bin

I’m not going to bother opening another issue, but in case anyone reads this, I get OutOfMemoryExceptions after every publish which magically seems to resolve itself after about 30 minutes. It made troubleshooting this issue a true nightmare, and honestly this whole experience makes Azure Functions feel like an early beta / toy. I’m glad this is for a personal project as I’ll be avoiding functions like the plague from here on out. This issue is the worst of the ones I’ve run into, but it’s not nearly the first. The idea is cool, but I’ll check back in a year or two when it’s hopefully ready for production.