Skip to content

ProviderAliasAttribute type name reference changed from plain string to type safe expression - #114607

Closed
SetTrend wants to merge 2 commits into
dotnet:mainfrom
SetTrend:ProviderAliasAttribute_TypeSafe
Closed

ProviderAliasAttribute type name reference changed from plain string to type safe expression#114607
SetTrend wants to merge 2 commits into
dotnet:mainfrom
SetTrend:ProviderAliasAttribute_TypeSafe

Conversation

@SetTrend

@SetTrendSetTrend commented Apr 13, 2025

Copy link
Copy Markdown
Contributor

resolves#114532

@ghost

Copy link
Copy Markdown

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
Copy Markdown

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-servicedotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Apr 13, 2025
@dotnet-policy-service

Copy link
Copy Markdown
Contributor

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

@SetTrendSetTrend changed the title ProviderAliasAttribute type name reference changed from plain string to type safe expressionWIP: ProviderAliasAttribute type name reference changed from plain string to type safe expressionApr 13, 2025
@tarekgh

tarekgh commented Apr 13, 2025

Copy link
Copy Markdown
Member

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

@tarekghtarekgh 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
CopilotAI review requested due to automatic review settings April 13, 2025 23:41

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

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.

@tarekghtarekgh changed the title WIP: ProviderAliasAttribute type name reference changed from plain string to type safe expressionProviderAliasAttribute type name reference changed from plain string to type safe expressionApr 13, 2025
@tarekgh

Copy link
Copy Markdown
Member

CC @ericstj

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

Copy link
Copy Markdown
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.

@SetTrendSetTrendApr 14, 2025

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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.AttributeTypeis ProviderAliasAttribute

What do you think?

@SetTrendSetTrendApr 14, 2025

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

Copy link
Copy Markdown

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
publicclassTestLoggerProvider:ILoggerProvider

@SetTrendSetTrendApr 14, 2025

Copy link
Copy Markdown
ContributorAuthor

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.

@KalleOlaviNiemitaloKalleOlaviNiemitaloApr 14, 2025

Copy link
Copy Markdown

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
Copy Markdown
ContributorAuthor

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.

Copy link
Copy Markdown

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
Copy Markdown
ContributorAuthor

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.

Copy link
Copy Markdown

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
Copy Markdown
Member

Closing this for the favor of #114606

@tarekghtarekgh closed this Apr 14, 2025
@github-actionsgithub-actionsBot locked and limited conversation to collaborators May 15, 2025
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Extensions-Loggingcommunity-contributionIndicates that the PR has been added by a community membernew-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

6 participants

@SetTrend@tarekgh@jkotas@teo-tsirpanis@KalleOlaviNiemitalo