Each section covers the problem, the API, a runnable example with its output, and the caveats I hit while testing. Everything was run on .NET 11 RC1, and the complete sample application is on GitHub: github.com/ahmetcelik05/dotnet11-features-demo.

Where .NET 11 stands today. .NET 11 RC1 shipped on September 8, 2026 with a go-live license. General availability is planned for November 10, 2026, and .NET 11 is a Standard Term Support (STS) release, supported until November 9, 2028. The APIs below are in RC1, but as you will see in the cache metrics section, details can still move before GA.

Short on time? The whole article in one table:

| Feature | What is new in .NET 11 | The catch I found on RC1 | |---|---|---| | LINQ joins | FullJoin, plus Join/GroupJoin overloads without a result selector | GroupJoin returns IGrouping, not a tuple; value-type default hides "no match" | | Async validation | AsyncValidationAttribute, IAsyncValidatableObject, Validator.*Async | Synchronous Validator calls on the same model throw | | Cache metrics | MemoryCache publishes an OpenTelemetry meter when TrackStatistics is on | The hit/miss tag name is being renamed before GA | | Tracing rules | AddTracing with rules from code or configuration, live reload | Nothing is enabled by default, Sample is mandatory, OpenTelemetry is unaffected |

The sample application

The sample is a small minimal API called OrdersDemo. It has no UI; you drive it with curl and watch the console. Each endpoint exists to demonstrate one feature, and the features also interact: placing an order runs async validation and then produces a traced activity.

Each feature lives in its own folder under Features and registers itself through Add... and Map...Endpoints extensions, so Program.cs is only a composition root.

1. LINQ FullJoin and selector-less Join/GroupJoin

The problem

.NET 10 added LeftJoin and RightJoin. A full outer join was still missing, so if you needed "everything from both sides, matched where possible" you wrote a left join, a right join, and a Concat or Union, or a GroupJoin/SelectMany/DefaultIfEmpty combination in each direction. Most of us have a FullOuterJoin extension method somewhere in a Utils folder, copied from a Stack Overflow answer. It works, right up until a reconciliation report is wrong.

A smaller annoyance: Join and GroupJoin always required a result selector. In most call sites that selector was (a, b) => (a, b), typed for the hundredth time.

The API

.NET 11 adds FullJoin and selector-less overloads of Join and GroupJoin. They exist on Enumerable, Queryable, and AsyncEnumerable. The new overloads take an optional IEqualityComparer<TKey> as a trailing parameter, and the same optional comparer is available on LeftJoin and RightJoin.

// Full outer join, returning tuples
IEnumerable<(TOuter? Outer, TInner? Inner)> FullJoin<TOuter, TInner, TKey>(
    this IEnumerable<TOuter> outer, IEnumerable<TInner> inner,
    Func<TOuter, TKey> outerKeySelector, Func<TInner, TKey> innerKeySelector,
    IEqualityComparer<TKey>? comparer = null);

// Full outer join with your own projection
IEnumerable<TResult> FullJoin<TOuter, TInner, TKey, TResult>(
    this IEnumerable<TOuter> outer, IEnumerable<TInner> inner,
    Func<TOuter, TKey> outerKeySelector, Func<TInner, TKey> innerKeySelector,
    Func<TOuter?, TInner?, TResult> resultSelector,
    IEqualityComparer<TKey>? comparer = null);

Example: reconciling two stock systems

The reconciliation endpoint compares stock levels reported by a warehouse and by an ERP system. A SKU can exist in either system or both, and when it exists in both the quantities may disagree. Three pair shapes, four statuses, one full outer join, and pattern matching on the tuple expresses all of it directly:

internal sealed class ReconciliationService : IReconciliationService
{
    public IReadOnlyList<ReconciliationRow> Reconcile(IEnumerable<WarehouseStock> warehouse, IEnumerable<ErpStock> erp)
    {
        var pairs = warehouse.FullJoin(
            erp,
            w => w.Sku,
            e => e.Sku,
            StringComparer.OrdinalIgnoreCase);

        return [.. pairs.Select(ToRow)];
    }

    private static ReconciliationRow ToRow((WarehouseStock? Warehouse, ErpStock? Erp) pair) => pair switch
    {
        (null, { } erp) => new ReconciliationRow(erp.Sku, ReconciliationStatus.MissingInWarehouse, null, erp.Quantity),
        ({ } warehouse, null) => new ReconciliationRow(warehouse.Sku, ReconciliationStatus.MissingInErp, warehouse.Quantity, null),
        ({ } warehouse, { } erp) when warehouse.Quantity != erp.Quantity
            => new ReconciliationRow(warehouse.Sku, ReconciliationStatus.QuantityMismatch, warehouse.Quantity, erp.Quantity),
        ({ } warehouse, { } erp) => new ReconciliationRow(warehouse.Sku, ReconciliationStatus.Ok, warehouse.Quantity, erp.Quantity),
        (null, null) => throw new UnreachableException("FullJoin never yields an empty pair."),
    };
}

Calling GET /reconciliation with three warehouse rows (LAPTOP-15, mouse-01, CHAIR-ERG) and three ERP rows (LAPTOP-15, MOUSE-01, DESK-STD) returns four rows:

[
  { "sku": "LAPTOP-15", "status": "Ok",                 "warehouseQuantity": 5,    "erpQuantity": 5 },
  { "sku": "mouse-01",  "status": "QuantityMismatch",   "warehouseQuantity": 0,    "erpQuantity": 3 },
  { "sku": "CHAIR-ERG", "status": "MissingInErp",       "warehouseQuantity": 7,    "erpQuantity": null },
  { "sku": "DESK-STD",  "status": "MissingInWarehouse", "warehouseQuantity": null, "erpQuantity": 2 }
]

Note the second row: mouse-01 and MOUSE-01 matched only because of the StringComparer.OrdinalIgnoreCase argument. Without it they would be two separate "missing" rows, which is exactly what happens in real life when two systems disagree on casing and nobody passes a comparer.

What the tests showed about the semantics

The documentation describes the join operators but not their ordering or null behaviour, so I wrote tests against RC1 to pin down what you can observe today.

Output order follows the outer sequence, with unmatched inner elements appended at the end: for outer = [1, 2, 3] and inner = [3, 4, 2], FullJoin yields (1, 0), (2, 2), (3, 3), (0, 4). Treat that as an implementation detail, not a guarantee. Null keys never match each other; a null key on either side produces an unmatched row, the same way NULL = NULL is false in SQL.

Look at that (1, 0) again. It means "outer 1 had no partner", but 0 is also a perfectly valid inner value, and nothing in the tuple tells you which. When the element type is a struct, use nullable elements or the resultSelector overload so you can tell the two apart.

One more surprise: the selector-less GroupJoin does not return tuples. The "What's new" page calls the new overloads "tuple-returning", which is true for Join, but GroupJoin returns IEnumerable<IGrouping<TOuter, TInner>> with the outer element as the Key and the matching inner elements as the group.

var grouped = customers
    .GroupJoin(orders, c => c.Id, o => o.CustomerId)
    .Select(group => (group.Key.Name, Count: group.Count()));

When to use it

Use FullJoin whenever you need a reconciliation, a diff, or a "who did not show up on the other list" report over two in-memory sequences. Keep the memory profile in mind: the inner sequence is fully materialised into a lookup, so put the smaller sequence on the inner side. Against a database, EF Core 11 translates Queryable.FullJoin to FULL JOIN on SQL Server. EF Core 11 is still in preview at the time of writing, so check the provider you use before relying on it.

That covers combining data that is already in memory. The next feature is about the data on its way in: the order request that arrives at POST /orders and has to be checked against systems you can only reach asynchronously.

2. Asynchronous validation with DataAnnotations

The problem

ValidationAttribute.IsValid is synchronous. Rules that need I/O, such as "is this e-mail registered", "does this VAT number exist in the tax registry", or "is there enough stock", either blocked a thread with .GetAwaiter().GetResult() or moved out of the validation layer entirely. Once they move, their error messages no longer flow through ValidationResult and ValidationProblemDetails, and every consumer of the model has to remember to call them. You know the result: [Required] failures arrive as a tidy 400 with a field name, "customer not found" arrives as a 500 from the service layer, and the front-end team asks why.

The API

.NET 11 adds an async path to System.ComponentModel.DataAnnotations with three pieces:

• AsyncValidationAttribute, an abstract base class with IsValidAsync(object?, ValidationContext, CancellationToken) returning Task<ValidationResult?>.
• IAsyncValidatableObject, with ValidateAsync(ValidationContext, CancellationToken) returning IAsyncEnumerable<ValidationResult>.
• Async counterparts on Validator: ValidateObjectAsync, TryValidateObjectAsync, ValidatePropertyAsync, TryValidatePropertyAsync, ValidateValueAsync, and TryValidateValueAsync.

