Tutorial

Create the projects

mkdir billing && cd billing
dotnet new sln -n Billing

dotnet new classlib    -n Billing.Application    -o src/Billing.Application
dotnet new classlib    -n Billing.Infrastructure -o src/Billing.Infrastructure
dotnet new web         -n Billing.Api            -o src/Billing.Api
dotnet new aspire-apphost -n Billing.AppHost     -o src/Billing.AppHost

dotnet sln add src/Billing.Application src/Billing.Infrastructure src/Billing.Api src/Billing.AppHost

Wire project references

The onion points inward — infrastructure and the host depend on the application, never the reverse.

dotnet add src/Billing.Infrastructure reference src/Billing.Application
dotnet add src/Billing.Api            reference src/Billing.Infrastructure src/Billing.Application
dotnet add src/Billing.AppHost        reference src/Billing.Api

Add the Elarion packages

The source generators ship inside their runtime packages — the Elarion generator in Elarion, the EF Core generator in Elarion.EntityFrameworkCore — so there are no separate analyzer packages to install or mark PrivateAssets="all". Because NuGet analyzer assets are not transitive, each project that needs a generator references its package directly.

The application project holds your modules, entities, and the [GenerateDbSets] concrete BillingDbContext. It uses EF Core for data access and Elarion.Validation so the DataAnnotations input rules on request DTOs are enforced (and the per-module validation resolvers generated):

cd src/Billing.Application
dotnet add package Elarion
dotnet add package Elarion.Validation
dotnet add package Elarion.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore
cd ../..

The application's persistence layer owns the concrete BillingDbContext, the PostgreSQL provider, the EF Core integration-event outbox, and the migrations — because the database is application logic, not an infrastructure detail. The generated class-side DbSets and entity configuration are emitted there beside the configurations (so no cross-assembly manifest is involved):

cd src/Billing.Application
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Elarion.Messaging.Outbox
cd ../..

The host project references the JSON-RPC transport, the ASP.NET Core integration, and the MCP server. It also references Elarion directly so the bundled generator runs in the host (it emits the RPC map and module bootstrapper), and registers the scheduler, the Microsoft resilience runtime, and EF Core design-time tooling.

cd src/Billing.Api
dotnet add package Elarion
dotnet add package Elarion.JsonRpc
dotnet add package Elarion.AspNetCore
dotnet add package Elarion.AspNetCore.Mcp
dotnet add package Microsoft.Extensions.Resilience
dotnet add package Microsoft.EntityFrameworkCore.Design
cd ../..

Turn on the generators

Opt the application assembly into Elarion generation once. We will add the pipeline attribute to this file in Write the features.

using Elarion.Abstractions;

[assembly: UseElarion]

[assembly: UseElarion] enables generation for module handlers, services, scheduled jobs, and resilience policies across the assembly.

Provision PostgreSQL with .NET Aspire

Rather than starting a database by hand, let the Aspire app host provision PostgreSQL and inject its connection string into the API. Add the PostgreSQL hosting integration and orchestrate the resources:

dotnet add src/Billing.AppHost package Aspire.Hosting.PostgreSQL

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres").WithDataVolume();
var billingDb = postgres.AddDatabase("billing");

builder.AddProject<Projects.Billing_Api>("api")
    .WithReference(billingDb)   // injects ConnectionStrings__billing into the API
    .WaitFor(billingDb);

builder.Build().Run();

Running the app host (in Host the API) starts the database container and the API together — no manual connection string, and the API reads it via builder.Configuration.GetConnectionString("billing"). The host applies EF migrations on startup, so a fresh database is ready on first run.