Azure-functions-host: Cannot bind parameter 'log' to type ILogger.

[forki]

018-12-05T08:11:31.235 [Error] Error indexing method 'StopTransaction.run'
Microsoft.Azure.WebJobs.Host.Indexers.FunctionIndexingException : Error indexing method 'StopTransaction.run' ---> System.InvalidOperationException : Cannot bind parameter 'log' to type ILogger. Make sure the parameter Type is supported by the binding. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
at async Microsoft.Azure.WebJobs.Host.Indexers.FunctionIndexer.IndexMethodAsyncCore(MethodInfo method,IFunctionIndexCollector index,CancellationToken cancellationToken) at C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Indexers\FunctionIndexer.cs : 272
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at async Microsoft.Azure.WebJobs.Host.Indexers.FunctionIndexer.IndexMethodAsync(MethodInfo method,IFunctionIndexCollector index,CancellationToken cancellationToken) at C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Indexers\FunctionIndexer.cs : 167
End of inner exception
at async Microsoft.Azure.WebJobs.Host.Indexers.FunctionIndexer.IndexMethodAsync(MethodInfo method,IFunctionIndexCollector index,CancellationToken cancellationToken) at C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Indexers\FunctionIndexer.cs : 175
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at async Microsoft.Azure.WebJobs.Host.Indexers.FunctionIndexer.IndexTypeAsync(Type type,IFunctionIndexCollector index,CancellationToken cancellationToken) at C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Indexers\FunctionIndexer.cs : 103
2018-12-05T08:11:31.260 [Warning] Function 'StopTransaction.run' failed indexing and will be disabled.

Investigative information

Please provide the following:

• Function App version (1.0 or 2.0): 2.0.12210.0
• Function App name: ecartransactions
• Function name(s) (as appropriate): StopTransaction
• Region: West Europe

This is a regression - same function worked before the 2.0.12210.0 upgrade.

open Microsoft.Extensions.Logging
...
[<FunctionName("StopTransaction")>]
let run([<HttpTrigger(AuthorizationLevel.Function, "post", "stoptransaction")>] req:HttpRequestMessage, log:ILogger) = task {
        ...
        use result = new HttpResponseMessage(HttpStatusCode.OK)
        return result
}

[forki]

btw: all my functions have that issue. not a single function is running anymore.

[forki]

which is the last version before that? I can try to manually downgrade

[forki]

Ok downgrading the runtime to 2.0.12180.0 did not seem to fix the problem. Maybe it's yet another instance of the binding redirects issue and I upgraded aspnet deps too far? Microsoft.Extensions.Logging which nuget version is that expected to be?

[forki]

Now that I think about it: yesterday the aspnet 2.2 nupkgs came out and I bet we upgraded that. Will try to downgrade these.

[jpriestley70]

I have the same issue when everything was updated even .Net Core 2.2.
Downgraded .Net Core to 2.0
Downgraded the following Microsoft packages to 2.1

• Microsoft.EntityFrameworkCore
• Microsoft.EntityFrameworkCore.Design
• Microsoft.EntityFrameworkCore.SqlServer
• Microsoft.Extensions.DependencyInjection.Abstractions

This allowed my Startup class with [assembly: WebJobsStartup(typeof(Startup))] to work again and also the ILogger log parameter in my functions.

[forki]

yes reverting to 2.1 did the trick. but this is yet another nightmare. it's hard to maintain

[thinkbeforecoding]

I got it wokring again with the following paket.dependencies :

```
source https://api.nuget.org/v3/index.json
framework: netcoreapp2.1, netstandard2
storage: none
strategy: min

nuget FSharp.Core
nuget FSharp.Data
nuget Giraffe == 3.1.0
nuget Microsoft.AspNetCore 2.1.1
nuget Microsoft.AspNetCore.StaticFiles 2.1.1
nuget Microsoft.NETCore.Platforms 2.1.1
nuget Microsoft.NET.Sdk.Functions == 1.0.24
nuget Thoth.Json.Giraffe  1.1.0
nuget Thoth.Json.Net 2.4.0
nuget WindowsAzure.Storage 9.3.2
nuget NETStandard.Library 2.0.2

```

[forki]