One design point matters before you write your first rule: the synchronous members are still required. IsValid(object?, ValidationContext) is abstract on AsyncValidationAttribute, and IAsyncValidatableObject inherits IValidatableObject.Validate. The framework samples throw from both so that accidental synchronous validation fails loudly instead of silently skipping the rule, and that is the approach I take below.

Example: an async attribute and an async object rule

The order request in the sample uses both mechanisms. The attribute checks that the customer exists in a directory:

[AttributeUsage(AttributeTargets.Property)]
public sealed class RegisteredCustomerAttribute : AsyncValidationAttribute
{
    protected override ValidationResult? IsValid(object? value, ValidationContext validationContext) =>
        throw new InvalidOperationException(
            $"{nameof(RegisteredCustomerAttribute)} only supports asynchronous validation. Use Validator.ValidateObjectAsync.");

    protected override async Task<ValidationResult?> IsValidAsync(
        object? value, ValidationContext validationContext, CancellationToken cancellationToken)
    {
        if (value is not string email || string.IsNullOrWhiteSpace(email))
        {
            return ValidationResult.Success; // [Required] owns the empty-value case
        }

        var directory = validationContext.GetRequiredService<ICustomerDirectory>();

        return await directory.ExistsAsync(email, cancellationToken)
            ? ValidationResult.Success
            : new ValidationResult($"'{email}' is not a registered customer.", [validationContext.MemberName!]);
    }
}

The model itself checks stock for every line, a rule that spans properties:

public sealed class CreateOrderRequest : IAsyncValidatableObject
{
    [Required, EmailAddress, RegisteredCustomer]
    public string CustomerEmail { get; init; } = string.Empty;

    [MinLength(1)]
    public IReadOnlyList<OrderLine> Lines { get; init; } = [];

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext) =>
        throw new InvalidOperationException($"Validate {nameof(CreateOrderRequest)} with {nameof(ValidateAsync)}.");

    public async IAsyncEnumerable<ValidationResult> ValidateAsync(
        ValidationContext validationContext,
        [EnumeratorCancellation] CancellationToken cancellationToken = default)
    {
        var inventory = validationContext.GetRequiredService<IInventoryService>();

        foreach (var line in Lines)
        {
            var available = await inventory.GetAvailableQuantityAsync(line.Sku, cancellationToken);
            if (available < line.Quantity)
            {
                yield return new ValidationResult(
                    $"Only {available} unit(s) of '{line.Sku}' are in stock.", [nameof(Lines)]);
            }
        }
    }
}

Both rules resolve their dependencies from the ValidationContext, which means the context has to be created with a service provider. Minimal APIs do that for you; when you call Validator yourself, pass one in:

var context = new ValidationContext(request, serviceProvider, items: null);
var results = new List<ValidationResult>();

var isValid = await Validator.TryValidateObjectAsync(
    request, context, results, validateAllProperties: true, cancellationToken);

Running it through a minimal API

builder.Services.AddValidation() has been available since .NET 10; it makes minimal API endpoints validate their parameters before the handler runs. What is new in .NET 11 is that the same call now runs the async rules as well, concurrently where possible. Posting an unknown customer:

curl -X POST http://localhost:5028/orders -H "Content-Type: application/json" \
     -d '{"customerEmail":"nobody@example.com","lines":[{"sku":"MOUSE-01","quantity":2}]}'

{
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": { "CustomerEmail": ["'nobody@example.com' is not a registered customer."] }
}

Only the attribute error is reported. That is by design: object-level validation runs after all property rules pass, so the stock check never executed. Post the same order with a registered customer and you get the object-level message instead:

{
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": { "Lines": ["Only 0 unit(s) of 'MOUSE-01' are in stock."] }
}

How the pipeline behaves

From reading Validator and confirming with tests, the async path works like this:

1. [Required] is evaluated first for each property and short-circuits that property on failure.
2. Synchronous attributes on a property run next. Async attributes run only if all synchronous ones pass, and they run concurrently.
3. Type-level attributes follow, then IAsyncValidatableObject.ValidateAsync.
4. Pass null for the results collection and validation stops at the first failure; pass a collection and it keeps going and collects everything.
5. The cancellation token flows into every async rule.

The migration trap

So what happens when an older code path calls the synchronous Validator.TryValidateObject on a model that now carries an async attribute? Does it quietly skip the rule? No. It has no special handling for async attributes at all: it calls your synchronous IsValid, and if you followed the framework guidance, that throws:

System.InvalidOperationException: RegisteredCustomerAttribute only supports asynchronous validation. Use Validator.ValidateObjectAsync.

On purpose, and rightly so. But it makes adding an async attribute a breaking change for every caller that still validates synchronously, so find those callers before you decorate a shared model. Minimal APIs and Blazor forms use the async path in .NET 11; MVC controllers are not listed in the RC1 notes and the public design notes defer them to follow-up work, so treat MVC as a synchronous caller until the docs say otherwise.

Validation decides whether a request gets in. The next two features are about seeing what the application does once it is in, starting with the cache that every request touches.

3. Built-in OpenTelemetry metrics for MemoryCache

The problem

IMemoryCache has had GetCurrentStatistics() for a while, but turning it into metrics meant polling it and publishing your own Meter. Every team wrote a slightly different decorator, and none of them agreed on instrument names. The decorator then quietly stopped being registered after a refactor, and the "cache hit ratio" panel on the dashboard showed a flat line for three weeks before anyone noticed.

The API

Do you need an extra package or an adapter for this? No. In .NET 11, MemoryCache publishes a meter named Microsoft.Extensions.Caching.Memory.MemoryCache as soon as you opt in with TrackStatistics = true. The new MemoryCacheOptions.Name becomes a dotnet.cache.name tag so that multiple caches can share a process, and a new constructor overload accepts an IMeterFactory for per-instance meters. MemoryCacheStatistics gained TotalEvictions to back the new eviction counter.

RC1 publishes these four instruments, captured with a MeterListener in the test suite:

| Instrument | Type | Unit | Tags | |---|---|---|---| | dotnet.cache.requests | ObservableCounter | {request} | dotnet.cache.request.type = hit / miss | | dotnet.cache.evictions | ObservableCounter | {eviction} | | | dotnet.cache.entries | ObservableUpDownCounter | {entry} | | | dotnet.cache.estimated_size | ObservableGauge | By | |

Example: a read-through product catalog

In most applications the opt-in is a one-liner: services.AddMemoryCache(options => options.TrackStatistics = true). In the demo the cache is configured through an IConfigureOptions<MemoryCacheOptions> instead, so that the demo-specific settings live next to the feature:

public void Configure(MemoryCacheOptions options)
{
    options.TrackStatistics = true;        // opt-in: without this no instruments are published
    options.Name = CacheName;              // becomes the dotnet.cache.name tag
    options.SizeLimit = productCache.Value.SizeLimit;
    options.CompactionPercentage = productCache.Value.CompactionPercentage;
}

internal sealed class CachedProductCatalog(IMemoryCache cache, IProductStore store) : IProductCatalog
{
    public Task<Product?> GetAsync(string sku, CancellationToken cancellationToken) =>
        cache.GetOrCreateAsync(sku, entry =>
        {
            entry.SetSize(1); // required when MemoryCacheOptions.SizeLimit is set
            entry.SetSlidingExpiration(TimeSpan.FromMinutes(5));
            return store.FindAsync(sku, cancellationToken);
        });
}

To export the meter, add it to your OpenTelemetry metrics pipeline:

services.AddOpenTelemetry()
    .WithMetrics(metrics => metrics
        .AddMeter("Microsoft.Extensions.Caching.Memory.MemoryCache")
        .AddConsoleExporter());

After five requests for LAPTOP-15 and one each for three other SKUs, the console exporter prints:

Metric Name: dotnet.cache.requests, Description: Total cache requests., Unit: {request}, Metric Type: LongSum
(...) dotnet.cache.name: products dotnet.cache.request.type: hit   Value: 4
(...) dotnet.cache.name: products dotnet.cache.request.type: miss  Value: 4

Metric Name: dotnet.cache.evictions, Description: Total cache evictions., Unit: {eviction}, Metric Type: LongSum
(...) dotnet.cache.name: products                                   Value: 1

Metric Name: dotnet.cache.entries, Description: Current number of cache entries., Unit: {entry}, Metric Type: LongSumNonMonotonic
(...) dotnet.cache.name: products                                   Value: 2

Metric Name: dotnet.cache.estimated_size, Description: Estimated size of the cache., Unit: By, Metric Type: LongGauge
(...) dotnet.cache.name: products                                   Value: 2

