[API Proposal]: Adding a Virtual `SetTarget` Method to `System.Attribute` for Efficient Target Association

[ActivistInvestor]

Background and motivation

Background / Summary

Currently, attributes in .NET do not have direct access to the object they are applied to at the time of instantiation. This limitation requires developers to use reflection-based workarounds, which introduce significant runtime overhead.

This proposal suggests adding a virtual method to System.Attribute:

public abstract class Attribute
{
    public virtual void SetTarget(object target) { }
}

When an attribute is applied to a target (class, method, property, etc.), the runtime should invoke SetTarget(target) automatically, passing the instance of the target where the attribute was applied.

Motivation & Use Case

Many attributes in .NET would benefit from knowing the target they are associated with at the time of instantiation, without requiring expensive reflection scans across assemblies.

Consider the following real-world example:

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
public class PerDatabaseAttribute : Attribute
{
    private Type targetType;

    public override void SetTarget(object target)
    {
        if (target is Type type)
        {
            targetType = type;
        }
    }
}

// Usage
[PerDatabase]
public class MyDatabaseClass { }

With this change, the attribute automatically knows its target at runtime, eliminating the need for reflection-based registration and scanning, which adds significant performance overhead in large applications.

Current Workaround (Inefficient Reflection-Based Approach)

Currently, developers must scan assemblies and manually associate attributes with their targets, and must be performed for every currently-loaded assembly in the AppDomain:

public static void RegisterAttributes(Assembly assembly)
{
    foreach (var type in assembly.GetTypes())
    {
        var attr = type.GetCustomAttribute<PerDatabaseAttribute>();
        if (attr != null)
        {
            // Manually associate the attribute with the target type
        }
    }
}

Drawbacks of This Approach:

• ❌ Performance Impact: Reflection-based type scanning is slow, especially in large applications with many assemblies.
• ❌ No Immediate Association: The attribute does not "know" its target upon instantiation.
• ❌ Complexity: Developers must manually track and register attributes instead of relying on the runtime.

By adding SetTarget(object target), the runtime eliminates the need for costly reflection, allowing attributes to immediately recognize their targets.

Proposed Implementation

The .NET runtime would be modified so that whenever an attribute is applied, the runtime automatically calls SetTarget(target).

Example Behavior:

Class-Level Attribute:

[MyCustom]
public class ExampleClass { }

• The runtime instantiates MyCustomAttribute
• It then calls SetTarget(typeof(ExampleClass))
• The attribute immediately knows its target

Method-Level Attribute:

public class MyClass
{
    [MyAttribute]
    public void MyMethod() { }
}

• The runtime calls SetTarget(MethodInfo("MyMethod"))

Property-Level Attribute:

public class Example
{
    [MyAttribute]
    public string Name { get; set; }
}

• The runtime calls SetTarget(PropertyInfo("Name"))

Backward Compatibility & Risks

• ✅ Non-Breaking Change: This change does not break existing code, as it only introduces a new virtual method.
• ✅ Optional Override: If SetTarget is not overridden, the default implementation does nothing.
• ✅ Minimal Runtime Impact: Attributes are already instantiated when metadata is processed, so the additional method call is negligible.
• ✅ Non-functional in reflection-only load contexts:

Alternatives Considered

1. Compiler-Based Solutions:

   • This would require modifying the C# compiler to generate additional code when applying attributes.
   • More complex and less flexible than a runtime enhancement.

2. Custom Attribute Registries:

   • Developers can create their own registries and track attributes manually.
   • Still requires reflection and assembly scanning, which does not scale well.

Conclusion

This proposal would improve performance, usability, and runtime efficiency by allowing attributes to be aware of their targets without costly reflection scans. It is a minimal, non-breaking change that significantly benefits developers working with attributes in .NET.

---

API Proposal

namespace System.Collections.Generic;

public class MyFancyCollection<T> : IEnumerable<T>
{
    public void Fancy(T item);
}

API Usage

// Fancy the value
var c = new MyFancyCollection<int>();
c.Fancy(42);

// Getting the values out
foreach (var v in c)
    Console.WriteLine(v);

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

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

[wasabii]

