Azure-functions-core-tools: Errors after upgrading to 1.0.19

[igorgnedish]

Hi All,

after functions SDK has been updated to 1.0.19 (with corresponding packages like Microsoft.Azure.WebJobs and Microsoft.Azure.WebJobs.Extensions to 3.0.0-beta8 as mentioned here: https://github.com/Azure/app-service-announcements/issues/129).

in the project I have had a custom binding implemented, I was using this approach: https://github.com/Azure/azure-webjobs-sdk/wiki/Creating-custom-input-and-output-bindings

Noticed two things that does not work anymore:

1. in IExtensionConfigProvider implementation ExtensionConfigContext does not contain Config property anymore. So it's not clear how can I resolve IExtensionRegistry in order to registed 'global' filter
2. in IExtensionConfigProvider implementation I registered BindingRule and Binded in to input

Note that ExtensionConfigProvider is located in different assembly (not in the functions' one). Also this code was working before SDK update occured.

So, after I run the project I can see a bunch of a following errors:
Error indexing method 'FunctionClass.MethodName'
[8/31/2018 7:40:28 AM] Microsoft.Azure.WebJobs.Host: Error indexing method 'FunctionClass.MethodName'. Microsoft.Azure.WebJobs.Host: Cannot bind parameter 'bindableParameterName' to type ParameterType. Make sure the parameter Type is supported by the binding. If you're using binding extensions (e.g. ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. config.UseServiceBus(), config.UseTimers(), etc.).

[MarcelLattmann]

We have exactly the same problems.

[gorillapower]

Is there a way to downgrade the CLI that visual studio uses? It looks like its installed automatically.

[dlalex83]

same here. It seems the config extensions is not invoked at all. I can debug through it if using a previous version of the func cli. And I do have the ExtensionConfigProvider in the same assembly as the functions.

[dlalex83]

It seems like the latest update to AzureFunctionsTools that VS did it's now using func.exe version func/2.0.1.36-beta. If I force visualstudio to use func/2.0.1.35-beta everything works fine again.
Now the problem is , I can't use 2.0.1.35-beta with the new 1.0.19 SDK. Is this change intended? or a bug in 2.0.1.36-beta?

[igorgnedish]

@dlalex83 how did you force VS to do that? :-)

[dlalex83]

Copying this from this original post: https://github.com/Azure/app-service-announcements/issues/129#issuecomment-417159056

Using pinned version of core tools with visual studio
Visual studio keeps the core tools updated and in-sync with runtime version in Azure. You can override the default version of core tools launched by visual studio by performing the steps below.

Download and extract this zip file
https://functionscdn.azureedge.net/public/2.0.1-beta.35/Azure.Functions.Cli.win-x86.2.0.1-beta.35.zip
In your function project properties, under Debug create a new profile and update the following values:
Launch: Executable
Executable: \func.exe
Application arguments: host start
Switch over to the new launch profile
Press F5 to run the project

[igorgnedish]

ah, ok, I see, it's a previous version (which was working recently). But if i'm not wrong it will be outdated in a month. So it's still would be nice to get it working :-)

[gorillapower]

@dlalex83 yes i believe you have to use 1.0.19 SDK with the new CLI version - https://github.com/Azure/azure-functions-core-tools/releases/tag/2.0.1-beta.36

[dlalex83]

@gorillapower that's what I'm doing. using 1.0.19 with 2.0.1-beta.35 or lower, breaks because of the breaking changes that were released in 1.0.19. The problem is, using 1.0.19 and 2.0.36-beta breaks the ExtensionConfigProvider extensions. As it seems it's not loading them up at all.

[gorillapower]

@dlalex83 are you able to use V1.0.14 with 2.0.1-beta.35?

[dlalex83]

@gorillapower didn't try 1.0.14. But I'm using 1.0.11 SDK with 2.0.1.beta-35 with no problems and IExtensionConfigProvider custom classes work perfectly fine.

[dlalex83]

@gorillapower just tested 1.0.14 with 2.0.1.35-beta and it's working fine, but I don't have custom ExtensionConfigProviders setup in this example.

[dlalex83]

Ok, found the solution thanks to @brettsam comment here.

The extensions registration pipeline has changed and you now need a class like this one:
C# example

using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Hosting;

[assembly: WebJobsStartup(typeof(Startup))]

namespace Test
{
    public class Startup : IWebJobsStartup
    {
        public void Configure(IWebJobsBuilder builder)
        {
            builder.AddExtension<YourCustomExtensionProvider>();
        }
    }
}

and that will register the extension on startup which will correctly get invoked now.
Everything working on 1.0.19 and 2.0.36-beta.

Hope this helps.

[dlalex83]

uhm, it is all working fine on my local machine now, but breaks once deployed :( I did remove the pin from appsettings. Baffled.

[brettsam]

@dlalex83 -- what error do you get when you deploy? The same thing you were getting previously when running locally?

[dlalex83]

@brettsam yes.As if it cant still load the extension.

[ahmelsayed]

@brettsam this probably doesn't belong here, but I'm not sure if it should go to the azure-functions-vs-build-sdk repo, or the azure-functions-host one.

[mhoeger]

@dlalex83 this is very silly and just to double check - but could you try restarting your production app and make sure that the functions runtime version is as expected?

[dlalex83]

@mhoeger not silly at all. you've pointed me in the right direction. So , after I've removed the pinned version in app settings I've noticed it's now running v1. (shouldn't it have gone back to ~2?)

<HostStatus xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/Microsoft.Azure.WebJobs.Script.WebHost.Models">
<Errors xmlns:d2p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" i:nil="true"/>
<Id>functionappname</Id>
<State>Running</State>
<Version>1.0.11959.0</Version>
</HostStatus>

I've then added the FUNCTIONS_EXTENSION_VERSION setting back with ~2 as value.
By doing that I can see it's now running with the following version

{
id: "lts-products",
state: "Default",
version: "2.0.12050.0",
versionDetails: "2.0.12050.0-beta1 Commit hash: 2db3b7e26f4c10b455afe385f66f67d1b4959b3a"
}

but every single function fails indexing with no specific error (Error indexing method 'FunctionName').
Still a bit confused.

[harjotsmart]

same scenario here, everything setup.
Azure Functions Core Tools (2.0.1-beta.36)
Function Runtime Version: 2.0.12050.0

WebJobsStartup registers the extension (ExtensionConfigContext) but giving error on launch
Microsoft.Azure.WebJobs.Host: Error indexing method 'ApiAppService.RunAppServiceDomain'. Microsoft.Azure.WebJobs.Host: Cannot bind parameter 'faaslogger' to type ILogger. Make sure the parameter Type is supported by the binding. If you're using binding extensions (e.g. ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. config.UseServiceBus(), config.UseTimers(), etc.).

Please guide, how to proceed now. I think this is last point to run the function locally.

[dlalex83]

@mhoeger @brettsam any idea on what this could be? Also, when is 2.0.11961-alpha supposed to be discontinued? Thanks

[brettsam]

@dlalex83 -- 11961 will be available until the end of September 2018. Some additional questions to help narrow down:

• How did you deploy your site?
• Would you mind sharing your site name? See this to share it privately: https://github.com/Azure/azure-functions-host/wiki/Sharing-Your-Function-App-name-privately

@harjotsmart -- Can you share your nuget package references for your project? It seems like there's a version mismatch with ILogger.

[dlalex83]

@brettsam the app is deployed via bitbucket. I can't really use that guide you sent to share it privately as the host failes to index the function, hence I can't run it. Anyway the function app name is lts-caching.azurewebsites.net.

Thanks for looking into it.

[mayoatte]

in IExtensionConfigProvider implementation ExtensionConfigContext does not contain Config property anymore. So it's not clear how can I resolve IExtensionRegistry in order to registed 'global' filter

Has anyone been able to get past this issue? How are you registering function filters now?

[dlalex83]

@brettsam any chance you managed to investigate our app? thanks.

[brettsam]

@mayoatbm -- see this: https://github.com/Azure/azure-functions-host/issues/3401#issuecomment-419777748

@dlalex83 -- I see this exception: System.InvalidOperationException : Cannot bind parameter 'invoker' to type FunctionInvoker. Is that your custom extension?

It's likely that the build process isn't correctly applying your extension to extensions.json when publishing. See this https://github.com/Azure/azure-functions-host/issues/3386#issuecomment-419565714 for a workaround (the global filter issue I linked to above mentions it as well).

[dlalex83]

@brettsam thanks. I can see my local extension.json has my custom Startup whilst the extension.json of the deployed app function doesnt have it. I'll try and use that workaround but is that something you guys are looking to fix? Thanks for your help.

[ahmedelnably]

Closing as stale