Four misses (one per SKU), four hits, and one eviction because the size limit is three. The hit ratio is hit / (hit + miss), which you can compute in any backend that supports the tag.

A detail that cost me a few minutes (and a brief, unfair suspicion of the runtime): with the default CompactionPercentage of 5 %, a three-entry cache never evicts anything; it just refuses the fourth entry. The demo uses 50 % so the counter moves; real caches are large enough that the default is fine.

Caveats

• The tag name is changing. RC1 emits dotnet.cache.request.type and unit By; the release/11.0 branch already has dotnet.cache.request.result and unit 1, because SizeLimit is an application-defined number, not bytes. Re-check any dashboard or alert that references the tag at GA.
• TrackStatistics is not free. It adds interlocked increments on every hit and miss. That is cheap, but measure it on a hot cache before enabling it everywhere.
• All four instruments are observable. The hot path only increments the counters it already kept for GetCurrentStatistics(); values are read when a collector asks. MeterListener users therefore have to call RecordObservableInstruments(). The same release moved the HTTP open_connections and active_requests metrics to observable instruments, so this applies to more than the cache.

Metrics tell you how often the cache is hit. They do not tell you what a single slow order did along the way. For that you need traces, and the last feature is about deciding which traces you actually want, without a redeploy.

4. Declarative Activity tracing rules

The problem

ActivitySource.StartActivity returns null unless some ActivityListener has said it is interested in that source. Deciding which sources are interesting has always happened in code: either an ActivityListener with a ShouldListenTo callback, or OpenTelemetry's AddSource. Changing the decision meant a redeploy. If you have ever watched a noisy health-check span flood a trace backend because nobody could turn it off in production, you know the feeling. Logging solved the equivalent problem years ago with Logging:LogLevel in appsettings.json, and metrics got MetricsBuilder.EnableMetrics in .NET 8. Tracing had nothing.

The API

Microsoft.Extensions.Diagnostics in .NET 11 adds a tracing builder with the same shape as the metrics one:

services.AddTracing(tracing =>
{
    tracing.AddListener("console", listener => { /* ActivityListenerBuilder */ });
    tracing.EnableTracing(sourceName: "OrdersDemo.Orders");
    tracing.DisableTracing(sourceName: "OrdersDemo.Orders", operationName: "HealthCheck");
    tracing.AddConfiguration(configuration.GetSection("Tracing"));
});

• AddListener(name, configure) registers a named ActivityListener. The ActivityListenerBuilder exposes Sample, SampleUsingParentId, ActivityStarted, ActivityStopped, and ExceptionRecorder.
• EnableTracing / DisableTracing add a TracingRule. sourceName is an exact name, a prefix, or a pattern with a single *; operationName and listenerName are exact matches; null matches everything.
• AddConfiguration reads rules from an IConfiguration section and re-applies them when the configuration reloads.
• The same release adds ActivitySourceFactory for creating sources through DI and unseals ActivitySource.

The configuration shape mirrors logging. This is the sample's appsettings.json:

{
  "Tracing": {
    "EnabledTracing": {
      "OrdersDemo.Orders": {
        "Default": true,
        "HealthCheck": false
      }
    }
  }
}

EnabledTracing applies to all listeners; EnabledGlobalTracing and EnabledLocalTracing target only sources created with new ActivitySource(...) or through ActivitySourceFactory, respectively; any other key under Tracing is a listener name with its own nested block. Inside a source, Default is the source-level rule, every other key is an operation name, and a bare boolean ("OrdersDemo.*": true) is shorthand for Default.

Example: a console listener driven by configuration

In the demo there is one named listener, registered with AddListener, and the rules come from AddConfiguration alone, no code-based rules. The listener itself:

internal static class ConsoleActivityListener
{
    public const string Name = "console";

    public static void Configure(ActivityListenerBuilder listener)
    {
        // The rules API makes no sampling decision for you: without Sample, StartActivity returns null.
        listener.Sample = static (ref _) => ActivitySamplingResult.AllDataAndRecorded;
        listener.ActivityStopped = Print;
    }

    private static void Print(Activity activity)
    {
        // Activity.Tags only yields string-valued tags; TagObjects includes numbers such as order.lines.
        var tags = string.Join(' ', activity.TagObjects.Select(tag => $"{tag.Key}={tag.Value}"));
        Console.WriteLine($"[trace] {activity.Source.Name}/{activity.OperationName} {activity.Duration.TotalMilliseconds:F1} ms {tags}");
    }
}

OrderService creates its source through ActivitySourceFactory and starts two activities, PlaceOrder and HealthCheck:

private readonly ActivitySource _activitySource =
    activitySourceFactory.Create(new ActivitySourceOptions("OrdersDemo.Orders"));

// in PlaceOrderAsync
using var activity = _activitySource.StartActivity("PlaceOrder");   // enabled by rule

// in CheckHealthAsync
using var activity = _activitySource.StartActivity("HealthCheck");  // disabled by rule

Place an order and call the health endpoint. Only the order shows up:

[trace] OrdersDemo.Orders/PlaceOrder 10.2 ms order.customer=ada@example.com order.lines=1 order.id=ORD-6067

Now change "HealthCheck": false to true in appsettings.json while the app is running. The configuration reloads, the listener refreshes its filters, and the next two health calls print:

[trace] OrdersDemo.Orders/HealthCheck 16.0 ms
[trace] OrdersDemo.Orders/HealthCheck 6.6 ms

Set it back to false and the lines stop. No restart, no redeploy.

What I learned by running it

The documentation for this feature is currently one paragraph and a five-line snippet, so most of the following comes from the source and from tests:

• Nothing is enabled by default. AddTracing() without rules enables no source.
• You must set Sample. A listener without a sampling callback never records anything, and StartActivity returns null for its sources. The snippet in the release notes omits this, which is why my first attempt produced no output at all.
• Listeners activate when the host starts. Rules are wired up during IHost.StartAsync (or when ActivitySourceFactory is first resolved). Building the service provider is not enough, which matters for tests and for tools that never start a host.
• Rules cover sources created with new ActivitySource(...) too. Those are "global" scope; factory-created sources are "local". A rule for Legacy.* picks up activities from a plain new ActivitySource("Legacy.Billing").
• Rules resolve like CSS selectors. The most specific one wins: a listener name beats none, a longer source pattern beats a shorter one, an operation name beats none. Between equally specific rules the last one registered wins; avoid overlapping rules rather than relying on that.

Rules and OpenTelemetry

The question everyone asks first: does AddTracing replace OpenTelemetry's AddSource? No. OpenTelemetry registers its own ActivityListener, and the rules only govern listeners registered through AddTracing. I confirmed this with an OpenTelemetry TracerProvider and a rule that disables HealthCheck: OpenTelemetry still received HealthCheck, and the rule-driven listener did not.

There is one interaction worth knowing about. ASP.NET Core's hosting layer creates a request activity even when no listener samples it, so that parent is unrecorded, and OpenTelemetry's default ParentBased(AlwaysOn) sampler follows the parent and drops the child spans. Sampling decisions are combined across listeners with the most permissive winning, so in my first run the rule-driven listener's AllDataAndRecorded decision is what got PlaceOrder exported, while HealthCheck looked as if the rule had suppressed it in OpenTelemetry too. It had not; the sampler had. The demo uses SetSampler(new AlwaysOnSampler()) to keep the two mechanisms independent; in production, ASP.NET Core instrumentation samples the parent properly.

So where does this API fit? Use it for listeners you own: a console or file listener for local debugging, an in-process collector, a diagnostic listener you want operators to toggle in a running service. Keep your OpenTelemetry pipeline as it is.

Four features down. Here is how to run the application and the tests behind them yourself.

Running the sample

The repository pins the SDK in global.json (11.0.100-rc.1.26425.128); the README shows how to install RC1 into a private folder without making it your machine's default SDK. Then, from the repository root:

dotnet test
dotnet run --project src/OrdersDemo   # listens on http://localhost:5028 (from launchSettings.json)

The test project uses xUnit v3 on Microsoft.Testing.Platform, and the run I used for this article looked like this:

OrdersDemo.Tests.dll (net11.0|x64) passed [+28/x0/?0] (1s 461ms)
Test run summary: Passed!
  failed: 0
  skipped: 0
  duration: 1s 896ms

Every observed behaviour listed in the feature sections above is backed by a test with a matching name.

Preview and RC caveats

• RC1 is go-live, not GA. Names and units can still change; the cache tag rename (request.type → request.result, unit By → 1) is already merged for release/11.0.
• Async validation in MVC controllers is not covered by the RC1 documentation; assume synchronous validation there.
• Tracing rules have minimal documentation. The behaviours above were verified against RC1 source and tests, not a specification; re-verify against the GA docs. EF Core 11's FullJoin translation is likewise still in preview.

