This post was most recently updated on February 8th, 2022.2 min read.
This article explains another fun issue that you might run into when developing Azure Functions in your local environment. It was weird how unclear the few results were that I could find. And the issue is just… very hazy in general. But I was able to track the issue down, and thought I’d document the solution :)
It’s for myself, really, because I’m pretty sure I’ll run into this one again. But if you find it useful, good for you! 😉
So what is it that is failing? Well, imagine this:
You hit F5, wait for the Azure Functions host to start, and your screen is filled with red text. The text should say something like this:
Microsoft.Azure.WebJobs.Host: Cannot bind parameter 'log' to type ILogger. Make sure the parameter Type is supported by the binding.
That’s the only text in the debug log as well. There’s very little to go with, right?
The fix turned out to be simple. But before I’ll show you how to fix this, let me list the other things I tried that should’ve worked, but didn’t. They might work for you!
Time needed: 15 minutes.
How to fix “Cannot bind parameter log” in Azure Functions
- Verify your runtime version is correct
This would need to be “v3” for most current use cases. Something like this:
v3 is the latest, and it’ll still take a while until v4 ships (and it’ll ship with quite a few breaking changes), so v3 might be the go-to for a while longer. Anyway – use whatever’s proper for you :)
- Make sure your TargetFramework makes sense
Depending on what you’re targeting, this could be one of many supported target frameworks. For me, it needed to be:
- Update your Microsoft.NET.Sdk.Functions NuGet package
This didn’t help me, as I was already running the latest version (3.0.13 at the time of writing this), but I’ve read online it often helps.
So you might just as well try it!
- Downgrade any packages causing conflicting ILogger interfaces to be loaded
Okay, so I admit this one was kind of weird, but it didn’t take long to track down since the issue popped up just seconds after I had foolishly upgraded my NuGet package references… :)
For me, upgrading Microsoft.Azure.Cosmos package to 3.20.0 was the issue. Downgrading it helped – just check your uncommitted changes, if in doubt! ;)
And that’s it! Let me know whether it helps you or not! :)
- Same error, but the solutions didn’t help me:
- Tips for downgrading:
- Using role claims to target WebSockets - May 24, 2022
- The simplest fixes to “500 (Internal Server Error)” from Azurite - May 17, 2022
- How to solve “Npgsql: 42883: function create_hypertable(…) does not exist”? - May 10, 2022