[Obsolete] never runs a single line of code. It just sits there, as data, until something else — the compiler, or your own reflection code — decides to go looking for it.

You've written [Obsolete("Use CalculateTotal instead")] above a method, and the compiler dutifully warned every caller. You've probably seen [Required] on a model property in an ASP.NET Core project, and somehow a form submission without that field gets rejected before your controller code even runs. Here's the thing that makes attributes genuinely strange the first time you think carefully about them: an attribute is not code that executes. [Obsolete] doesn't "do" anything by itself, in the sense of running instructions. It's a piece of data, permanently attached to a method, a class, a property — baked into the compiled assembly's metadata, sitting there inertly until some other piece of code (the compiler, a validation library, your own code) goes looking for it and decides what to do about it.

That's exactly why this lesson follows reflection directly: reflection is how something goes looking for an attribute. The two are a matched pair — attributes are the declarative metadata; reflection is the mechanism that reads it back.

In this lesson: what attributes actually are, familiar built-in ones you've already used, writing your own custom attribute, restricting where it can apply with AttributeUsage, and a full worked example reading a custom attribute back via reflection to enforce a real rule.

What Is It?

The Simple Explanation

An attribute is a labeled sticky note you attach to a class, method, property, or parameter in your source code, written in square brackets: [Obsolete], [Serializable], [Required]. The note itself does nothing on its own — it just sits there, permanently attached, as part of the compiled type's metadata. What gives it meaning is entirely up to whoever later reads that note and decides to act on it.

The Technical Definition

An attribute is an instance of a class deriving (directly or indirectly) from System.Attribute, applied to a code element — an assembly, type, method, property, field, or parameter — using [AttributeName(...)] syntax. The C# compiler stores the attribute and its constructor arguments as part of the target element's metadata in the compiled assembly. Nothing about applying an attribute causes any code to run at the point of application; consuming its meaning is entirely the responsibility of whatever tool later reads it back — most commonly via reflection, though the C# compiler itself also reads certain well-known attributes directly (like [Obsolete], to emit a warning).

Why Does It Exist?

The Problem

Some information about a type or member is genuinely useful to record, but doesn't belong in the type's actual logic. "This method is deprecated." "This property is required for a form to be valid." "This class can be converted to a stream of bytes." "This method is a unit test the runner should discover and execute." None of that is behavior the type performs itself — it's metadata about the type, meant for some external tool to act on. Before attributes, expressing this kind of information meant separate configuration files, naming conventions the tool had to guess at, or — worse — no standard way to express it at all, leaving every framework to invent its own bespoke convention.

The Need

Developers needed a standard, language-level way to attach structured, typed metadata directly to the code element it describes — kept right next to the code (rather than in a separate file that inevitably drifts out of sync), discoverable uniformly by any tool via reflection, and validated by the compiler like any other C# code (real types, real constructors, real compile errors for a typo).

The Solution

Attributes. A single, uniform mechanism — an ordinary class deriving from Attribute, applied with bracket syntax — that the entire .NET ecosystem shares. The compiler itself is just the first, most privileged consumer: it specifically knows how to react to a handful of attributes like [Obsolete]. Everything else — validation, serialization, dependency injection, test discovery — is built by libraries reading attributes back through the exact reflection mechanism from the previous lesson.

Big Picture

How It Works

public class RangeAttribute : Attribute
{
    public int Min { get; }
    public int Max { get; }
    public RangeAttribute(int min, int max) { Min = min; Max = max; }
}

[AttributeUsage(AttributeTargets.Property | AttributeTargets.Field, AllowMultiple = false)]
public class RangeAttribute : Attribute
{
    public int Min { get; }
    public int Max { get; }
    public RangeAttribute(int min, int max) { Min = min; Max = max; }
}

public class Product
{
    [Range(0, 1000)]
    public int Quantity { get; set; }
}

PropertyInfo prop = typeof(Product).GetProperty("Quantity")!;
RangeAttribute? range = prop.GetCustomAttribute<RangeAttribute>();
if (range is not null)
{
    Console.WriteLine($"Quantity must be between {range.Min} and {range.Max}");
}

Simple Example

Built-in attributes you've very likely already written, now seen for what they actually are:

[Obsolete("Use CalculateTotal(Order) instead — this overload ignores tax.")]
public decimal CalculateTotal(decimal subtotal) => subtotal;
// The COMPILER itself reads this attribute back and emits a warning at every call site —
// no reflection involved for this specific case; the compiler is a privileged, built-in consumer.

[Serializable]
public class LegacySettings { public string Theme = "Dark"; }
// A marker for the (legacy) BinaryFormatter serialization infrastructure to check via reflection
// before attempting to serialize an instance of this type.

