search

Azure / azure-functions-host

The host/runtime that powers Azure Functions
https://functions.azure.com
MIT License
1.95k stars 442 forks source link

Referencing Microsoft.Extensions.Logging #1570

Open baabel opened 7 years ago

baabel commented 7 years ago

We have been using Microsoft.Extensions.Logging in our Azure Functions since August 2016 by copying the DLLs to a shared \bin folder and referencing from the function.

Release 1.0.1.10917 on April 28 was a breaking change for our apps that use Logging because the logging extensions DLLs were added to the site extensions directory in that release had different versions than we deployed to the Functions \bin directory.

Repro steps

  1. Deploy Microsoft.Extensions.Logging to Function App \bin folder

  2. Reference the DLLs in the function:

r "..\bin\Microsoft.Extensions.Logging.Abstractions.dll"

r "..\bin\Microsoft.Extensions.Logging.dll"

Expected behavior

Should be able to create an instance of ILogger

Actual behavior

error CS0266: Cannot implicitly convert type 'Microsoft.Extensions.Logging.ILogger [D:\home\site\wwwroot\bin\Microsoft.Extensions.Logging.Abstractions.dll]' to 'Microsoft.Extensions.Logging.ILogger [D:\Program Files (x86)\SiteExtensions\Functions\1.0.11002\bin\Microsoft.Extensions.Logging.Abstractions.dll]'. An explicit conversion exists (are you missing a cast?)

Is referencing the logging extensions now available via #r "Microsoft.Extensions.Logging" now that they are deployed to site extensions bin folder?

brettsam commented 7 years ago

@baabel -- we did add support for ILogger directly to Functions with that release, and we neglected to add a binding redirect. We've been discussing a way to prevent this kind of thing, but we'll track that in this issue: #1571.

For your specific scenario, can you share what you're using ILogger for in your function? You may be able to get away without using any #r at all...

baabel commented 7 years ago

We use ILogger for all of our application logging, both for troubleshooting and app requirements. We created an extension of the Log function that essentially drops the log data into a service bus topic for consumption by a separate logging service.

Here's a sample Function:

load "..\domain\RequestRepository.csx"

r "..\bin\Microsoft.Extensions.Logging.Abstractions.dll"

r "..\bin\Microsoft.Extensions.Logging.dll"

r "..\bin\Equifax.Extensions.Logging.dll"

r "..\bin\Equifax.Extensions.ServiceBus.dll"

r "..\bin\Equifax.Extensions.ServiceDiscovery.dll"

r "..\bin\Equifax.Extensions.ServiceDiscovery.Abstractions.dll"

r "..\bin\Equifax.Extensions.Security.dll"

r "..\bin\Equifax.Extensions.Security.Abstractions.dll"

r "..\bin\Equifax.Azure.Functions.Abstractions.dll"

r "..\bin\Equifax.Azure.Functions.dll"

r "Newtonsoft.Json"

r "Microsoft.ServiceBus"

r "Microsoft.WindowsAzure.Storage"

using System.Net;

using System.Net.Http.Formatting;

using System.Web.Http.Tracing;

using Microsoft.Extensions.Logging;

using Microsoft.WindowsAzure.Storage.Table;

using Microsoft.ServiceBus.Messaging;

using Microsoft.ServiceBus;

using Newtonsoft.Json;

using Newtonsoft.Json.Schema;

using Equifax.Extensions.Logging;

using Equifax.Extensions.ServiceDiscovery;

using Equifax.Extensions.Security;

using Equifax.Extensions.Security.KeyVault;

using Equifax.Extensions.ServiceBus;

using Equifax.Azure.Functions;

public static ILogger Logger = ApplicationLogging.CreateLogge r("notification", "create-notificaton");

public static IKeyVault KeyVault = KeyVaultFactory.CreateKeyVault ("efx-digital-id");

public static var Fn = new HttpFunction<Request, Notification>(Logger);

/**

CREATE CRUD operation for notification resource

*/

public async static HttpResponseMessage CreateAsync(HttpRequestMessage req, TraceWriter log)

{

return await Fn.Run( req,

            null,

            (context, rq) => createInternalAsync(context.Logger,

context.CorrelationId, rq, log),

            (m, rq, rs) => HttpStatusCode.Created);

}

public async static Notification createInternalAsync(ILogger logger, string correlationId, Request req, TraceWriter log)

{

var repository = new NotificationRepository(Databas

e.NotificationCollection());

var notification = new Notification {

        uri = req.uri,

        payload = req.payload,

        attempts  = 0,

        success = false,

       policyId = req.policyId

};

await repository.SaveAsync(notification);

logger.log("Notification created", notification, LogLevel.Debug);

return notification;

}

On Jun 5, 2017 1:50 PM, "Brett Samblanet" notifications@github.com wrote:

@baabel https://github.com/baabel -- we did add support for ILogger directly to Functions with that release, and we neglected to add a binding redirect. We've been discussing a way to prevent this kind of thing, but that'll be a separate issue to track.

For your specific scenario, can you share what you're using ILogger for in your function? You may be able to get away without using any #r at all...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/azure-webjobs-sdk-script/issues/1570#issuecomment-306256589, or mute the thread https://github.com/notifications/unsubscribe-auth/AE2N3wUdfQO9goMx3b6Dxcoq0IsdFfGTks5sBEADgaJpZM4NwWEx .

brettsam commented 7 years ago

I'm assuming you're creating a new LoggerFactory in your ApplicationLogging class? We only auto-reference the Microsoft.Extensions.Logging.Abstractions assembly for you right now, but my guess is that you need the concrete implementations as well since you're managing that.

brettsam commented 7 years ago