That looks correct, but boy is it annoying to pin everything. I think azure
functions Team needs to reopen the infamous "binding redirects issue" (see https://github.com/Azure/azure-functions-host/issues/2881) that
they proudly closed live on stage.

[forki]

one thing the team might consider to do is in to release a new Microsoft.NET.Sdk.Functions package that pins its dependecies to concrete versions. That way customers would always use these versions

[Hoaas]

Same error occurs if Microsoft.Extensions.Http 2.2.0 is added to the project.

[skotl]

Same for me, having updated to SDK 2.2
I _could_ go back, but don't particularly want to, and I'm not sure I want to be monkeying around with binding extensions.
Is there a solution for ILogger that anyone is aware of?

[forki]

Since dotnet core doesn't even have support for binding redirects, your
only option is to downgrade to 2.1 and wait until azure functions upgrades
the platform.

Am Di., 11. Dez. 2018, 00:13 hat Scott Leckie [e-mail]
geschrieben:

Same for me, having updated to SDK 2.2
I could go back, but don't particularly want to, and I'm not sure I
want to be monkeying around with binding extensions.
Is there a solution for ILogger that anyone is aware of?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-functions-host/issues/3854#issuecomment-446010453,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNA7pZyQnKd1DTeHDs9RGEa3cgShtks5u3uqfgaJpZM4ZCNon
.

[skotl]

Since dotnet core doesn't even have support for binding redirects, your only option is to downgrade to 2.1 and wait until azure functions upgrades the platform. Am Di., 11. Dez. 2018, 00:13 hat Scott Leckie [e-mail] geschrieben:
…
Same for me, having updated to SDK 2.2 I could go back, but don't particularly want to, and I'm not sure I want to be monkeying around with binding extensions. Is there a solution for ILogger that anyone is aware of? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3854 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNA7pZyQnKd1DTeHDs9RGEa3cgShtks5u3uqfgaJpZM4ZCNon .

Darn - ok, so back to 2.1 for me!
Thanks for the info :)

[jongyllen]

I reverted to the old TraceWriter, it is obsolete but still working.
Also implemented an ILogger that uses the tracewriter so I don't have to rewrite the logging statements in the function.
Will swap it for the dependency injected version when it is fixed

[mikesitch]

We also had to suspend moving to 2.2. Any update on when this will be ready?

[dneelyep]

Confirmed that I receive this error as well when moving to .NET Core 2.2/ASP.NET Core 2.2.

[raymens]

I guess we have to wait for the plans regarding .NET Core 2.2 as mentioned in https://github.com/Azure/azure-functions-host/issues/3611#issuecomment-429989485 ?

[jeffhollan]

Correct - this is due to the fact that we don't quite yet support .NET Core 2.2, but we have the work underway and should ship in January. Usually we don't lag behind releases but in this case we did. The good news is the model today for v2 means we can additively create this support.

As a result we'll also add some issues around better prevention of folks getting into this situation - like messages back to user.

[tdjastrzebski]

I remember .Net was supposed to end the "dll hell".
It did for quite a while but it seems recently something goes deeply wrong.
I just spent hours trying to pin point this issue.

[requilium]

Also hitting this. Do you have an estimate on when it'll be fixed? I'll have to undo some of the other I just did to upgrade to netcoreapp2.2.

Edit: Nevermind, just had some projects that had references to M.E.Logging.Abstractions 2.2.0 which didn't need them.

[JohnGalt1717]

I get this not matter what target framework I use:

<PropertyGroup>
        <TargetFramework>netcoreapp2.0</TargetFramework>
    <AzureFunctionsVersion>v2</AzureFunctionsVersion>
    <LangVersion>latest</LangVersion>
  </PropertyGroup>
  <ItemGroup>
        <PackageReference Include="Microsoft.Extensions.Configuration.AzureKeyVault" Version="2.2.0" />
        <PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="2.2.0" />
        <PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="2.2.0" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
  </ItemGroup>

Because we have dependent projects, all of which need to be on .NET Core 2.2 this is a major blocker. When can we expect this to be released? (Even a pre-release version would help!)

[jongyllen]

We get it on ServieBus queue / topic triggered functions as well.

[oacsed]

This is so frustrating. You cannot update a SDK/Nuget package/anything-really without everything crashing to hell. And waste hours pinpointing to an obscure non-fixed issue.