Meaning: Two completely different consumers reading the exact same kind of thing — a compile-time consumer (the C# compiler, for [Obsolete]) and a runtime consumer (reflection-based serialization infrastructure, for [Serializable]). The attribute mechanism itself doesn't care which one reads it; that's the point of it being a general-purpose, uniform system.

Real-World Example

A full, working validation attribute — genuinely close to how ASP.NET Core's own data-annotation attributes ([Required], [Range], [StringLength]) work internally: a custom attribute class, applied to model properties, enforced entirely through reflection at runtime.

[AttributeUsage(AttributeTargets.Property, AllowMultiple = false)]
public class RangeAttribute : Attribute
{
    public int Min { get; }
    public int Max { get; }
    public RangeAttribute(int min, int max) { Min = min; Max = max; }
}

public class Product
{
    public string Name { get; set; } = "";

    [Range(0, 1000)]
    public int Quantity { get; set; }

    [Range(1, 5)]
    public int Rating { get; set; }
}

public static class Validator
{
    public static List<string> Validate(object instance)
    {
        var errors = new List<string>();
        Type type = instance.GetType();

        foreach (PropertyInfo prop in type.GetProperties())
        {
            var range = prop.GetCustomAttribute<RangeAttribute>();
            if (range is null) continue; // this property has no [Range] attribute — nothing to check

            var value = prop.GetValue(instance);
            if (value is int intValue && (intValue < range.Min || intValue > range.Max))
            {
                errors.Add($"{prop.Name} must be between {range.Min} and {range.Max}, but was {intValue}.");
            }
        }
        return errors;
    }
}

var product = new Product { Name = "Widget", Quantity = 1500, Rating = 3 };
var errors = Validator.Validate(product);
// errors: ["Quantity must be between 0 and 1000, but was 1500."]
// Rating (3) is within [1, 5], so it produces no error — and Name has no [Range] attribute at all, so it's skipped entirely

Notice what Validator does not contain: any mention of Product, Quantity, or Rating anywhere in its code. It's entirely generic — it would validate any class with any number of [Range]-attributed int properties, unchanged. This is the exact combination the whole lesson has been building toward: attributes supply the declarative "what the rule is," and reflection supplies the generic "go find and enforce it."

Analogy

Under the Hood

Common Confusion

1. "Attributes execute code" — no, they're pure metadata; a consumer executes code

This is the single most important thing to internalize: applying [Range(0, 1000)] has zero runtime effect until something else — a validator, the compiler, a serializer — deliberately goes looking for it. Writing an attribute with no consumer anywhere in the program compiles perfectly fine and does, quite literally, nothing.

2. Constructor arguments and named-property arguments are two different things in attribute syntax

[Range(0, 1000)] uses positional constructor arguments (matching RangeAttribute's constructor exactly, in order). Some attributes also support [SomeAttribute(SomeProperty = value)] syntax — setting a public property on the attribute instance after construction, by name — which is why you'll sometimes see attribute usages mixing both styles, like [Range(0, 1000, ErrorMessage = "Out of range")]. Both are compiled the same way: a constructor call, optionally followed by property assignments.

3. Attribute constructor arguments must be compile-time constants

You can't write [Range(GetMinFromConfig(), 1000)] — attribute constructor arguments must be values the compiler can fully resolve at compile time (literals, const fields, typeof() expressions, and a few similar cases), never the result of calling an arbitrary method. This follows directly from attributes being baked into static metadata rather than executed — there's no "runtime" at the point an attribute is applied to compute a dynamic value from.

Common Mistakes

Mistake 1 — Writing a custom attribute and expecting it to "just work" without a consumer

Applying [Range(0, 1000)] to a property and being surprised when an out-of-range value doesn't get rejected anywhere. An attribute is inert without something reading it — either use a framework that already knows how to consume it (data-annotation attributes with ASP.NET Core model binding, for instance), or write the consuming reflection code yourself, as shown in the Real-World Example.

Mistake 2 — Forgetting [AttributeUsage] and letting the attribute be applied in nonsensical places

A validation attribute meant only for properties, with no [AttributeUsage] restriction, accidentally applied to a class or a method — compiling cleanly, then failing to do anything meaningful (or worse, throwing at runtime when a consumer assumes it's always on a property).

Always specify [AttributeUsage(AttributeTargets.X)] deliberately — it turns a class of misuse into a compile error instead of a silent or runtime surprise.

Mistake 3 — Calling GetCustomAttribute<T>() repeatedly in a hot path without caching

Reflecting for the same attribute on the same member on every request, in a loop that could reasonably cache the result once. This is exactly the reflection performance trap from the previous lesson, now specifically about attribute lookups (which construct a new attribute instance from metadata each time, per "Under the Hood").

Look attributes up once — typically at startup, or the first time a given type is encountered — and cache the result for reuse, exactly as the reflection lesson recommended for member lookups generally.

When Should I Use It?

• Write a custom attribute when you have declarative metadata that genuinely belongs next to the code element it describes, and you (or a library) will consume it via reflection — validation rules, serialization hints, framework-specific markers (route metadata, test categorization).
• Reach for a built-in attribute first whenever one already exists for your need — [Obsolete], the data-annotation validation attributes, [Required]-style ones — rather than reinventing an equivalent.
• Don't use attributes for information that's actually behavior, or that changes at runtime — attribute arguments must be compile-time constants, and the attribute itself is fundamentally static metadata, not a place to store dynamic state.

Mental Model

Key Takeaway

Check Your Understanding

You've seen what attributes are, how to write and restrict a custom one, and how reflection is what gives an attribute meaning. Let's check your understanding.

You now understand that attributes are pure metadata — and exactly how reflection is what gives them any real effect at all. Next up: source generators, a compile-time alternative to the reflection-at-runtime pattern you've just built.

dotnetmadeeasy.com — Learn C# and .NET, the right way.