What are interceptors in C#, and what should a .NET developer know about them? Explain what problem they solve, how a source generator uses InterceptsLocation to redirect a specific call site, the InterceptorsNamespaces opt-in, where .NET already uses them (Request Delegate Generator, configuration binding generator), and why you should not hand-write them.

How I would answer this in an interview

Interceptors let a source generator redirect a specific method call in your source code to a different, generated method — at compile time, without you changing the call site. They exist to replace reflection-heavy framework APIs with generated, AOT-friendly code while keeping familiar APIs like app.MapGet(...) and config.Get<T>(). As a .NET developer, you mostly need to know they exist, how they're enabled, where .NET uses them, how to see what was intercepted, and why you shouldn't hand-write them.

1. What problem they solve

Some APIs are inherently dynamic: app.MapGet("/orders/{id}", (int id, IOrderService svc) => ...) must inspect the lambda's parameters to build request binding, and section.Get<SmtpOptions>() must discover properties to bind. Historically this used reflection and runtime code generation — slow start-up and incompatible with NativeAOT/trimming.

A source generator can generate specialised binding code for each call, but it can't modify your code to call the generated method. Interceptors close that gap: the generator emits a method marked with [InterceptsLocation] pointing at the exact call site, and the compiler rewrites that call to target the generated method instead.

2. How it works

// Your code (unchanged)
app.MapGet("/orders/{id:int}", (int id, IOrderService svc) => svc.FindAsync(id));

// Generated by the Request Delegate Generator (simplified)
file static class GeneratedRouteBuilderExtensions
{
    [InterceptsLocation(1, "zP3lV2...base64 location data...")]     // identifies the exact call
    internal static RouteHandlerBuilder MapGet0(this IEndpointRouteBuilder endpoints,
        [StringSyntax("Route")] string pattern, Delegate handler)
    {
        // generated, reflection-free parameter binding and response writing
    }
}

• The generator analyses the call (method, arguments, lambda signature) and emits an intercepting method with a compatible signature.
• [InterceptsLocation] identifies the call site. In early previews it took file path + line + column; current versions use a versioned, opaque encoding (InterceptsLocation(int version, string data)) produced by Roslyn APIs (GetInterceptableLocation), so it's robust to path differences and not meant to be written by hand.
• At compile time, the compiler substitutes the call target. At run time there's no lookup — it's an ordinary static call.

3. The opt-in

Interceptors must be enabled for the namespace containing the generated interceptor methods:

<PropertyGroup>
  <InterceptorsNamespaces>$(InterceptorsNamespaces);Microsoft.AspNetCore.Http.Generated</InterceptorsNamespaces>
</PropertyGroup>

(Earlier SDKs used InterceptorsPreviewNamespaces.) In practice, the .NET SDK and NuGet packages set this automatically when you enable their generators, so most developers never touch it. The opt-in prevents arbitrary generators from silently rewriting calls.

The feature started as experimental in C# 12/.NET 8 and was moved towards a supported model for source generator authors in the .NET 9 timeframe (with the new location format); it's not intended as a general language feature for application code.

4. Where .NET already uses them

• Request Delegate Generator (RDG) for minimal APIs — <EnableRequestDelegateGenerator>true</EnableRequestDelegateGenerator>, enabled automatically with PublishAot. It intercepts MapGet/MapPost/... calls and generates binding, validation and serialisation code.
• Configuration binding source generator — <EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator> (automatic for AOT/trimmed apps). Intercepts ConfigurationBinder.Bind/Get/GetValue and services.Configure<T>(section) / OptionsBuilder.Bind.
• Options validation, logging, and other generators in the ecosystem increasingly use them; third-party libraries (e.g. Dapper.AOT) use them to make connection.Query<T>(...) calls AOT-friendly.

5. How to inspect them

• Enable <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> and look for generated files containing [InterceptsLocation].
• In the IDE, "Go to Definition" on an intercepted call may navigate to the generated interceptor; debugger stepping enters generated code.
• Binary logs show generator outputs.

6. Why not to hand-write them

• The location encoding is opaque and versioned; hand-written locations break when code moves.
• They create spooky action at a distance: the code you read (MapGet) isn't what runs; only tools can tell you.
• They must be kept semantically identical to the original API, including edge cases — framework teams test this extensively.
• They're tied to exact call sites; refactoring silently changes which calls are intercepted.
• The design explicitly targets generators: a generator re-computes locations on every build, keeping them correct.

If you want to change behaviour for your own code, use normal techniques: wrappers, extension methods, decorators, DI, or a source generator that generates new APIs you call explicitly.

7. A production example

Publishing a minimal API with NativeAOT produced trimming warnings from reflection-based endpoint binding and configuration binding. Enabling the SDK's RDG and configuration binding generator (automatic with PublishAot) made the warnings disappear; inspecting the emitted files showed interceptors for each MapGet/MapPost and Configure<T> call. When a developer later wrote app.MapGet(route, handlerFromVariable) with a delegate stored in a variable, RDG couldn't analyse it and emitted a warning — we refactored to inline lambdas so the generator could intercept.