This all thing is a dirty mess.

[forki]

As I said multiple times: things would be way easier when azure functions
would pin their own dependencies in their nuspec. Waaaaaaay easier

Am Di., 8. Jan. 2019, 17:28 hat oacsed [e-mail]
geschrieben:

This is so frustrating. You cannot update a SDK/Nuget
package/anything-really without everything crashing to hell. And waste
hours pinpointing to an obscure non-fixed issue.

This all thing is a dirty mess.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-functions-host/issues/3854#issuecomment-452361780,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNEcNtBrQQ8zPOlCnvzG5CBqVgkMdks5vBMclgaJpZM4ZCNon
.

[fabiocav]

Deployment for the release adding support for .NET Core 2.2 will be starting this coming week.

We'll also be making some enhancements to prevent similar issues in the future, which includes (but not limited to) some of the things you've mentioned above, @forki.

[PureKrome]

/me politely waiting impatiently ........

[YurivanBoza]

The error comes out when referencing Microsoft.EntityFrameworkCore 2.2.0 or higher. please if you can solve it because the only way to compile it is with version 2.1.4

[raymens]

https://github.com/Azure/azure-functions-host/releases/tag/v2.0.12265

https://github.com/Azure/app-service-announcements/issues/152

Deployments have begun I see!

[forki]

damn it. West Europe is still on: 2.0.12246.0

[oacsed]

Will Azure Function Tools be updated?

[PureKrome]

@oacsed Tools? I thought this was an issue with the nuget package/framework?

[oacsed]

@oacsed Tools? I thought this was an issue with the nuget package/framework?

Well I assume this issue is fixed by the new runtime version (2.0.12265). Shouldn't we expect a new Tools package to use the new runtime version (I mean, on a dev machine using VS)? Please correct me if I'm wrong.

[forki]

still no update in Europe West!?

[C-M-Ryan]

Is there a time frame for the West Europe upgrade?

Also when will we have an updated version of the Tools for VS?

Come on guys, make functions great again! :P

[forki]

it's working for me. I still don't think the root cause is fixed, but it's currently working.

[forki]

thanks!

[fabiocav]

The deployment completed on Friday (apologies for the delay, there were deployment issues we had to address)

[forki]

Would be nice to have some overview site where we can see the progress

Am Mo., 21. Jan. 2019, 08:42 hat Fabio Cavalcante [e-mail]
geschrieben:

The deployment completed on Friday (apologies for the delay, there were
deployment issues we had to address)

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-functions-host/issues/3854#issuecomment-455975947,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNISRVKl8Dt77th5jZCIfK6hOKYXNks5vFW9egaJpZM4ZCNon
.

[oacsed]

What about Azure Function Tools ?

[JohnGalt1717]

@fabiocav There is still no nuget package update showing up for me and this fails for the same reason in development. When can we expect the fixed nuget packages to arrive? We're blocked from a production release until this is fixed.

[forki]

@johngalt1717 what package do you need? This was purely a runtime issue.

[JohnGalt1717]

@forki I would have assumed Microsoft.Net.Sdk.Functions would have been updated at the least.

Where does one get the updated runtime for VS.net so that it works again?

[forki]

You mean to test locally? That's a different issue and I guess you want to open up a separate issue. The function runtime in azure is fixed.

[JohnGalt1717]

@forki It's the same issue. No one in their right mind would release to production without being able to test and verify locally. This is still a blocker because we're never going to blindly trust and push code into Azure and hope it works with no way of being able to prove it first nor, I think, would anyone else. That's why everyone on here is asking where the Azure Function Tools fix is for this.

[PureKrome]

@JohnGalt1717 yeppers! That's what I was wondering ... Preach it!

[forki]

The nuget package and the core tools are different things. The nuget package update won't help you.
Yoi need the runtime bits - I believe they can be built directly from the repo - which is definitely at least inconvenient. They should update the bits on npm.

BTW using a testing/staging environment in the cloud is not "blindly push to azure". Please don't assume everyone is using your workflow. I can totally understand that you want to test locally, but that's really something else. I'd open up another issue which makes perfectly clear that release of the runtime on azure should not happen before proper release of the local runtime.