Adoption checklist

1. Target net11.0, pin the SDK in global.json with rollForward: latestFeature.
2. Replace hand-written full outer joins with FullJoin; test null keys and decide how value types represent "no match".
3. Convert (a, b) => (a, b) selectors to the selector-less Join/GroupJoin overloads; remember GroupJoin returns IGrouping.
4. Move I/O-bound rules to AsyncValidationAttribute or IAsyncValidatableObject; decide whether the synchronous members throw or fall back.
5. Find every synchronous caller of those models (Validator.*, MVC model binding, custom pipelines) and switch it, or keep async attributes off shared models.
6. Call AddValidation() in minimal API projects and pass HttpContext.RequestAborted through.
7. Enable TrackStatistics, set MemoryCacheOptions.Name, add the meter to OpenTelemetry, build a hit-ratio panel; re-check the tag name at GA.
8. If you use MeterListener, call RecordObservableInstruments() on your collection interval.
9. Move custom ActivityListener code to AddTracing with a named listener and a Tracing section; always set Sample; leave OpenTelemetry's AddSource alone.
10. Prefer ActivitySourceFactory over static ActivitySource fields in new code.

Closing thoughts

None of these four features will headline the .NET 11 launch keynote, and that is exactly why they are worth knowing: they are the changes you will use on a Tuesday afternoon, not the ones you will benchmark. Good luck with the upgrade, keep the tests from this article close, and treat every "it obviously works like this" moment with a little suspicion until GA. Hit a surprise I did not cover? The sample repository is the place to open an issue.

References

• What's new in .NET 11
• What's new in .NET libraries for .NET 11 (LINQ joins, async validation, cache metrics, tracing configuration)
• What's new in ASP.NET Core for .NET 11 (async validation in minimal APIs and Blazor)
• .NET diagnostics overview and Collect a distributed trace
• Announcing .NET 11 Release Candidate 1
• dotnet/runtime #100317: Tracing configuration API proposal and PR #129380
• dotnet/runtime #124140: Metrics for MemoryCache API proposal and PR #133151: tag and unit fix
• Async validation design notes (dotnet/aspnetcore) (MVC support deferred)
• What's new in EF Core 11 (FullJoin translation)

Search “ABP vs …” and you will land on pages written by kits and tenancy libraries. Fair. Those pages exist because the question is real. They are not comparing two products of the same kind.

You are choosing among four shapes:

1. Build it yourself on ASP.NET Core, often with a tenancy library such as Finbuckle.MultiTenant.
2. A Clean Architecture template (Jason Taylor, Ardalis) that gives you folders, layers, and a sample feature.
3. A starter kit that copies a snapshot of production modules into your repo (fullstackhero, Brick, and similar kits).
4. A maintained application platform. Architecture, infrastructure, modules, and tools that keep moving.

ABP competes across several decision categories rather than against one uniform product set. Some teams compare it with Clean Architecture and DDD references or starter kits because they prefer to own and assemble the application foundation themselves. Others evaluate .NET application and service frameworks such as ServiceStack, model-driven RAD platforms such as DevExpress XAF, or cross-stack SaaS platforms and starter kits. Existing ASP.NET Boilerplate applications are usually a migration and adoption consideration rather than a same-generation alternative. The table below focuses on the architecture and application-foundation decision; these other categories can still enter the same broader technology discussion.

ABP takes the application-platform approach. The rest of this article is about the things teams evaluate later: multi-tenancy, identity, permissions, modularity, UI (including React), and a path from modular monolith (one deployable application organized into independent modules) to microservices.

TL;DR

Choose ABP when you are shipping a long-lived, multi-tenant, modular .NET product and want a maintained platform: tenancy, identity, modules, official UIs (including React), and Studio / Suite on the same stack.

Choose a Clean Architecture template (Jason Taylor, Ardalis) when the goal is to own every architectural decision from a well-named skeleton.

Choose a starter kit (fullstackhero, Brick, and similar) when you prefer a copy of modules in your repo on day one and you are willing to maintain that snapshot.

Choose Finbuckle (or custom tenant middleware) when tenant resolution is the only additional capability you need on an app you already own. ABP also connects tenancy with application concerns such as identity, permissions, and audit.

Tables in this article follow official ABP documentation.

This is for the long haul

ABP is the recommended choice when you are building a long-lived, multi-tenant, modular .NET product. B2B SaaS. Line of business. A platform several teams will still be extending in a few years.

You want:

• Cross-cutting concerns (auth, tenancy, audit, jobs, localization) already solved and documented.
• Official UI options that match your team: React, Angular, Blazor, MVC, MAUI, or React Native.
• A way to add pre-built modules and, later, split a module into a service without rewriting the application code.
• Tooling (Studio, Suite, CLI) and, if you need it, commercial modules and support, without leaving the same platform.

Yes, ABP is opinionated. The initial learning cost is real: teams need to understand modules, application services, and unit of work conventions before those conventions become productive. Then, when a module needs to become a microservice, the contracts are already there. The conventions become team-wide standards so the next project does not invent a second way to do the same thing.

Four shapes. One table.

| Capability | ABP Platform | DIY ASP.NET Core | Clean Architecture templates (Jason Taylor, Ardalis) | Starter kits (fullstackhero, Brick, and similar) | |---|---|---|---|---| | What you get | Maintained framework + modules + templates + tooling | Empty host and libraries you assemble | Layered/CQRS skeleton + a sample feature | A copy of modules in your repo on day one | | Multi-tenancy | Native: single database, database-per-tenant, or hybrid; identity and authentication/token infrastructure wired for tenants | You design isolation, filters, and cache keys, or add a library such as Finbuckle.MultiTenant | Not included | Often via a tenancy library you still own end-to-end | | Identity, permissions, audit | Application modules + automatic tenant-data filtering, audit logging, permission system | You compose Identity, policies, and audit yourself | Identity sample at most | Bundled in the kit; you maintain the fork | | Modularity | First-class module system; install/uninstall packages | You invent module boundaries | Folders and layers, not a product module catalog | Modular folders; upgrades are merge/cherry-pick | | UI | React (Modern), MVC, Blazor, Angular, React Native, MAUI | You pick and integrate | Template-specific (often Angular/React/API) | Kit-specific (often one SPA) | | Monolith → microservices | Same application contracts; HTTP/C# proxies replace in-process calls | You design the split | You design the split | Extract-a-module if the kit allows it | | Tooling | ABP Studio (including AI Agent), ABP Suite, CLI | dotnet CLI and your IDE | Template CLI + IDE | Kit CLI / Aspire host, varies | | How it evolves | NuGet upgrades for the framework and modules, plus documented migrations | You upgrade every library | You copy the next template over your tree | You merge upstream into source you already customized | | Support | Open-source core plus commercial extras and vendor support | Your team | Community | Community |

ABP may be a suitable fit when the application needs architecture, infrastructure modules, and development tooling to remain integrated and maintainable as the product grows.

How to read the table: templates teach structure. Starter kits give you a snapshot you own. ABP combines application architecture, infrastructure modules, and development tooling in one platform. Names in the headers are examples of the category, not a review of every repository.

Identity, permissions, and audit. ABP ships these as application modules: permission UI, automatic filtering of tenant data, and audit logging. On plain ASP.NET Core you compose Identity, policies, and audit yourself. A Clean Architecture template usually stops at an Identity sample. A starter kit may bundle them; you then maintain that copy.

How the stack evolves. When a customized starter kit is updated, identity and tenancy code may already contain local changes. Reconciling those changes across the files you now own can add significant maintenance work. That is a different upgrade model from updating framework packages.

ABP uses framework and module packages, together with documented migrations. A Clean Architecture template’s next version is something you copy forward. A kit’s next version is reconciled with the snapshot you already changed.

Let’s be honest: what are you actually downloading?

What you build yourself

ASP.NET Core is phenomenal. It is a foundation, not a complete application platform. Building from scratch gives teams maximum control, but also leaves tenant resolution, permission checks, audit logs, job plumbing, and module boundaries to the team.

That work is legitimate if the architecture is unique. For a standard business product, it is infrastructure before the first domain feature.

ABP sits on ASP.NET Core. You keep the Microsoft stack. ABP provides established conventions and modules for teams that prefer those decisions to be part of the platform. See Why ABP Platform.

ABP suits teams that want application infrastructure to remain integrated with the product as it grows.

Clean Architecture templates

This category includes the templates most often compared with ABP: Jason Taylor’s Clean Architecture template and Ardalis’s Clean Architecture template. They provide a good classroom and a clean slate. Their focus is architectural structure and ownership rather than a built-in application module catalog or ABP-specific tooling.

