Flowly.Templates 1.3.2

Flowly.Templates

Project templates for scaffolding Flowly-based .NET applications.

Installation

dotnet new install Flowly.Templates

Templates

flowlyapp — Scaffold a complete send/receive solution

Generates a full solution with a Messages contracts library, a Sender, and a Receiver — the fastest way to get a working Flowly app running locally. Matches the quickstart guides exactly, including docker-compose.yml and sbconfig.json for Azure Service Bus.

dotnet new flowlyapp --transport <transport> [options] -n <SolutionName>

Transport (required)

Features (optional)

Database backend (required when --jobs or --deadletter is used)

Examples

# Full RabbitMQ solution
dotnet new flowlyapp --transport rabbitmq -n MyApp

# Full Azure Service Bus solution (includes sbconfig.json)
dotnet new flowlyapp --transport asb -n MyApp

# Single-project InMemory solution (no broker required)
dotnet new flowlyapp --transport inm -n MyApp

# RPC-style call/response (RabbitMQ)
dotnet new flowlyapp --transport rabbitmq --call -n MyApp

# RPC-style call/response (ASB) — reply queue added to sbconfig.json automatically
dotnet new flowlyapp --transport asb --call -n MyApp

# RPC in a single in-process worker (InMemory)
dotnet new flowlyapp --transport inm --call -n MyApp

# RabbitMQ with job tracking (SQLite) and dead-letter tracking
dotnet new flowlyapp --transport rabbitmq --jobs --deadletter --db sqlite -n MyApp

# ASB with job tracking (SQL Server) — SQL Server is already in docker-compose
dotnet new flowlyapp --transport asb --jobs --db sqlserver -n MyApp

# InMemory with both features (SQLite)
dotnet new flowlyapp --transport inm --jobs --deadletter --db sqlite -n MyApp

# RabbitMQ with standalone Dashboard project
dotnet new flowlyapp --transport rabbitmq --dashboard -n MyApp

# RabbitMQ with Jaeger tracing (adds Jaeger to docker-compose, sets OTLP endpoint in launchSettings)
dotnet new flowlyapp --transport rabbitmq --otel-export jaeger -n MyApp

# RabbitMQ with Zipkin tracing
dotnet new flowlyapp --transport rabbitmq --oe zipkin -n MyApp

What's generated

RabbitMQ / Azure Service Bus (baseline):

MyApp/
├── MyApp.slnx
├── Messages/            ← shared message contracts (MyMessage.cs)
├── Sender/              ← WebApplication; sends a message every second
├── Receiver/            ← worker; receives and prints messages
├── docker-compose.yml   ← RabbitMQ or ASB emulator (+ SQL Server / Postgres when --db sqlserver/postgres)
└── sbconfig.json        ← ASB only: emulator queue config

With --jobs, JobTracker/ is added and ProcessJobMessage.cs / ProcessJobHandler.cs / JobSubmitterService.cs are included in the respective projects. With --deadletter, DeadLetterTracker/ is added alongside DeadLetterSampleMessage.cs / DeadLetterSampleMessageHandler.cs / FailingMessageSenderService.cs — the Receiver handles domain messages while DeadLetterTracker monitors dead-letter sub-queues and persists failed messages to the DB. With --dashboard, a standalone Dashboard/ project is added — a minimal ASP.NET Core web app that hosts the Flowly management UI at /flowly. The Receiver remains a pure background worker; wire in submitters and tracking connections yourself if you want those dashboard features active.

InMemory:

MyApp/
├── MyApp.slnx
└── App/                 ← single worker; sends and receives in-process (+ DB tracking when --jobs / --deadletter)

For RabbitMQ, each project's Program.cs automatically registers DotCaseTopologyNameResolver (dot-case naming is idiomatic in RabbitMQ, e.g. process.order). For ASB and InMemory, the default KebabCaseTopologyNameResolver (e.g. process-order) is used.

After scaffolding, start the local infrastructure (RabbitMQ or ASB only, skip for SQLite):

docker compose up -d

Then run each project:

dotnet run --project Sender            # or: dotnet run --project App
dotnet run --project Receiver
dotnet run --project JobTracker        # only when --jobs
dotnet run --project DeadLetterTracker # only when --deadletter (non-InMemory)
dotnet run --project Dashboard         # only when --dashboard (non-InMemory)

flowlyaspireapp — Scaffold a complete Aspire-based send/receive solution

Generates a full Aspire solution with an AppHost, ServiceDefaults, a Messages contracts library, a Sender, and a Receiver — all wired for the chosen transport. OpenTelemetry is always enabled (the Aspire dashboard depends on it). No docker-compose or sbconfig.json required; Aspire manages all infrastructure.

dotnet new flowlyaspireapp --transport <transport> [options] -n <SolutionName>

Transport (required)

Features (optional)

Database backend (required when --jobs or --deadletter is used)

Examples

# RabbitMQ with Aspire
dotnet new flowlyaspireapp --transport rabbitmq -n MyApp

# Azure Service Bus with Aspire
dotnet new flowlyaspireapp --transport asb -n MyApp

