Menu
My function is referencing an assembly that references Microsoft.Extensions.Logging.Abstractions 2.0.0. If I add a nuget reference to that version to the function's assembly, function execution fails with:
[1/25/2018 11:14:46 PM] Microsoft.Azure.WebJobs.Host: Error indexing method 'TrainingFunction.Run'. Microsoft.Azure.WebJobs.Host: 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. 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.).
Is it possible to use the newer logger in Azure functions ? (SDK 1.0.7)
640
Azure Functions natively support binding to a ILogger parameter on the static method of the function however there are currently some disadvantages. It does not support binding ILogger<T> or ILoggerFactory parameters, does not write entries to the local dev console and does not write to the Azure Portal log section.
To use ILogger as your logging interface, simply add a parameter to your function signature and use any of the logger extensions: public static void Run (string myQueueItem, ILogger logger) { logger.LogInformation ("C# Queue trigger function processed: {message}", myQueueItem); }
It is possible that this will change in the future. The default Azure Functions template in Visual Studio uses TraceWriter for logging. This works well when developing locally with Visual Studio and also writes log entries out to the Azure Portal log section for the function when deployed to Azure.
Then a logger factory and module are registered (more on this later). The way this works is that Azure Functions will invoke the extension point in order to bind values to the marked parameters of the static entry point of the function. The binder will return the parameter value by resolving the target type from the Autofac container.
What is probably happening is that the SDK is binding to version X of the ILogger assembly and your user code is binding to version Y. The binding engine then doesn't recognize your parameter's type as being the same since they're from different assemblies. (this can happen with any other type too).
Generally the fix is to:
119
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