Choose a Clean Architecture template when architectural ownership and a focused starting point matter most.

ABP is a fit when architectural conventions and application modules need to evolve together.

Starter kits

A starter kit copies identity, tenancy, auditing, and a few domain modules into your repository. You own every line. That is a real preference for some teams.

Starter kits are another common option in this decision. fullstackhero is a copy-and-own MIT kit (identity, tenancy, React admin, modules in your repo). Other starter kits, such as Brick, can also provide a prebuilt starting point; the exact features, ownership model, and update process depend on the kit. They can provide a fast starting point, but long-term maintenance depends on how each kit handles updates to customized code.

With ABP, framework and module updates are distributed through packages and documented migrations. With a kit, teams have direct ownership of the source, while updates may require reconciling local changes with upstream code. These are different maintenance models.

Choose a starter kit when an existing set of application features and direct source ownership can accelerate your team.

Choose ABP when you want those application concerns, modules, and tooling to evolve as part of a maintained platform. ABP’s open-source core is yours to use; your business code lives in your repo. There is no separate proprietary runtime for that core. Commercial extras (themes, Pro modules, Suite, support) are optional layers on the same platform, not a rewrite.

Package-based framework and module updates may suit teams that prefer them to reconciling changes in an owned source snapshot.

If you last looked a year ago: React is official

This is easy to miss if you last looked at ABP a year ago.

Official UI options (ABP UI):

• React, in the Modern template system (ABP Studio or abp new --modern).
• MVC / Razor Pages, Blazor (WebAssembly, Server, WebApp), and Angular, on Classic templates.
• React Native and MAUI for mobile / hybrid.

Modern vs Classic: Classic is not a deprecated track. It is the actively supported family with the broadest UI matrix (MVC, Angular, Blazor, MAUI) and the template-first Studio flow. Modern is the newer architecture-first Studio flow, React (or no UI), and the Admin Console / Low-Code path (metadata-driven screens configured through a designer). Choose Classic when the team’s UI is MVC, Angular, or Blazor. Choose Modern when the web UI is React.

One backend, the UI your team already knows.

Multi-tenancy without a side project

ABP treats tenancy as infrastructure, not a feature you bolt on:

• Current tenant is resolved per request.
• Entities implementing IMultiTenant (ABP’s contract for separating tenant-owned data) are automatically filtered; new records get a TenantId identifying the tenant.
• You can use one database for all tenants, one database per tenant, or a hybrid.

That isolation also applies to cache and related concerns so business code stays mostly tenancy-agnostic. Details: Multi-Tenancy.

A tenancy library on raw ASP.NET Core, including Finbuckle.MultiTenant, can resolve the tenant. It does not automatically give you permission UI, audit, jobs, Identity/OpenIddict authentication and token wiring for tenants, and module installs on the same model. That is the platform difference. Pages titled “Finbuckle vs ABP vs custom” are answering a library question. This article is answering the application-platform question.

ABP is worth considering when tenancy needs to stay connected to identity, permissions, data filtering, and the rest of the application model.

Modularity that can become microservices

ABP modules are real packages (domain, application, HTTP API, UI) with documented dependency rules. You can start with a modular monolith and later replace in-process calls with HTTP using the same application service contracts and client proxies (typed clients that call application services over HTTP).

That path is the point. You do not throw away the monolith to “do microservices”; you change the hosting of a module that already had a boundary.

This approach fits teams that want modular boundaries to support both a modular monolith and a later service split.

ABP Low-Code: admin screens inside the same app

ABP Low-Code is a module in your ABP application (Team license or higher). You model entities, pages, forms, permissions, and scripts in the Admin Console. The runtime uses that metadata in the same app, with the same identity, audit, and EF Core model. There is no separate low-code database.

Designer, Studio AI Agent, and hand-written C# / Script API land on one model.

The documented runtime UI is React. You can still keep MVC, Razor Pages, Angular, or Blazor as the main UI and host the React Low-Code runtime beside it (non-React integration).

Docs still label the system Preview (APIs and designer may change before GA). That is a maturity label, not a missing product.

| | ABP Low-Code | External low-code platform | Hand-written CRUD every time | |---|---|---|---| | Where it runs | Inside your ABP app | Separate product / runtime | Your repo | | Data and identity | Same database and ABP authorization | Often a parallel model | Whatever you build | | Extend with code | C#, Script API, Agent | Platform limits | Always code | | Screens | Grid, form, calendar, kanban, gallery, dashboard, import/export | Vendor widgets | Custom pages | | How you enable it | Studio modern wizard (layered, single-layer, modular monolith + EF Core) or add to an existing EF Core solution | Vendor onboarding | Always code |

Studio’s new-solution wizard step is omitted for microservice architecture and when MongoDB is selected, because runtime-managed tables use EF Core. Layered and modular-monolith EF Core solutions are the documented enablement path today.

Use Low-Code for the admin CRUD and metadata-driven screens. Keep distinctive product UX in normal ABP UI, including Suite-generated React CRUD on modern solutions.

When this is the right call

Pick ABP when:

• The product will have tenants, roles, audit, and more than one team.
• You want React or Blazor or Angular or MVC on a shared backend.
• You expect to grow from modular monolith to services without a rewrite.
• You want Studio, Suite, and (optionally) Low-Code on the same stack.

A Clean Architecture template is a solid choice when architectural ownership and a focused starting point matter most.

A starter kit is a solid choice when an existing set of application features and direct source ownership can accelerate your team. ABP is a better fit when those application concerns, modules, and tooling should evolve as part of a maintained platform.

ASP.NET Boilerplate is the predecessor, not a same-generation starter kit. If that is the comparison, it is a migration to the current ABP platform, not a fork-and-own kit decision.

DevExpress XAF and similar commercial frameworks follow a model-driven RAD approach built around a vendor UI ecosystem. That approach can reduce application boilerplate and accelerate internal business applications, while also placing the application’s model and much of its UI experience within DevExpress conventions and controls. ABP is an application platform on ASP.NET Core, with an open-source core, modular architecture, and multiple UI options. It gives teams more direct control over the application layers and frontend choices, including MVC, Blazor, Angular, and React, while supporting a modular-monolith-to-microservices path. XAF may be the better fit when the priority is delivering a model-driven business application quickly within the DevExpress ecosystem. ABP may be the better fit when the product needs ASP.NET Core, a more customized frontend experience, multiple client options, or a modular architecture that can evolve toward services.

FAQ

Is ABP free or commercial?

ABP Framework has an open-source core. Some themes, modules, generators, Studio capabilities, support, and other commercial offerings require an appropriate commercial license. Exact availability depends on the product and license level.

If we stop paying for commercial extras, or we leave ABP later, is the app a black box?

No. The application is still ASP.NET Core, your C#, and EF Core (or MongoDB). The open-source framework stays in the solution as packages you already reference. Leaving ABP means replacing those packages the way you would replace any framework, not extracting code from a closed runtime. Suite output is source in your repo. Commercial modules, themes, and Suite itself are optional layers; dropping them does not delete your domain.

If we already have a Clean Architecture or starter-kit repo (Jason Taylor, Ardalis, fullstackhero, Brick), can we “just add ABP” like a NuGet?

No. ABP’s module pipeline, interceptors, automatic tenant-data filters (which limit queries to the current tenant), and startup conventions assume it is the host. Teams adopt ABP on a new solution (or plan a migration), they do not drop Volo.Abp.* onto an existing CA template and keep the old composition root unchanged. That is the real cost versus a tenancy library you add to code you already own. See Why ABP Platform.

We already use Finbuckle (or custom tenant middleware). What does ABP tenancy still do that that library does not?

A tenancy library resolves who the tenant is. ABP also isolates queries and inserts (IMultiTenant data filters), wires Identity and OpenIddict for tenants, and applies the same tenant context to cache and related infrastructure. That covers single database, database-per-tenant, or hybrid. Permissions, audit, and jobs then run inside that model instead of each being a separate integration project.

If we start Modern/React, can the same backend later serve a second UI (public MVC, partner Blazor, mobile)?

Yes. Application services and HTTP APIs are UI-agnostic. Official UIs (React, Angular, Blazor, MVC, React Native, MAUI) are hosts on that backend. You choose Modern vs Classic at solution creation for the primary web app; extra clients consume the same APIs. You do not rewrite domain or application layers to add a second frontend.

When we split a module into a microservice, do we rewrite application services as controllers?

Not as the default path. Module contracts stay; in-process calls become HTTP (or messaging) via client proxies against the same application-service interfaces. You change hosting, not the feature’s application API. That is the comparison point versus a starter kit whose “modules” are folders with no proxy story.