[JohnGalt1717]

@forki

Standard best practices (according to Microsoft!) development process:

1. Test locally
2. Test in a staging environment
3. Deploy to production.

I am not going to release code into an environment that is vastly more difficult to test against (dockerized functions are basically impossible to test inside azure!) and blindly trust my code. Just because I don't get any errors in staging doesn't mean that the code is working, only that it didn't error. I can't debug or step through anything and thus cannot be sure that the code is doing what it should be doing. Even one configuration setting not set properly in the Azure Keyvault could cause catastrophic data corruption because we use azure functions to do accounting calculations that inject into our accounting system as small example.

So if people aren't doing what I've outlined, their nuts.

And this whole thing outlines a complete failure of the functions team to understand their customers and align their development process correctly and logically. You need to get those function tools out the door immediately and then have a team meeting and navel gaze about the deficiency of your process that resulted in this happening and taking the better part of a month (and counting) to be resolved.

[forki]

I think you might consider your wording here. You have strong opinions
about your workflow, but please don't assume people with otherwise
workflows are nuts.

Am Mo., 21. Jan. 2019, 14:33 hat James Hancock [e-mail]
geschrieben:

@forki https://github.com/forki

Standard best practices (according to Microsoft!) development process:

1. Test locally
2. Test in a staging environment
3. Deploy to production.

I am not going to release code into an environment that is vastly more
difficult to test against (dockerized functions are basically impossible to
test inside azure!) and blindly trust my code. Just because I don't get any
errors in staging doesn't mean that the code is working, only that it
didn't error. I can't debug or step through anything and thus cannot be
sure that the code is doing what it should be doing. Even one configuration
setting not set properly in the Azure Keyvault could cause catastrophic
data corruption because we use azure functions to do accounting
calculations that inject into our accounting system as small example.

So if people aren't doing what I've outlined, their nuts.

And this whole thing outlines a complete failure of the functions team to
understand their customers and align their development process correctly
and logically. You need to get those function tools out the door
immediately and then have a team meeting and navel gaze about the
deficiency of your process that resulted in this happening and taking the
better part of a month (and counting) to be resolved.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-functions-host/issues/3854#issuecomment-456075653,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNA8KKztMfP1OQe0MeMFmIoGWq-7fks5vFcHCgaJpZM4ZCNon
.

[forki]

Btw: things are still working well locally and on azure if you avoid that asp.net 2.2 upgrade. So this is a legit workaround until the runtime bits are released properly.

[JohnGalt1717]

@forki

Again, Microsoft's own best practices agrees with me.

And so do the people on here, almost all of which are asking for updated function tools.

Others might have more lax processes but that doesn't mean that they're right. It just means that they're willing to take risks that Microsoft themselves are not.

Please fix the entire bug and not just half of it.

[oacsed]

@forki
The thing is, the bug _as a whole_ is not yet fixed. Consider someone trying to develop an Azure Function with the latest version of packages/tools/sdk available. It just won't work. Even with the most basic "hello world" example one can find.

If you can't debug locally, it is actually broken.

The frustration is high here, because such issues are unfortunately wayyy to common with Azure and .NET Core.

[JohnGalt1717]

No, avoiding asp.net 2.2 or even 2.2.1 that just came out that the fix may not work with either, is not a valid work around.

We have specific features that require 2.2.x AND the functions share said code. So in a simplistic hello world, your assertions may be correct, but in the real world projects aren't isolated and interact. That's why functions must always be synchronized with releases of the .net core runtime. And by functions I mean ALL of functions, not just Azure.

[forki]

@JohnGalt1717 "We have specific features that require 2.2.x AND the functions share said code" - I'd argue that's the real problem here. With paket as dependency manager you can use dependency groups and untangle that stuff. Please don't assume everyone else is a noob and only works with toys.

Anyway I openend that issue for you https://github.com/Azure/azure-functions-host/issues/3987

[JohnGalt1717]

@forki
Simple project:

DTOs
Data Layer
Repository
Web Api

Function App:
DTOs
Data Layer
Repository
Functions

The Data Layer requires Entity Framework 2.2 because of the major improvements to grouping etc.
The Repository uses major improvements to the .net core runtime.

