Add logging to identity Worker Specific Extensions Versions perhaps as part of the WorkerInitRequest

[FinVamp1]

What problem would the feature you're requesting solve? Please describe.

For In Pro and Bundles we have diagnostics that clearly show the version of the Extension loaded and if it has a newer version. It was noticed that the .NET Isolated Worker Extensions don't show up on the logs in the same manner.

E.G

Please provide feedback here:

1. Latest version is N/A
2. Identity Based Support  it should show as supported take Azure Queues triggers and bindings as example based on this Guidance for developing Azure Functions | Microsoft Learn we should show it as supported .

The current logging is showing the Internal name of the Extension from the source and this matches up to the version on the Worker Extension.

Updating Service Bus extension references. · Azure/azure-functions-dotnet-worker@4189766 (github.com) Updating Service Bus extension references. · Azure/azure-functions-dotnet-worker@4189766 Azure Functions out-of-process .NET language worker - Updating Service Bus extension references. · Azure/azure-functions-dotnet-worker@4189766

https://github.com/Azure/azure-sdk-for-net/blob/d6f89a90aacc28ca76a2760fa70581d686466c1f/sdk/storage/Microsoft.Azure.WebJobs.Extensions.Storage.Common/src/Shared/Constants.cs#L10

Describe the solution you'd like

We need logging that shows the Worker Extensions versions so we can report this to the customer and suggest appropriate upgrades,

Describe alternatives you've considered

No other approaches have been considered,

Additional context

This is for supportability and self-help for the customer.

[mattchenderson]

Sending back to triage. This is not clearly actionable. Is this just a request to log worker assembly versions? To what end? Whether or not identity is supported ultimately needs to be derived from host extension versions, which is information already present. We need an example case where the lack of this (worker assembly) information led to a supportability issue.

[liliankasem]

@mattchenderson I think this is a nice quality of life improvement for support engineers and anyone investigating CRIs - it's really nice to have all the information in one place. I do consider this actionable, it might have to be a design item to start before any code needs to be writen.

[FinVamp1]

Thanks @liliankasem I was going to say the same thing. It helps to understand the versions that are currently being used so that we can have a better understanding of potential issues and help drive investigations.