Skip to content

Conversation

@SetTrend
Copy link
Contributor

@SetTrend SetTrend commented Apr 13, 2025

resolves #114532

@ghost
Copy link

ghost commented Apr 13, 2025

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

1 similar comment
@ghost
Copy link

ghost commented Apr 13, 2025

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Apr 13, 2025
@dotnet-policy-service
Copy link
Contributor

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

@SetTrend SetTrend changed the title ProviderAliasAttribute type name reference changed from plain string to type safe expression WIP: ProviderAliasAttribute type name reference changed from plain string to type safe expression Apr 13, 2025
@tarekgh
Copy link
Member

tarekgh commented Apr 13, 2025

This LGTM. You may close the other PR #114606. I marked this PR as ready for review too.

@tarekgh tarekgh added this to the 10.0.0 milestone Apr 13, 2025
@tarekgh tarekgh marked this pull request as ready for review April 13, 2025 23:41
Copilot AI review requested due to automatic review settings April 13, 2025 23:41
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

src/libraries/Microsoft.Extensions.Logging/tests/Common/ProviderAliasAttribute.cs:1

  • Removing the ProviderAliasAttribute test implementation may reduce test coverage for alias functionality; please ensure that equivalent tests exist elsewhere.
// Licensed to the .NET Foundation under one or more agreements.

@tarekgh tarekgh changed the title WIP: ProviderAliasAttribute type name reference changed from plain string to type safe expression ProviderAliasAttribute type name reference changed from plain string to type safe expression Apr 13, 2025
@tarekgh
Copy link
Member

tarekgh commented Apr 14, 2025

CC @ericstj

internal static class ProviderAliasUtilities
{
private const string AliasAttributeTypeFullName = "Microsoft.Extensions.Logging.ProviderAliasAttribute";
private static readonly string AliasAttributeTypeFullName = typeof(ProviderAliasAttribute).FullName!;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just an expensive way to compute the constant string. Is it really worth it?

It is very common to hardcode type names as strings. You can find many instances of hardcoded type name strings in this repo.

Copy link
Contributor Author

@SetTrend SetTrend Apr 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a single call, done only once during the lifetime of an application (static). Do you think this makes much of a difference?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say yes. This might root the reflection stack on Native AOT.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think this makes much of a difference?

One-off cases won't make a difference. If we were to use pattern like this everywhere instead of hardcoded strings, it would make a difference.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, this is inconsistent with what we typically do in the rest of the repo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gave it a second thought: Since ProviderAliasAttribute is statically linked in this project, there won't be any other class definition with this FQ name.

So, it may be logical and coherent to replace the const string comparison

if (attributeData.AttributeType.FullName == AliasAttributeTypeFullName &&

in line 22 with an is operator

if (attributeData.AttributeType is ProviderAliasAttribute

What do you think?

Copy link
Contributor Author

@SetTrend SetTrend Apr 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to mention that I very much agree with your valuable AOT argument.

I'm not sure if the is operator is made available for all .NET versions.

This particular change I provided just as an option. We can easily refrain from this change and move over to PR #114606. It contains all the changes I made without the string comparison being changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just reopened #114606. Please choose.

/// Test implementation of ProviderAliasAttribute
/// </summary>
[AttributeUsage(AttributeTargets.Class)]
public class ProviderAliasAttribute : Attribute

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be used in src/libraries/Microsoft.Extensions.Logging/tests/Common/TestLoggerProvider.cs for testing that the comparison in ProviderAliasUtilities is indeed by name and not by type identity. I think it is better to keep this file.

#pragma warning disable CS0436 // Type conflicts with imported type
[ProviderAlias("TestLogger")]
#pragma warning restore CS0436 // Type conflicts with imported type
public class TestLoggerProvider : ILoggerProvider

Copy link
Contributor Author

@SetTrend SetTrend Apr 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@KalleOlaviNiemitalo: I can't find your comment in the "Files changed" tab. Is your comment still valid?

Since the ProviderAliasAttribute moved to Abstractions, it's now available in TestLoggerProvider.cs, so there is no need for duplicate definition. That's why I removed that file.

I found it nice to see that everything falls in place now with the change. No need for a quirk like a duplicate class definition or string comparisons originally implemented as a workaround due to the original class definition not having been available where it should have been.

Copy link

@KalleOlaviNiemitalo KalleOlaviNiemitalo Apr 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it is still valid.

I mean, if some third-party logger provider currently references Microsoft.Extensions.Logging.Abstractions rather than Microsoft.Extensions.Logging, and defines ProviderAliasAttribute as an internal type, then ProviderAliasUtilities should keep recognizing that. And there should be a test to verify that ProviderAliasUtilities does so.

In the existing tests, TestLoggerProvider currently uses the local definition of ProviderAliasAttribute from
src/libraries/Microsoft.Extensions.Logging/tests/Common/ProviderAliasAttribute.cs. If you delete that file, then it will instead use the ProviderAliasAttribute definition that you moved to Microsoft.Extensions.Logging.Abstractions. So this TestLoggerProvider can no longer be used for testing that ProviderAliasUtilities recognizes types by name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, you also plead for keeping the string comparison, like @jkotas does?

No problem. That's why I intentionally created a separate pull request for this. It is just a test drive.

As I wrote above, we can easily refrain from this change and move over to PR #114606. It contains all the changes I made without the string comparison being changed.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, there are internal definitions of ProviderAliasAttribute in these projects:

https://github.com/DataDog/dd-trace-dotnet/blob/b4342eff1e242dda7b47cc2c90232efa1bf0b221/tracer/src/Datadog.Trace/ClrProfiler/AutoInstrumentation/Logging/ILogger/DirectSubmission/ProviderAliasAttribute.cs#L18
https://github.com/microsoft/ApplicationInsights-dotnet/blob/a02249a047eb6f97f83e2b733aedc902a7c92363/NETCORE/src/Microsoft.ApplicationInsights.AspNetCore/Implementation/ProviderAliasAttribute.cs#L9

If you replace the string comparison with a type comparison, it will be a breaking change for those. More breaking than just moving ProviderAliasAttribute from Microsoft.Extensions.Logging to Microsoft.Extensions.Logging.Abstractions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just reopened #114606. Please choose.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find your comment in the "Files changed" tab.

That's because the comment is on a deleted file. If you click "Load diff" above "This file was deleted", then it will show the diff and the comment.

@tarekgh
Copy link
Member

tarekgh commented Apr 14, 2025

Closing this for the favor of #114606

@tarekgh tarekgh closed this Apr 14, 2025
@github-actions github-actions bot locked and limited conversation to collaborators May 15, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Extensions-Logging community-contribution Indicates that the PR has been added by a community member new-api-needs-documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[API Proposal]: ProviderAliasAttribute: Better move to Microsoft.Extensions.Logging.Abstractions

5 participants