For the same admin entity, should we use Suite-generated React CRUD or Low-Code pages?

Suite writes source into your layers (entity, app service, UI, tests) that you commit and customize, including React on modern solutions. Low-Code keeps the entity in metadata (designer + runtime APIs/pages) without generating those classes for the standard flow. Use Suite when the screen will grow into product code; use Low-Code when the screen should stay designer-driven. They are not substitutes for each other.

Can we keep MediatR / vertical-slice handlers for new features inside an ABP solution?

You can reference extra libraries, but ABP’s default application surface is application services with unit of work, validation, and authorization conventions. Comparison with CA templates is not “MediatR vs nothing”; it is whether the team standardizes on ABP’s application layer or on a handler-per-feature folder as the public API. Mixing both without a rule usually duplicates the same use case in two styles.

Next step

Create a solution in ABP Studio and pick Modern (React) or Classic (MVC / Blazor / Angular). Then add only the modules you need.

Create a free ABP solution · Read the framework overview · Why ABP Platform

Sources

• ABP UI options
• Modern vs Classic templates
• React UI
• Multi-tenancy
• Why ABP Platform
• Low-Code System
• Jason Taylor Clean Architecture template
• Ardalis Clean Architecture template
• fullstackhero starter kit
• Finbuckle.MultiTenant documentation
• ServiceStack documentation
• DevExpress XAF overview

Product names in this article belong to their owners. Mention is for identification in a technical comparison, not affiliation or endorsement.

Teams compare ABP Studio with three neighbors. This is not an “IDE replacement” debate.

1. .NET Aspire, for describing distributed resources as code and watching them on a dashboard.
2. Generic AI IDEs (Cursor, GitHub Copilot, Claude Code), for repo-wide chat and file edits.
3. CRUD scaffolders, such as dotnet aspnet-codegenerator and visual Blazor builders (for example Radzen).

Those tools are good. Keep Visual Studio, Rider, or VS Code. Studio can open the solution in them. This article is about what the ABP workflow brings together in one environment: templates, module graph, Solution Runner (Studio’s tool for starting, stopping, and inspecting applications), the ABP Agent, and ABP Suite (including React).

TL;DR

Choose ABP Studio when the work is ABP: solution shape, module graph, Solution Runner, AI Agent, and Suite CRUD (including React on modern solutions).

Keep Visual Studio, Rider, or VS Code beside it for refactor, tests, and language services.

Add .NET Aspire when you want resource-as-code and the Aspire dashboard. Studio does not forbid it; microservice templates can wire Aspire in.

Use a generic AI IDE as an extra editor if the team already lives there. Prefer the ABP Agent when the change needs modules, migrations, proxies, or live run telemetry.

Tables in this article follow official ABP documentation.

If the bottleneck is ABP, not the C# file

Studio may be a suitable choice when your team is (or will be) on the ABP Platform and you want one place to:

• Scaffold production templates (including React Modern and Classic MVC / Blazor / Angular).
• Run many services, containers, and UIs from a Solution Runner profile (the set of applications and services started together).
• Ask, plan, and implement with AI against modules, packages, migrations, and live telemetry.
• Generate layered CRUD with ABP Suite for MVC, Blazor, Angular, and React.

If you only need a general editor, keep using your IDE. If you only need container orchestration and OpenTelemetry locally, Aspire may already be on the machine. Add Studio when the solution graph and ABP conventions are the bottleneck, not the C# file.

What actually sits next to Studio

| Capability | ABP Studio + Agent | .NET Aspire | General AI IDEs (Cursor, Copilot, Claude Code, …) | Visual Studio / Rider / VS Code | |---|---|---|---|---| | Role | ABP solution lifecycle + AI coding in context | Cloud-native orchestration, service discovery, dashboard | Repo-wide AI edit / chat / agents | General-purpose IDE | | ABP / DDD structure in context | Solution, modules, packages, run profiles in the agent system context | Unaware of ABP modules | Files and text; no ABP module graph | Solution explorer of projects, not ABP modules | | ABP-shaped artifacts | Suite generates entity, app service, DTOs, repository, and UI; Agent follows those module conventions | No | Generic C# unless you prompt every ABP convention | Language services only | | Production ABP templates | Layered, modular, microservice; Modern React or Classic UIs | Minimal host templates for Aspire | None | dotnet new / ABP CLI if you add it | | Run + monitor | Solution Runner: start/stop apps and containers, HTTP requests, exceptions, logs, events, browse UI | Aspire dashboard: resources, logs, traces, metrics | Shell / terminal processes | Multi-project debug | | AI that can build, migrate, generate proxies | Agent mode: files, shell, Studio tools (dotnet_build, start_applications, generate_csharp_proxies, get_exceptions, …), MCP | Not an ABP coding agent | Shell-wrapped dotnet if you teach it | Copilot in the editor (generic) | | Kubernetes | Studio Kubernetes integration for ABP solutions | Publish / deploy story for Aspire apps | No | No (unless you add tools) | | Code edit / refactor | Agent writes code; Open with your IDE for deep refactor | Not an editor | Strong | Strongest language tooling | | Use together? | Yes, open IDE from Studio; optional Aspire integration | Yes with ABP microservice template | Yes as an extra editor | Yes; Studio launches them |

How to read the table: these tools stack. Studio does not replace Rider's refactorings or Aspire's resource model. Its differentiated value is the ABP-aware workflow across solution structure, modules, run profiles, and agent tools.

Kubernetes. Studio’s Kubernetes integration is for developing against a cluster (browse and health using service names from the run profile). It is not Helm, GitOps, or your production deploy pipeline.

The ABP Agent vs “just ask Cursor”

Cursor and Copilot are excellent at finishing a LINQ query or explaining a regex. That is not the argument.

Ask a generic AI IDE: "Add a Product entity, make it multi-tenant, add the EF Core migration, generate the React UI." A generic AI IDE can work effectively when it has sufficient repository context and explicit project conventions. ABP Studio's differentiated value is that solution, module, run-profile, and telemetry context are available through first-class Studio capabilities. For cross-layer ABP changes, this can reduce the amount of context and manual coordination the developer must provide.

ABP Studio AI Agent is not limited to the currently open text buffer. The session can use the solution, modules, packages, runnable apps, run profile, AI scope, and enabled tools. ABP Suite remains the CRUD generator, while the Agent is designed to work with the module graph, add a migration, start the profile, and inspect live exceptions.

Modes:

• Ask, read-only answers. Can search ABP documentation.
• Plan, read-only implementation plans.
• Agent, read/write files, shell, add migrations, run Studio tools, MCP, update plan steps.

The ABP Agent fits changes where module, solution, and runtime context should remain available throughout the work.

That is the difference versus a generic AI IDE:

| What you ask | ABP Agent | Generic AI IDE | |---|---|---| | “Add an app service following ABP layering” | Receives solution, module, and ABP documentation context through Studio | Works from the repository context and instructions provided to it | | “Why did this HTTP call fail?” | get_requests / get_exceptions / get_logs on the running profile | You paste a log or attach a debugger | | “Generate C# / Angular proxies” | First-class Studio tools | A shell command if the model guesses it | | “Start the apps, then continue” | start_applications / start_containers | Terminal + wait | | Scope | AI scopes limit which modules the agent may touch; .abpignore blocks secrets | Works from the repository context and instructions provided to it |

You still review the diff. Agent mode is execution with a permission boundary, not unsupervised production deploys.

The privacy boundary is the session you give it: files, prompts, Studio tool output, attachments, and allowed URLs. Privacy depends on the selected model, configured provider, accessible scope, and enabled tools. .abpignore prevents excluded files from entering the agent context.

Why Aspire does not replace Studio (they stack)

Solution Runner is how you run an ABP modular or microservice tree: profiles per team, folders for apps/gateways/services, C# hosts, CLI tasks (for example Angular), Docker containers, start/stop/build, browse, health, and live HTTP / exception / log / event views.

.NET Aspire is how many .NET teams describe distributed resources as code and watch them on a dashboard (OpenTelemetry, containers, connection strings).

Their responsibilities overlap around local orchestration, but their primary scopes are different. Aspire focuses on distributed resource orchestration, while ABP Studio adds ABP solution templates, module workflows, Suite, and the ABP Agent.

You do not have to pick one. ABP microservice templates can enable Aspire so AppHost starts infrastructure and services; you can still use Studio’s runner and Agent. See Aspire integration.

Pairing ABP Studio with Aspire works well when ABP solution workflows and distributed resource orchestration are both needed.

Suite: a CRUD slice, not a pretty grid