There should NEVER be an expectation that Microsoft's developers should have to use a 3rd party tool to hack Microsoft's issues. That's isn't being a Noob, that's being part of an enterprise that doesn't use 3rd party tools to hack code to make it work.

Stop deflecting blame here.

[forki]

@johngalt1717 part of the advantage of using FaaS is that we can deploy parts of the system independently. This requires that function apps are as independent as possible. If you treat them like a monolith and share binaries between all the parts then you lose that property. Since functions and other parts of the dotnet framework have different release cycles you will automatically find yourself in the same trouble over and over again.

[oacsed]

@forki

My personal opinion is that we moved from a DLL hell to a package hell / nuget hell. I think the whole stuff is a huge mess. There is not a single time I fear my whole solution will break hard when I upgrade a nuget package / sdk / runtime / tool / anything from a version to another. There are countless bugs everywhere due to incompatibilities between versions. I stopped using Service Fabric for instance because it was a huge waste of time having something working properly. I think this approach is a pure nightmare and I've lost hours figuring out it was not my fault, just some package was not ready yet, and I should wait weeks before changing my nuget package / sdk / runtime / tool version.

So using Faas has definitely its pros (yeah we can have some cool features much faster) but a lot of cons to. Keep in mind we (actual developers that use the products, not build them) don't rush for a version update, we just want stable softwares. We used to upgrade once in a year with a decent changelog and a good view of what will work and what won't. Now it's once in a month with no clue about what's changed and what's broken.

That being said, we could deliberate for hours, this won't help much IMHO.

The fact is, currently the Azure Function Tools don't work properly with a the last version of .NET Core, and this is a huge problem for everyone. So in order to fix this bug for real, could someone create another issue in the right repository (https://github.com/Azure/azure-functions-core-tools)? I don't know the steps to follow to reach out the right team, but we need to move on and this must be fixed ASAP.

EDIT: just saw https://github.com/Azure/azure-functions-host/issues/3987. Good post. Hopefully we'll get a decent answer.

[C-M-Ryan]

@forki

My personal opinion is that we moved from a DLL hell to a package hell / nuget hell. I think the whole stuff is a huge mess. There is not a single time I fear my whole solution will break hard when I upgrade a nuget package / sdk / runtime / tool / anything from a version to another. There are countless bugs everywhere due to incompatibilities between versions. I stopped using Service Fabric for instance because it was a huge waste of time having something working properly. I think this approach it's a pure nightmare and I've lost hours figuring out it was not my fault, just some package was not ready yet, and I should wait weeks before changing my nuget package / sdk / runtime / tool version.

So using Faas has definitely its pros (yeah we can have some cool features much faster) but a lot of cons to. Keep in mind we (actual developers that use the products, not build them) don't rush for a version update, we just want stable softwares. We used to upgrade once in a year with a decent changelog and a good view of what will work and what won't. Now it's once in a month with no clue about what's changed and what's broken.

That being said, we could deliberate for hours, this won't help much IMHO.

The fact is, currently the Azure Function Tools don't work properly with a the last version of .NET Core, and this is a huge problem for everyone. So in order to fix this bug for real, could someone create another issue in the right repository (https://github.com/Azure/azure-functions-core-tools)? I don't know the steps to follow to reach out the right team, but we need to move on and this must be fixed ASAP.

EDIT: just saw #3987. Good post. Hopefully we'll get a decent answer.

100% this.

I am an early adopter in my organisation (trying to champion the use of Functions internally), it is easy to say academically that it is great that the Azure libraries are separated etc.. but the reality for those of us who are the consumers is that the lack of communication and planning across the Azure Teams is punishing us when we update our solutions to use what we expect is a stable offering. If the teams worked closer together and worked off a joint road map I think a lot of this would go away.

My organisation has premium support, but I dare not raise a ticket for such matters as from experience doing so becomes a massive time vacuum in follow up with the account manager and MS Architects which leads nowhere with nothing but time lost to show for it.

Anyway, Thanks MS team for the Release I look forward to tooling update, apologies for the rant. back to the coal face!

[forki]

FTR: I don't have any affiliation with Microsoft. I'm a consumer or "actual developers that use the product" as well. I'm just saying that going to the cloud needs to change mindset - this is in no way academic, this is just the nature of this thing. I agree with all of you that the team needs to do better here and that missing binding redirects is just a nightmare. But it's equally important for users to understand that we will hit these issues over and over again if we don't start to untagle the code for the services that we use.

