Add additional LoggerMessageAttribute constructors

[noahfalk]

By @geeknoid

• Event id is not an effective concept; customers don't want to use it and don't have anything to do with it. So, we want overloads that don't require that.
• We are trying to shift customers to not use message strings and stick with structured logging. So, we want overloads that don't include a message.
• We routinely find situations where log levels are specified as a logging method parameter rather than in the attribute definition, so we want overloads that don't include a level.

Bottom line is that the lack of these constructors leads to considerably more ceremony for the customers. More stuff to type with no upside to them.

Proposal

public sealed class LoggerMessageAttribute : Attribute
{
    public LoggerMessageAttribute()
    public LoggerMessageAttribute(int eventId, LogLevel level, string message)

+   public LoggerMessageAttribute(LogLevel level, string message)
+   public LoggerMessageAttribute(LogLevel level)
+   public LoggerMessageAttribute(string message)
}

Original description

dotnet/extensions supports a variety of shortcut constructors on LogMethodAttribute. In the past these shortcuts were deemed undesirable. While I don't know the details behind the original decisions, now that we have more history of internal usage and a better track record we should reconsider.

@geeknoid - can you enumerate exactly which APIs you hope to bring over?

[geeknoid]

Here's the set:

public sealed class LoggerMessageAttribute : Attribute
{
    // existing
    public LoggerMessageAttribute()
    public LoggerMessageAttribute(int eventId, LogLevel level, string message)

    // proposed additions
    public LoggerMessageAttribute(int eventId, LogLevel level)
    public LoggerMessageAttribute(LogLevel level, string message)
    public LoggerMessageAttribute(LogLevel level)
    public LoggerMessageAttribute(string message)
    public LoggerMessageAttribute(int eventId, string message)
    public LoggerMessageAttribute(int eventId)

    // existing
    public int EventId { get; set; } = -1;
    public string? EventName { get; set; }
    public LogLevel Level { get; set; } = LogLevel.None;
    public string Message { get; set; } = "";
    public bool SkipEnabledCheck { get; set; }
}

So:

• Event id is not an effective concept, customers don't want to use it and don't have anything to do with it. So we want overloads that don't require that.

• We are trying to shift customers to not use message strings and stick with structured logging. So we want overloads that don't include a message.

• We routinely find situations where log levels are specified as a logging method parameter rather than in the attribute definition, so we want overloads that don't include a level.

Bottom line is that the lack of these contrusctors leads to considerably more ceremony for the customers. More stuff to type with no upside to them.

Tagging subscribers to this area: @dotnet/area-extensions-logging
See info in area-owners.md if you want to be subscribed.

Issue Details

---

dotnet/extensions supports a variety of shortcut constructors on LogMethodAttribute. In the past these shortcuts were deemed undesirable. While I don't know the details behind the original decisions, now that we have more history of internal usage and a better track record we should reconsider.

@geeknoid - can you enumerate exactly which APIs you hope to bring over?

Author:	noahfalk
Assignees:	geeknoid
Labels:	area-Extensions-Logging
Milestone:	8.0.0

[tarekgh]

Event id is not an effective concept, customers don't want to use it and don't have anything to do with it. So we want overloads that don't require that.

If this is the case, why are we proposing the following constructors? would be better reducing a more helper constructors in such scenario.

 public LoggerMessageAttribute(int eventId, LogLevel level)
 public LoggerMessageAttribute(int eventId, string message)
 public LoggerMessageAttribute(int eventide)

[geeknoid]

@tarekgh I hate it when people point out logical flaws in my stuff :-)

Yeah, I suppose it would be reasonable to not include those.

[noahfalk]

Just a heads up, I suspect without changes to static analysis users that attempt to use the new attribute constructors will get a warning that multiple events use the same -1 id, and warnings that the message string doesn't include their parameter names. Presumably we'd want to remove those warnings.