ABP Suite generates a CRUD slice of an ABP application from an entity: domain type, repository, application service, migration, UI, tests, navigation properties, multi-tenant flag, localization keys.

| | ABP Suite | dotnet aspnet-codegenerator / EF scaffolding | Visual Blazor app builders (for example Radzen) | |---|---|---|---| | Output | Entity through application layer + UI + optional tests | Controllers, Razor Pages, Blazor CRUD, or Minimal API endpoints against a DbContext | Blazor UI + data wiring from a database or REST source | | UI stacks | MVC, Blazor (Blazorise or MudBlazor, detected), Angular, and React (modern solutions) | MVC views, Razor Pages, and Blazor components. No Angular. No React. | Blazor only (Server, WebAssembly, Auto) | | ABP permissions, tenancy, audit base classes | Options on the entity (CRUD generation) | Does not use ABP permission and tenancy conventions | Does not use ABP permission and tenancy conventions | | Custom code on regenerate | Customizable code hook points for MVC, Blazor, and Angular; React pages require extra care when regenerated | Often requires manually preserving custom changes | Varies by product | | React UI | Yes, template-based CRUD for modern React apps, including search, paging, validation, permissions, localization, and navigation properties. Registers routes and menu | No React generator in the official scaffolding set (blazor, razorpage, view, controller, identity, minimalapi) | Blazor-focused rather than React-based |

Suite supports the official web UI stacks, including React. ABP Agent is an extra path when you want AI to evolve those pages, not a substitute for Suite React output.

Suite is a fit when generated CRUD should follow the application's ABP layers, conventions, and selected UI stack.

When Studio is the right tool in the stack

Choose ABP Studio when the work is ABP: new solution shape, module graph, run profiles, Kubernetes-connected browse, Agent that can migrate and generate proxies, Suite for CRUD.

Keep your IDE open beside it for refactor, tests, and language services. Studio expects that.

Add Aspire when you want resource-as-code and the Aspire dashboard. Studio does not forbid it.

Use a generic AI IDE as an extra editor if your team already lives there. Prefer Agent for ABP-structured changes so the model is not guessing module boundaries from filenames.

Studio works best when ABP-specific solution workflows complement your existing IDE.

FAQ

We already run .NET Aspire (AppHost + dashboard). What does Studio still do that Aspire does not?

Aspire models resources (projects, containers, connection strings, OpenTelemetry) as code. Studio models an ABP solution: modules, package installation, production templates, Suite, Kubernetes browse for ABP services, and an agent that can migrate and generate proxies. Their responsibilities overlap around local orchestration, but their primary scopes are different. You can keep AppHost; microservice templates can integrate Aspire. You do not need to replace Aspire with Studio.

If the team already uses Cursor or Copilot on the same repo, when is ABP Agent the better tool for a task?

When the task needs ABP structure or a live run, not only a file edit: module/package scope, generate_csharp_proxies / generate_angular_proxies, start_applications, or get_exceptions / get_requests / get_logs against the Solution Runner profile. Generic IDEs can work in the same repository when given the relevant context and conventions. Agent provides first-class access to module, run-profile, and Studio tool context for changes that coordinate ABP modules and running services.

After Suite generates React CRUD, how should we customize the page?

For MVC, Blazor, and Angular, use Suite’s customizable code hook points. React pages require extra care when regenerated, so keep additional React UI in files Suite does not generate or evolve it with ABP Agent. Suite React generation itself is template-based, not AI.

Can Agent start the microservice profile, then use real HTTP/exception data in the same session?

Yes, in Agent mode with a run profile: tools include start_applications / start_containers and then get_requests, get_exceptions, get_logs, get_events (built-in capabilities). Ask/Plan cannot mutate or start apps. If nothing is running, those telemetry tools have nothing to read. That is why “AI that sees production-like local traffic” is a Studio and Runner loop, not a chat sidebar.

Does Studio Kubernetes integration replace Helm, GitOps, or our cluster deploy pipeline?

No. It is for developing against a cluster (browse/health using Kubernetes service names from the run profile, manage connected services). Aspire’s publish story and your CI remain how you ship. Do not treat the Studio K8s panel as the production deployment product.

Can one developer live in Rider and another in VS Code while sharing the same Studio solution?

Yes. Studio holds solution/run-profile metadata; Open with launches whatever IDE is installed. Run profiles and Agent sessions are not tied to a single editor vendor. The constraint is ABP Studio itself on the machine, not a mandate to abandon Rider or VS.

Next step

Download ABP Studio · AI Agent docs · Generate a CRUD page · ABP Framework

Sources

• ABP Studio overview
• AI Agent
• AI Agent built-in capabilities
• Solution Runner
• Solution Explorer / Open with IDE
• ABP Suite
• Generating a CRUD page
• Customizing the generated code
• ASP.NET Core aspnet-codegenerator
• .NET Aspire overview
• Radzen Blazor Studio
• Microservice Aspire integration

Product names in this article belong to their owners. Mention is for identification in a technical comparison, not affiliation or endorsement.

This guide compiles best practices for building robust, scalable, and sustainable RESTful APIs, based on information gathered from various sources.

1. Fundamentals of REST Architecture

REST is based on specific constraints and principles that support features like simplicity, scalability, and statelessness. The six core principles of RESTful architecture are:

• Uniform Interface: This is about consistency. You use standard HTTP methods (GET, POST, PUT, DELETE) and URIs to interact with resources. The client knows how to talk to the server without needing some custom instruction manual.

• Client-Server: The client (e.g., a frontend app) and the server are separate. The server handles data and logic, the client handles the user interface. They can evolve independently as long as the API contract doesn't change.

• Stateless: This is a big one. The server doesn't remember anything about the client between requests. Every single request must contain all the info needed to process it (like an auth token). This is key for scalability.

• Cacheable: Responses should declare whether they can be cached or not. Good caching can massively improve performance and reduce server load.

• Layered System: You can have things like proxies or load balancers between the client and the server without the client knowing. It just talks to one endpoint, and the layers in between handle the rest.

• Code on Demand (Optional): This is the only optional one. It means the server can send back executable code (like JavaScript) to the client. Less common in the world of modern SPAs, but it's part of the spec.

2. URI Design and Naming Conventions

The URI structure is critical for making your API understandable and intuitive.

Use Nouns Instead of Verbs

Your URIs should represent things (resources), not actions. The HTTP method already tells you what the action is.

• Good: /api/users

• Bad: /api/getUsers

Use Plural Nouns for Resource Names

Stick with plural nouns for collections. It keeps things consistent, even when you're accessing a single item from that collection.

• Get all users: GET /api/users

• Get a single user: GET /api/users/{id}

Use Nested Routes to Show Relationships