The quickest way to get this working, btw, would be to upload version 1.1.1 of these two assemblies to your bin folder. That's the version we use and it should remove the error: https://github.com/Azure/azure-webjobs-sdk-script/blob/dev/src/WebJobs.Script.Host/packages.config#L39-L40.

@fabiocav and I have been discussing the fix to prevent this in the future, which may include one or both of:

baabel commented 7 years ago

Yes, that is what we ended up doing, uploading the 1.1.1 DLLs. We can probably just reference .abstractions and remove the other reference.

Thanks, Brian

On Jun 5, 2017 2:58 PM, "Brett Samblanet" notifications@github.com wrote:

The quickest way to get this working, btw, would be to upload version 1.1.1 of these two assemblies to your bin folder. That's the version we use and it should remove the error: https://github.com/Azure/ azure-webjobs-sdk-script/blob/dev/src/WebJobs.Script.Host/ packages.config#L39-L40.

@fabiocav https://github.com/fabiocav and I have been discussing the fix to prevent this in the future, which may include one or both of:

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/azure-webjobs-sdk-script/issues/1570#issuecomment-306273644, or mute the thread https://github.com/notifications/unsubscribe-auth/AE2N3wiKCUjqmZshNI9haNuZ-iqEkkhFks5sBE_FgaJpZM4NwWEx .

solvingj commented 7 years ago

I used to be able to pass ILogger to my azure functions, but now I'm getting the error Cannot bind parameter 'log' to type ILogger. Can someone confirm or deny that my issue is related to this one? If so, what is status. If not, is there another known issue, or should I open one?

brettsam commented 7 years ago

Do you have a project.json that adds Microsoft.Extensions.Logging? Or are you using a precompiled function?

baabel commented 7 years ago

project.json.

( we run nuget restore during our build process and push the DLLs to a /bin folder. From source we reference them... #r "../bin/Microsoft.Extensions.Logging.dll"

We have been using logging extensions for over a year before it was integrated into Functions.

On Aug 18, 2017 9:09 AM, "Brett Samblanet" notifications@github.com wrote:

Do you have a project.json that adds Microsoft.Extensions.Logging? Or are you using a precompiled function?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/azure-webjobs-sdk-script/issues/1570#issuecomment-323349118, or mute the thread https://github.com/notifications/unsubscribe-auth/AE2N35E5rDt5D3u5l-RLP8ekS6t7B35Hks5sZY0cgaJpZM4NwWEx .

brettsam commented 7 years ago

Is that version of Microsoft.Extensions.Logging 1.1.2? We build and reference 1.1.1 in our host, which means you may have a mismatch in versions. Can you try uploading version 1.1.1 to your bin folder and see if that gets you working again?

baabel commented 7 years ago

We are now at 1.1.1 and it is working.

This issue occurred when we were at 1.0.0 and logging was first integrated into Functions. When the Functions runtime upgraded, it broke our existing Function because of the assembly reference error.

We want to prevent future breaks, for example Functions upgrades to logging 1.2.0 and we are referencing 1.1.1

On Aug 18, 2017 9:29 AM, "Brett Samblanet" notifications@github.com wrote:

Is that version of Microsoft.Extensions.Logging 1.1.2? We build and reference 1.1.1 in our host, which means you may have a mismatch in versions. Can you try uploading version 1.1.1 to your bin folder and see if that gets you working again?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/azure-webjobs-sdk-script/issues/1570#issuecomment-323353844, or mute the thread https://github.com/notifications/unsubscribe-auth/AE2N31hCoczvaJ1Tvxgg6WBml7wWzGgAks5sZZHQgaJpZM4NwWEx .

brettsam commented 7 years ago

I'm glad you're working again.

If you stay equal-to or behind our version, you should be fine as we'll make sure the binding redirects move you forward at runtime. The issue arises when a reference moves beyond what we have in our host. We see it with all of our dependencies, and it's a problem we're discussing. There's a long back-and-forth discussion in issue #992 (and a tracking issue for a solution is #1716) if you're interested in the details.

Moeahmad94 commented 6 years ago

Hi @brettsam , I read through this and a few other posts, but I can't tell if you reached a resolution on the Microsoft.Extensions.Logging version 1.1.1 vs 1.1.2. I'm developing a project that due to a dependency requires version 1.1.2, but using version 1.1.2 gives me the same "cannot bind log to ILogger" runtime error. Is there anything I can do to unblock myself right now?

Thanks, Moe

fabiocav commented 6 years ago

@Moeahmad94 as Brett mentioned above, this is one of the dependencies that are unified by the runtime, and unification will upgrade you within safe ranges. We try to stay on the very latest of those packages, where are you referencing 1.1.2 from?

Moeahmad94 commented 6 years ago

I'm referencing another project that has 1.1.2 as a dependency, so unfortunately I don't have complete control over that part.

fabiocav commented 6 years ago

@Moeahmad94 if you have an explicit reference to a 2.x version of the package, this should work as expected. Have you tried adding a reference to a 2.x Microsoft.Extensions.Logging from your function project?

Moeahmad94 commented 6 years ago

I tried that but still get the same error message.

fabiocav commented 6 years ago

Can you open a separate issue with the details? That will help keep things scoped to what you're running into. I can try to set something up and iterate on that issue, but if you have a repro you can also share, that would be helpful. Thanks!

Moeahmad94 commented 6 years ago

Sure. Anything in particular on anyone in particular you want me to add to the new issue I create?

ChristianSnijderAmbusuite commented 4 years ago

For those of you who still run into this problem after changing the framework to .net full. This was the problem for me:

public static async Task Run([TimerTrigger("0 */1 * * * *")] TraceWriter log)

Changing it to:

public static async Task Run([TimerTrigger("0 */1 * * * *")] TimerInfo myTimer, TraceWriter log)

And the problem was solved for me. The exception is very misleading imo.