Strong type support in Microsoft.Extensions.Logging

[reyang]

Problem Description

In a large codebase, there are cases people want to log with existing types defined for business logic (and these types might come from a 3rd party library which is not controlled by the dev), rather than having to invent another type (and do the mapping) or write lots of boilerplate code.

public struct Food
{
    public string Name { get; set; }
    public double Price { get; set; }
}

logger.Eat(new Food { Name = "artichoke", Price = 3.99 });

In order for the above code to work, one has to write the boilerplate code as follows, and will start to hit performance issue if there are more than 6 fields (based on the current implementation).

using System;
using Microsoft.Extensions.Logging;

public static class LoggerExtensions
{
    private static readonly Action<ILogger, Food, Exception> _eat = LoggerMessage.Define<Food>(
        LogLevel.Information,
        new EventId(1, nameof(Eat)),
        "Eat (Food = {food})."); // message template, not interpolated string

    public static void Eat(this ILogger logger, Food food)
    {
        _eat(logger, food, null);
    }
}

The Ask

Provide a vendor agnostic way for the user to log strong typed objects without having to write boilerplate code, yet with good/reasonable performance.

public struct Food
{
    public string Name { get; set; }
    public double Price { get; set; }
}

public class Dog
{
    public string Name { get; set; }
    public int Age { get; set; }
}

logger.Eat(new Food { Name = "Artichoke", Price = 3.99 });
logger.Log(new Dog { Name = "Labrador Retriever", Age = 2 });

Additional Information

• It is not clear if this should part of .NET runtime, or it should be provided by 3rd party (e.g. OpenTelemetry). I guess one goal could be - any existing provider (e.g. ConsoleLoggerProvider) should just work.
• This potentially could leverage compile-time logging source generation.
• Additional scenario 1
• Additional scenario 2

Tagging subscribers to this area: @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Problem Description

In a large codebase, there are cases people want to log with existing types defined for business logic, rather than having to invent another type (and do the mapping) or write lots of boilerplate code.

public struct Food
{
    public string Name { get; set; }
    public double Price { get; set; }
}

logger.Eat(new Food { Name = "artichoke", Price = 3.99 });

In order for the above code to work, one has to write the boilerplate code as follows, and will start to hit performance issue if there are more than 6 fields (based on the current implementation).

using System;
using Microsoft.Extensions.Logging;

public static class LoggerExtensions
{
    private static readonly Action<ILogger, Food, Exception> _eat = LoggerMessage.Define<Food>(
        LogLevel.Information,
        new EventId(1, nameof(Eat)),
        "Eat (Food = {food})."); // message template, not interpolated string

    public static void Eat(this ILogger logger, Food food)
    {
        _eat(logger, food, null);
    }
}

The Ask

Provide a vendor agnostic way for the user to log strong typed objects without having to write boilerplate code, yet with good/reasonable performance.

public struct Food
{
    public string Name { get; set; }
    public double Price { get; set; }
}

public class Dog
{
    public string Name { get; set; }
    public int Age { get; set; }
}

logger.Eat(new Food { Name = "Artichoke", Price = 3.99 });
logger.Log(new Dog { Name = "Labrador Retriever", Age = 2 });

Additional Information

• It is not clear if this should part of .NET runtime, or it should be provided by 3rd party (e.g. OpenTelemetry). I guess one goal could be - any existing provider (e.g. ConsoleLoggerProvider) should just work.
• This potentially could leverage compile-time logging source generation.

Author:	reyang
Assignees:	-
Labels:	untriaged, area-Extensions-Logging
Milestone:	-

[yecril71pl]

The introduction says that named parameters can be used to attach properties to log entries.
I would like the opposite syntax to work in the following scenarios:

const string format = "Customer {Name} #{Serial} entered the shop.  {Name} left {Mood}.";

var customer = new { Name = "Joe", Sex = Sex .Male, Age = 50, Serial = 33 };
logger .LogInformation (format, customer with { Mood = Mood .Satisfied });

var customer = new Customer { Name = "Joe", Sex = Sex .Male, Age = 50, Serial = 33 };
customer .Mood = Mood .Satisfied;
logger .LogInformation (format, customer);

var customer = new Dictionary < string, object >
 { ["Name"] = "Joe", ["Sex"] = Sex .Male, ["Age"] = 50, ["Serial"] = 33 };
customer ["Mood"] = Mood .Satisfied;
logger .LogInformation (format, customer);

All these calls should translate to

logger .Log
 (LogLevel .Information, default, null,
 format, "Joe", 33, "Joe", Mood .Satisfied);

Implementing this using reflexion bumps into the following problem: support for enumerating parameter islands in a message format string, which was never officially supported, was removed from the public API in ASP.NET 3, so any independent solution would have to rely on undocumented features or contain a copy or a replica of internal code.