a new attribute to allow custom attributes to indicate that the decorated member is not unused (prevent invalid IDE0051)

[jjanuszkiewicz]

This is coming from my comment in #34719 (comment).

Currently there are some cases where there is no way (apart from an explicit suppression on a case-by-case basis) to get rid of IDE0051.

One example is this xUnit test, another is in the issue linked above:

[Fact]
private void TheTestMethod() { ... }

xUnit allows tests to be private, but this causes IDE0051. It can be suppressed (individually, per file, per test project), but that is inconvenient - it is unnecessary noise in the code, and if done on file or project level, can hide other, valid cases when IDE0051 should be raised.

It would be ideal if a custom attribute (like xUnit's Fact) could indicate that the decorated member is actually used - similar to what the DynamicallyAccessedMembers attribute can be used for now.

E.g. there could exist a DynamicallyAccessedDecoratedMember attribute:

[AttributeUsage(AttributeTargets.Class)]
public class DynamicallyAccessedDecoratedMemberAttribute : Attribute { ... }

which would be used like this (using the xUnit example):

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
[DynamicallyAccessedDecoratedMember]
public class FactAttribute : Attribute { ... }

which would cause members decorated with [Fact] to be recognized as used.

Would such a new DynamicallyAccessedDecoratedMemberAttribute be something desired?

[CZEMacLeod]

I can think of several scenarios I have for this kind of thing.
There are some similar warnings I have in code that must be suppressed due to reflection scanning/access based on attributes.
Perhaps we could do a more generic SuppressAttribute which could take a list of codes to suppress on the attribute's target.

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
[Suppress("IDE0051")]
public class FactAttribute : Attribute { ... }

I wonder about class or assembly level attributes that target a member by type/name.
The only one I can think of just now is System.Web.PreApplicationStartMethod and it doesn't really apply there as it requires the target member to be public, but I think there are other instances, of a similar signature.
Maybe we could have something like this for that scenario

[Suppress("xxxxxx","yyyyyy","zzzzzz")]
[SupressTarget(nameof(PreApplicationStartMethod.Type),nameof(PreApplicationStartMethod.MethodName))]
public class PreApplicationStartMethodAttribute : Attribute { ... }

I appreciate that we are unlike to get this backported to net4x (although it would be nice), and that this specific attribute doesn't actually cause a problem, but I wanted to flag another scenario that this could be useful for.

Perhaps System.ComponentModel.DataAnnotations.MetadataTypeAttribute where the target type may throw nullability errors on members because it will never actually be instaciated.

[jjanuszkiewicz]

A generic SuppressAttribute would certainly be more flexible than an attribute which suppresses specifically IDE0051, but it would probably come with its own set of problems (e.g. you can't really suppress a compilation error, but you possibly can suppress a warning that was configured to be treated as an error).

Do you have examples of non-IDE0051 that it would be possibly used to suppress?

[CZEMacLeod]

In my case I have an attribute that marks config fields in a class that get set externally (pre MS.E.C and MS.E.O) - I get an IDE0044 for each saying it should be readonly as it is never set (it is through reflection).
I also get CC0057 (unused parameters) on methods marked with an attribute that need to match a signature, but in some cases doesn't need all the variables passed.
As mentioned before MetadataTypeAttribute doesn't play well with nullable - The Example shows a CS8618 (Non-nullable field 'Title' must contain a non-null value when exiting constructor. Consider declaring the field as nullable.) error in the targeted type of MetadataTypeAttribute.
Another (related) situation would be if a field had the RequiredAttribute attached where EF6/EFCore will initialize the field outside the constructor. Maybe the RequiredAttribute should inherit the RequiredMemberAttribute, or something so that if you create the object outside EF, and are using C# 11.0+ you have to set the field yourself, but that is a different issue.

[RikkiGibson]

You could consider writing a diagnostic suppressor which recognizes attributes either whose names are either baked-in or whose definitions are annotated with some attribute you know about, and suppresses any known "unused member" warnings on them.

Our own docs are not extremely complete here but this StackOverflow answer may be a good start.

[jjanuszkiewicz]

I know I can do this in a custom way, but wouldn't it be better if there was something provided by .NET itself that would allow authors of e.g. xUnit to make IDE0051 not be reported when their FactAttribute and TheoryAttribute are used? There are many libraries which use attributes to target/access members, why not have a means of letting them flag those members as not-unused?

I could give a shot at implementing something (I'd probably need to research how DynamicallyAccessedMembersAttribute works, as this would need to be similar), provided that there is interest in having this in .NET.