[JohnGalt1717]

@forki

Fact: If you want to have major issues, have the same database model described by EF Core twice separately.

Thus there is absolutely no way to NOT include at the very least your DAL with functions if you are accessing your database, which you almost certainly are.

THUS.

Functions MUST always be aligned with the release of .NET Core.

FACT: Microsoft's own best practices say you're wrong about testing in the cloud.
FACT: You can't remote debug docker functions.

THUS

You're completely and utterly incorrect when it comes to your assertions that it's fine that this only works in Azure and is broken in VS.NET/Code.

Since you don't work for Microsoft AND you clearly don't have a clue what you're talking about, how about you leave it for Microsoft to fix the problem and fix the issue and stop pontificating on a subject that you're clearly out of your depth on.

[oacsed]

@forki

Fact: If you want to have major issues, have the same database model described by EF Core twice separately.

Thus there is absolutely no way to NOT include at the very least your DAL with functions if you are accessing your database, which you almost certainly are.

THUS.

Functions MUST always be aligned with the release of .NET Core.

FACT: Microsoft's own best practices say you're wrong about testing in the cloud.
FACT: You can't remote debug docker functions.

THUS

You're completely and utterly incorrect when it comes to your assertions that it's fine that this only works in Azure and is broken in VS.NET/Code.

Since you don't work for Microsoft AND you clearly don't have a clue what you're talking about, how about you leave it for Microsoft to fix the problem and fix the issue and stop pontificating on a subject that you're clearly out of your depth on.

I'm equally frustrated as you are and I can feel the weariness too with all those version issues, but try not to be personal against @forki

This issue really is a PITA, but he doesn't work for MS and his post https://github.com/Azure/azure-functions-host/issues/3987 is actually useful for everyone as it's the best chance they fix this whole thing.

[JohnGalt1717]

@oacsed You're dropping causality. Read the thread. @forki started the insults directly against me. I'm simply putting him/her in his/her's place.

[forki]

What? Where did I insult you? That would never be my intention. I just statedI think that part of the issue is treating cloud infrastructure like a monolith.

[cartermp]

I'd like to point out that this repository is governed by the Microsoft code of conduct: https://opensource.microsoft.com/codeofconduct/

Please refrain from insults towards other people who use this repository, thank you.

[fabiocav]

To get back to the original topic, the Core Tools update was released on Friday (when the deployment completed) for VS. NPM, brew and other repositories are being updated as well.

[JohnGalt1717]

Where can they be downloaded? I can only find the one from December on the git hub repro for the tools.

[dersia]

I guess I have mentioned this a few times in person to several people. The only way I see for the binding redirect issue and other updating issue to be fixed is in a bring your own worker version that is not dependent on a specific sdk.

I know of course, that this needs some more dev work and will probably bring some other downsides, but I guess there is no real other solution than that.

I'm happy to take time and get in a call and plan this through with who ever is interested in that option.

[fabiocav]

@JohnGalt1717 the download is automatically handled if using VS, for the other channels, the update is now available on NPM and Homebrew. You can find installation instructions here: https://github.com/azure/azure-functions-core-tools#installing

@dersia the answer for a custom worker (mentioned in some of the previous threads on this topic) is actually to leverage the out-of-proc infrastructure we already use for the other languages. This would enable to bring a language worker that works with .NET and giver you full control over the process.

[dersia]

@fabiocav

I am aware of that, but I think it actually needs some extra work and a way to bring your bring in your custom worker into the host runtime something like we can do today with custom binding extensions.

But I guess this is a topic for another discussion and not for this one 😉

[gdodd1977]

So is that claim here that the latest version of core tools eliminates this issue in regards to having to downgrade EF core?

[torhovland]

For me, this issue didn't sort itself out on its own. Although I also run on West Europe, like @forki, I still got version 2.0.12246.0, the one that doesn't work. However, after manually restarting the Function App, I get 2.0.12275.0.

[forki]

@torhovland did you restart your function app?

[torhovland]

@forki Thanks for the hint. I just figured that out, and updated my comment above :-)