At what phase is the [Serializable] attribute considered by the .NET platform for (de)serialization behavior?

Introduction / Context:
The [Serializable] attribute marks a type as eligible for serialization by formatters (e.g., binary formatter, SOAP, custom serializers) and certain frameworks. Understanding when this attribute is honored clarifies its role in application behavior.

Given Data / Assumptions:

• We are considering the standard .NET serialization mechanisms that check for [Serializable].
• No custom source generators or compile-time transforms are assumed.

Concept / Approach:
While attributes are emitted into metadata at compile-time, the decision to serialize an object of a given type is made at run-time by the serializer. The serializer examines the type’s metadata using reflection to verify that [Serializable] is present (or that a custom contract applies).

Step-by-Step Solution:

Verification / Alternative check:
Attempt to serialize a class without [Serializable]; you will receive a run-time error. Add [Serializable] and the same code succeeds, demonstrating run-time inspection.

Why Other Options Are Wrong:
Compile-time/design-time/linking-time do not perform serialization; they only record metadata. The decisive check is performed by the run-time serializer.

Common Pitfalls:
Assuming that merely compiling with [Serializable] guarantees correct serialization; non-serializable members must be handled with [NonSerialized] or custom serialization patterns (ISerializable).

Final Answer:
Run-time