There's a number of what seem like fundamental misunderstandings of what attributes are in here...... but beyond that, I am having a hard time even conceptualizing the performance benefits that could be gained. How is some other code (managed) calling a SetTarget method any different from just keeping the instance of the object you invoked GetCustomAttribute on in the first place?

For instance, in the example:

public static void RegisterAttributes(Assembly assembly)
{
    foreach (var type in assembly.GetTypes())
    {
        var attr = type.GetCustomAttribute<PerDatabaseAttribute>();
        if (attr != null)
        {
            // HERE
        }
    }
}

Right at HERE you have the type in the type variable. In pretty much the exact time and place at which the attribute was instantiated in the first place.

[colejohnson66]

The purpose of attributes is to annotate something. They're markers, and markers shouldn't need to know where they're used. Also, the proposal's logic doesn't make sense. Why is "find all types with XAttribute" bad, but "find all XAttribute with Type=SomeType" better? Both involve reflection.

[jkoritzinsky]

@ActivistInvestor I think there's a fundamental piece of how custom attributes work in the runtime that's missing here. The following statement is false:

Attributes are already instantiated when metadata is processed, so the additional method call is negligible.

Custom attribute objects aren't instantiated until someone asks for them via reflection. Therefore, you can't have an attribute have a SetTarget method that auto-registers itself with what it is applied to at runtime to avoid doing the "for all types in this assembly, get the custom attributes", as you need to do the latter to have the Attribute-derived objects created in the first place.

[ActivistInvestor]

@ActivistInvestor I think there's a fundamental piece of how custom attributes work in the runtime that's missing here. The following statement is false:

Attributes are already instantiated when metadata is processed, so the additional method call is negligible.

Custom attribute objects aren't instantiated until someone asks for them via reflection. Therefore, you can't have an attribute have a SetTarget method that auto-registers itself with what it is applied to at runtime to avoid doing the "for all types in this assembly, get the custom attributes", as you need to do the latter to have the Attribute-derived objects created in the first place.

Yes, and given that, the manner of achieving the underlying objective in this proposal will not avoid the overhead of examining every type in every assembly to discover all of the types having a certain attribute applied to them. Something I neglected to consider.

Regarding "The purpose of attributes is to annotate something.", I'm not sure what that has to do with finding all elements that have a certain 'annotation' attached to them.

The problem is fairly simple. In my use case, there are > 100 assemblies loaded, each containing which may contain up to a few hundred types. And, more assemblies are loaded after my search for all types with a specific attribute applied to them (requiring an AssemblyLoad event handler).

The process of finding all elements with a specific attribute applied to them is taking far too long. I considered using assembly-level attributes with the element as a parameter, but it isn't ideal, mostly because the attribute isn't annotating the assembly, but rather something in the assembly (type, method, etc).

So, perhaps what may be a better proposal, is to allow assembly-level attributes to be applied to Types, Members, etc., with an implicit parameter representing the element the attribute was applied to.

EDIT: clarified intent

[AttributeUsage(AttributeTargets.Assembly, AllowMultiple = true)]
public class PerDatabaseClassAttribute : System.Attribute
{
   Type target;
   
   public PerDatabaseClassAttribute([AttributeTarget] ICustomAttributeProvider target)
   {
      if(target is Type)
         this.target = target;
   }                                
}

/// Theoretical usage:

[assembly: PerDatabaseClass]
public class MyClass
{
}

That should require no runtime changes, as everything is done by the compiler, and it's actually quite simple. The [AttributeTarget] attribute (which may not even be necessary) tells the compiler to pass 'typeof(MyClass)' as the target parameter. It's still an assembly-level attribute, but it can be applied to other types of targets and uses the target as a parameter.

So, if you look at the disassembled code, you'd see

  [assembly: PerDatabaseClass(typeof(MyClass))]

[jkoritzinsky]

I would recommend writing a source generator that generates assembly-level attributes that point to the various members that you need to look up.

Writing a generator that generates code based on applied attributes can be done efficiently and then you could make whatever shape you want work without needing language or runtime changes (your proposal would likely require both)

[ActivistInvestor]

Many of the entities that I work with have banned Source generators for anything other than things like generating code files from a template.

They simply don't believe that using a generator to Implement a proprietary fork of a programming language is an appropriate use.

[huoyaoyuan]