# InMemory with Aspire (single App project)
dotnet new flowlyaspireapp --transport inm -n MyApp

# RPC call/response with ASB
dotnet new flowlyaspireapp --transport asb --call -n MyApp

# RabbitMQ with job tracking (PostgreSQL) and dead-letter tracking
dotnet new flowlyaspireapp --transport rabbitmq --jobs --deadletter --db postgres -n MyApp

# ASB with job tracking (SQL Server)
dotnet new flowlyaspireapp --transport asb --jobs --db sqlserver -n MyApp

# InMemory with SQLite job tracking
dotnet new flowlyaspireapp --transport inm --jobs --db sqlite -n MyApp

# RabbitMQ with standalone Dashboard project
dotnet new flowlyaspireapp --transport rabbitmq --dashboard -n MyApp

What's generated

RabbitMQ / Azure Service Bus (baseline):

MyApp/
├── MyApp.slnx
├── MyApp.AppHost/              ← Aspire orchestrator; provisions broker and optional DB
├── MyApp.ServiceDefaults/      ← Standard Aspire OTel, health checks, service discovery
├── MyApp.Messages/             ← Shared message contracts
├── MyApp.Sender/               ← WebApplication; sends messages
├── MyApp.Receiver/             ← WebApplication; processes messages (pure handler worker)
├── MyApp.JobTracker/           ← only with --jobs: owns job state persistence
├── MyApp.DeadLetterTracker/    ← only with --deadletter: monitors DLQs, persists failed messages
└── MyApp.Dashboard/            ← only with --dashboard: standalone web app hosting the management UI at /

InMemory:

MyApp/
├── MyApp.slnx
├── MyApp.AppHost/           ← Aspire orchestrator (no broker to provision)
├── MyApp.ServiceDefaults/
└── MyApp.App/               ← Single WebApplication; sends and receives in-process

After scaffolding, run the AppHost to start everything:

dotnet run --project MyApp.AppHost

The Aspire dashboard opens automatically and shows all services, health checks, logs, and traces.

flowly — Scaffold a new Flowly project

dotnet new flowly --transport <transport> [options] -o <ProjectName>

Transport (required)

Pass via --transport <value>, e.g. --transport rabbitmq or --transport asb.

Features (optional)

Database backend (required when --jobs or --deadletter is used)

Examples

# Minimal RabbitMQ receiver
dotnet new flowly --transport rabbitmq -o Receiver

# Queue-only worker (no HTTP listener)
dotnet new flowly --transport rabbitmq --no-http -o Worker

# Azure Service Bus with job tracking (SQL Server) and dead-letter tracking
dotnet new flowly --transport asb --jobs --db sqlserver --deadletter -o Processor

# InMemory with all features, inline wiring
dotnet new flowly --transport inm --jobs --deadletter --db sqlite --otel --inline -o TestWorker

# RabbitMQ with Jaeger export (adds OTLP wiring and OTEL_EXPORTER_OTLP_ENDPOINT in launchSettings)
dotnet new flowly --transport rabbitmq --otel-export jaeger -o Receiver

# ASB with default OTLP export (gated on env var)
dotnet new flowly --transport asb --oe default -o Processor

What's generated

• <ProjectName>.csproj — with the correct Flowly package references for your chosen transport and features
• Program.cs — minimal ASP.NET Core entry point
• FlowlyConfiguration.cs — configuration class inheriting Flowly.Configuration (omitted when --inline)
• appsettings.json — base configuration
• appsettings.Development.json — development connection strings for your chosen transport and database

Notes

• Connection string names: RabbitMQ, AzureServiceBus, FlowlyJobs, FlowlyDeadLetters
• Migrations run automatically on startup by default — set enableMigrations: false to manage them externally
• Each scaffolded project gets a randomly assigned HTTP port (5000–5300) and HTTPS port (7000–7300), so multiple projects created from the template do not collide

flowlymessagelib — Scaffold a Flowly message contracts library

Creates a class library pre-wired with Flowly for holding shared message contracts. Reference this project from both your sender and receiver services.

dotnet new flowlymessagelib -o <ProjectName>

Options

Examples

# Minimal contracts library
dotnet new flowlymessagelib -o MyApp.Contracts

# Contracts library with job message support
dotnet new flowlymessagelib --jobs -o MyApp.Contracts

What's generated

• <ProjectName>.csproj — class library targeting net10.0 with a Flowly package reference (and Flowly.Jobs when --jobs is specified)
• MyMessage.cs — a starter record MyMessage(string Description) in the project's namespace
• MyJobMessage.cs — a starter record MyJobMessage implementing IJobMessage (only when --jobs is specified)

flowlyskills — Install Flowly Claude Code skills

Drops Flowly AI skills for Claude Code into .claude/skills/ in the current directory. Run this from your repository root so skills are available across all projects in the repo.

dotnet new flowlyskills

No options or project name required. The skills teach Claude Code how to scaffold message handlers, recurring jobs, contracts assemblies, and configure Flowly transports.