If a resource only exists in the context of another (like a user's orders), reflect that in the URL.

• Good: /api/users/{userId}/orders (All orders for a user)

• Bad: /api/orders?userId={userId}

• Good: /api/users/{userId}/orders/{orderId} (A specific order for a user)

Note: Use this structure only if the child resource is tightly coupled to the parent. Avoid nesting deeper than two or three levels, as this can complicate the URIs.

Path Parameters vs. Query Parameters

Use the correct parameter type based on its function.

• Path Parameters (/users/{id}): Use these to identify a specific resource or a collection. They are mandatory for the endpoint to resolve.

  • Example: GET /api/users/123 uniquely identifies user 123.

• Query Parameters (?key=value): Use these for optional actions like filtering, sorting, or pagination on a collection.

  • Example: GET /api/users?role=admin&sort=lastName filters the user collection.

Keep the URL Structure Consistent

• Use lowercase letters: Since some systems are case-sensitive, always use lowercase in URIs for consistency.

  • Example: Use /api/product-offers instead of /api/Product-Offers.

• Use special characters correctly: Use characters like /, ?, and # only for their defined purposes.

  • Example: To get comments for a specific post, use the path /posts/123/comments. To filter those comments, use a query parameter: /posts/123/comments?authorId=45.

3. Correct Usage of HTTP Methods

Each HTTP method has a specific purpose. Sticking to these standards makes your API predictable.

| HTTP Method | Description | Idempotent* | Safe** | | --------------- | --------------------------------------------------------------------------- | --------------- | ---------- | | GET | Retrieves a resource or a collection of resources. | Yes | Yes | | POST | Creates a new resource. | No | No | | PUT | Updates an existing resource completely or creates it if it does not exist. | Yes | No | | PATCH | Partially updates an existing resource. | No | No | | DELETE | Deletes a resource. | Yes | No |

• Idempotent: Doing it once has the same effect as doing it 100 times. Deleting a user is idempotent; once it's gone, it's gone.

• Safe: The request doesn't change anything on the server. GET is safe.

Example in practice:

Let's consider a resource endpoint for a collection of articles: /api/articles.

• GET /api/articles: Retrieves a list of all articles.

• GET /api/articles/123: Retrieves the specific article with ID 123.

• POST /api/articles: Creates a new article. The data for the new article is sent in the request body.

• PUT /api/articles/123: Replaces the entire article with ID 123 using the new data sent in the request body.

• PATCH /api/articles/123: Partially updates the article with ID 123. For example, you could send only the {"title": "New Title"} in the request body to update just the title.

• DELETE /api/articles/123: Deletes the article with ID 123.

4. Data Exchange and Responses

Prefer the JSON Format

It's the standard. It's lightweight, human-readable, and every language can parse it easily. Send and receive your data as JSON.

• Example Request Body:

  {
    "title": "Best Practices for APIs",
    "authorId": 5,
    "content": "An article about designing great APIs..."
  }
  

Use Appropriate HTTP Status Codes

Use standard HTTP status codes to provide clear information to the client about the outcome of their request.

• 2xx (Success):

  • 200 OK: The request was successful. (For GET, PUT, PATCH)

  • 201 Created: The resource was successfully created. (For POST) The response should include a Location header with the URI of the new resource.

    • Example: POST /api/articles responds with 201 Created and the header Location: /api/articles/124.

  • 204 No Content: The request was successful, but there is no response body. (For DELETE)

• 4xx (Client Error):

  • 400 Bad Request: Invalid request (e.g., missing or incorrect data).

  • 401 Unauthorized: Authentication is required.

  • 403 Forbidden: No permission.

  • 404 Not Found: The requested resource could not be found.

• 5xx (Server Error):

  • 500 Internal Server Error: An unexpected error occurred on the server.

Provide Clear and Consistent Error Responses

When something goes wrong, give back a useful JSON error message. Your future self and any developer using your API will thank you.

• Example of a detailed error response:

{
  "type": "[https://---.com/probs/validation-error](https://example.com/probs/validation-error)",
  "title": "Your request parameters didn't validate.",
  "status": 400,
  "detail": "The 'email' field must be a valid email address.",
  "instance": "/api/users"
}

5. Performance Optimization

Optimizing API performance is crucial for providing a good user experience and ensuring the scalability of your service. Key strategies include caching, efficient data retrieval, and controlling traffic.

Caching

Caching is one of the most effective ways to improve performance. By storing and reusing frequently accessed data, you can significantly reduce latency and server load.

• How it works: Caching can be implemented at various levels (client-side, CDN, server-side). REST APIs can facilitate this by using standard HTTP caching headers.

• Key Headers:

  • Cache-Control: Tells the client how long to cache something (e.g., public, max-age=600).

  • ETag: A unique version identifier for a resource. The client can send this back in an If-None-Match header. If the data hasn't changed, you can just return 304 Not Modified with an empty body, saving bandwidth.

  • Last-Modified: Indicates when the resource was last changed. Similar to ETag, it can be used for conditional requests with the If-Modified-Since header.

• Example Response Header for Caching:

  Cache-Control: public, max-age=600
  ETag: "x234dff"
  

Filtering, Sorting, and Pagination

For endpoints that return lists of resources, it's inefficient to return the entire dataset at once, especially if it's large. Implementing these features gives clients more control over the data they receive.

• Filtering: Allows clients to narrow down the result set based on specific criteria. This reduces the amount of data transferred and makes it easier for the client to find what it needs.

  • Example: GET /api/orders?status=shipped&customer_id=123

• Sorting: Enables clients to request the data in a specific order. A common convention is to specify the field to sort by and the direction (ascending or descending).

  • Example: GET /api/users?sort=lastName_asc or GET /api/products?sort=-price (the - indicates descending order).

• Pagination: Breaks down a large result set into smaller, manageable chunks called "pages". This prevents overloading the server and client with massive amounts of data in a single response.

  • Example: GET /api/articles?page=2&pageSize=20 (retrieves the second page, with 20 articles per page).

Rate Limiting

Protect your API from abuse by limiting how many requests a client can make in a given time. If they exceed the limit, return a 429 Too Many Requests. It's also super helpful to return these headers so the client knows what's going on:

• X-RateLimit-Limit: Total requests allowed.

• X-RateLimit-Remaining: How many requests they have left.

• Retry-After: How many seconds they should wait before trying again.

6. Security

Security is not an optional feature; it must be a core part of your API design.

• Always Use HTTPS (TLS): Encrypt all traffic to prevent man-in-the-middle attacks. There are no exceptions to this rule for production APIs.

• Authentication & Authorization:

  • Authentication (Who are you?): Use a standard like OAuth 2.0 or JWT Bearer Tokens.

  • Authorization (What are you allowed to do?): Check permissions for every request. Just because a user is logged in doesn't mean they can delete another user's data.

• Input Validation: Always validate and sanitize data coming from the client to prevent injection attacks. If the data is bad, reject it with a 400 Bad Request.

• Use Security Headers: Add headers like Strict-Transport-Security and Content-Security-Policy to add extra layers of browser-level protection.

7. API Lifecycle Management

Versioning

Your API will change. Versioning lets you make breaking changes without messing up existing clients. The most common way is in the URI.

• URI Versioning (Most Common): https://api.example.com/v1/users

  • Pros: Simple, explicit, and easy to explore in a browser.

• Header Versioning: The client requests a version via a custom HTTP header.

  • Example: Accept-Version: v1

  • Pros: Keeps the URI clean.

• Media Type Versioning (Content Negotiation): The version is included in the Accept header.

  • Example: Accept: application/vnd.example.v1+json

  • Pros: Technically the "purest" REST approach.

Backward Compatibility & Deprecation

When you release v2, don't just kill v1. Keep it running for a while and communicate a clear shutdown schedule to your users.

Documentation

An API is only as good as its documentation. Use tools like the OpenAPI Specification (formerly Swagger) to generate interactive, machine-readable documentation. Good docs should include:

• Authentication instructions.

• Clear explanations of each endpoint.

• Request/response examples.

• Error code definitions.

8. Monitoring and Testing

Monitoring and Logging

To ensure your API is reliable, you must monitor its health and log important events.

• Structured Logging: Log in a machine-readable format like JSON. Include a correlationId to track a single request across multiple services.

• Monitoring: Track key metrics like latency (response time), error rate, and requests per second. Use tools like Prometheus, Grafana, or Datadog to visualize these metrics and set up alerts.

API Testing

Thorough testing is essential to prevent bugs and regressions.

• Unit Tests: Test individual components and business logic in isolation.

• Integration Tests: Test the interaction between different parts of your API, including the database.

• Contract Tests: Verify that your API adheres to its documented contract (e.g., the OpenAPI spec).

9. Advanced Level: HATEOAS

HATEOAS (Hypermedia as the Engine of Application State) is a REST principle that allows your API to be self-documenting and more discoverable. It involves including hyperlinks in responses for actions that can be performed on the relevant resource.

For example, a response for a user resource might look like this:

{
  "id": 1,
  "name": "Deo Steel",
  "links": [
    { "rel": "self", "href": "/users/1", "method": "GET" },
    { "rel": "update", "href": "/users/1", "method": "PUT" },
    { "rel": "delete", "href": "/users/1", "method": "DELETE" }
  ]
}

This way, the client can follow the links in the response to take the next step, rather than manually constructing the URIs.

10. A Practical Shortcut: Leveraging Frameworks like ABP.IO

Okay, that was a lot. While it's crucial to understand all these principles, you don't have to build everything from scratch. Modern frameworks can handle a ton of this for you. I work a lot in the .NET space, and ABP Framework is a great example of this.

Here’s how it automates many of the things we just talked about:

• Automatic API Controllers: You write your business logic in an "Application Service," and ABP automatically creates the REST API endpoints for you, following all the correct naming and HTTP method conventions. (Covers sections 2 & 3).

• Built-in Best Practices:

  • Standardized Error Responses: It has a built-in exception handling system that automatically generates clean, consistent JSON error responses. (Covers section 4).

  • Input Validation: It has automatic validation for your DTOs. If a request is invalid, it returns a detailed 400 Bad Request without you writing a single line of code for it. (Covers section 6).

  • Paging, Sorting, Filtering: You get these out of the box by just using their predefined interfaces. (Covers section 5).

• Integrated Security: It comes with a full auth system. You just add an [Authorize] attribute to a method, and it handles the rest. It also automatically manages database transactions per API request (Unit of Work) to ensure data consistency. (Covers section 6).

• Automatic Documentation: It automatically generates an OpenAPI/Swagger UI for your API, which is a massive help for anyone who needs to use it. (Covers section 7).

Using a framework like this lets you focus on your core business logic, confident that the foundation is built on solid, established best practices.