Attribute instances are not interesting to talk about. They are just mechanical projections of attribute data.

The problem in this post is about inefficiency to find certain category of attribute data, for example all applications of certain attribute.

The proposed approach is to build a list of attributes in interest in the form of assembly attributes, which is a centralized list to retrieve. This is a tricky, inefficient and complicated transform that unsuitable for canonical support.

The correct API to work with in this case is CustomAttributeData, not Attribute. The missing steps that matches how CLR resolves attributes would be:

• Retrieve all CustomAttributeData within an assembly. Currently there're only APIs to work with this for a given target, which makes the searching inefficient, because all potential but not interesting target has to be processed.
• Retrieve the target of CustomAttributeData. Currently CAData can only be retrieved with given target, so there's no support for the opposite. It may be exposed as RuntimeHandle instead of reflection objects because the latter is much heavier.
• Optionally, construct attribute instances from CustomAttributeData. This is often not required when there's no interesting payload.

Then, the efficient workflow to retrieve applications of certain attributes would be:

foreach (var caData in assembly.GetAllCustomAttributesData())
{
    if (caData.TargetKind == AttributeTargets.Class && caData.AttributeType == typeof(MyAttribute))
    {
        Register(caData.Target.AsType(), caData.CreateAttributeInstance<MyAttribute>().SomeOption);
    }
}

[ActivistInvestor]

I've used CustomAttributeData in reflectionly-only load contexts for scraping attribute data from assemblies, but in the case of Assembly attributes, the overhead difference between using CustomAttributeData and Attributes is negligible, as there aren't hundreds of assembly attributes that must be processed.

public static partial class ReflectionExtensions
{
   public static List<Type> GetAttributeArguments(
      this Assembly asm, 
      Type attributeType, 
      int index)
   {
      List<Type> result = new List<Type>();
      var data = asm.GetCustomAttributesData();
      for(int i = 0; i < data.Count; i++)
      {
         var cad = data[i];
         if(attributeType.IsAssignableFrom(cad.AttributeType))
         {
            result.Add((Type) cad.ConstructorArguments[index].Value);
         }
      }
      return result;
   }
}

It should be noted that when using CustomAttributeData to get a Type argument, it leads to a call to RuntimeTypeHandle.GetTypeByNameUsingCARules(), which involves more work than is needed for arguments of simple types.

However, whether CustomAttributeData is used or not, that doesn't address the issue of applying attributes to Types or members verses applying them to the containing assembly, and making the annotated type/member an argument, which for me, is the crux of the problem.

[KalleOlaviNiemitalo]

For the originally proposed public virtual void SetTarget(object target), I wonder whether object target here should be typeof(Base<>), typeof(Base<int>), or typeof(Derived<int>):

using System;
using System.Reflection;

[AttributeUsage(AttributeTargets.All, Inherited = true)]
public class HuhAttribute : Attribute
{
    public override void SetTarget(object target)
    {
        this.Target = target;
    }
    
    public object? Target { get; private set; }
}

[Huh]
class Base<T>
{
}

class Derived<T> : Base<T>
{
}

class Program
{
    static void Main()
    {
        Console.WriteLine(typeof(Derived<int>).GetCustomAttribute<HuhAttribute>()!.Target);
    }
}

[ActivistInvestor]

The original proposal doesn't work, because Attributes aren't instantiated until requested. That was a ChatGPT-generated proposal that I failed check for accuracy.

The only hope for my objective is enabling assembly attributes to be applied to other types of targets with a transformation done by the compiler to use the annotated target as an argument to the assembly-level attribute.

[huoyaoyuan]

but in the case of Assembly attributes, the overhead difference between using CustomAttributeData and Attributes is negligible

Currently the only way to retrieve the S.R.CAData type is to use the same workflow of getting attribute instances. Assembly.GetCustomAttributesData() gets attributes applied to the assembly, not attribute applications contained in the assembly. The pseudo GetAllCustomAttributesData method is the key part of efficiency.

The only hope for my objective is enabling assembly attributes to be applied to other types of targets with a transformation done by the compiler to use the annotated target as an argument to the assembly-level attribute.

This will definitely non happen. Assembly-targeting attributes are still a high-level concept that with overhead and duplicated payload.