BuildQuickPkg 1.1.0

BuildQuickPkg

An interactive .NET CLI tool that scaffolds a complete Clean Architecture ASP.NET Core solution: API, Application, Domain, and (optionally) Infrastructure projects, already wired up, testable, and building in seconds. Stop hand-rolling the same folder structure and .csproj references for every new API.

📖 Full documentation (or browse in-repo): getting started, CLI reference, architecture guide, EF Core, Docker, JWT, microservices, and troubleshooting.

What it generates

Given a project name of MyAwesomeApi with the 4-layer architecture and tests enabled, the tool creates:

MyAwesomeApi/
├── MyAwesomeApi.sln
├── .gitignore
├── README.md
├── Dockerfile                         # (optional) multi-stage build → publish → run
├── docker-compose.yml                 # (optional) api + db services
├── src/
│   ├── MyAwesomeApi_API/              # Presentation layer (Minimal API, Swagger, CORS, launch profiles)
│   │   ├── Controllers/
│   │   ├── Extensions/
│   │   ├── Middlewares/
│   │   ├── Properties/launchSettings.json
│   │   ├── appsettings.json           # shared settings (logging, JWT issuer/audience, ...)
│   │   ├── appsettings.Development.json # local connection string + dev JWT signing key
│   │   ├── appsettings.Production.json  # secrets left blank, supplied via env vars
│   │   └── Program.cs
│   ├── MyAwesomeApi_Application/      # Use cases / business logic
│   │   ├── Services/Implementation/
│   │   ├── Services/Interfaces/
│   │   └── Utilities/
│   ├── MyAwesomeApi_Domain/           # Entities, DTOs, enums, no dependencies on other layers
│   │   ├── Dtos/RequestDtos/
│   │   ├── Dtos/ResponseDtos/
│   │   ├── Entity/
│   │   └── Enums/
│   └── MyAwesomeApi_Infrastructure/   # EF Core, external services, persistence
│       ├── Context/                   # (optional) generated DbContext when EF Core is selected
│       └── Migrations/
└── tests/
    └── MyAwesomeApi_API.Tests/        # xUnit + WebApplicationFactory integration tests
        └── HealthEndpointTests.cs

appsettings.json, per environment

Every generated API ships all three settings files, loaded by ASP.NET Core's standard appsettings.json → appsettings.{Environment}.json → environment variables layering:

API style

Choose Minimal API (top-level app.MapGet/app.MapPost calls in Program.cs) or Standard API (Controllers backed by an interface/service pair, the service-controller pattern). Every generated project has Controllers/, Services/Interfaces/, and Services/Implementation/ folders either way; Standard API is what actually populates them. Both styles expose the same URLs, so this only changes how the code is organized.

Optional add-ons

Three more prompts let you opt into common boilerplate at generation time:

• Entity Framework Core (None / PostgreSQL / SQL Server): adds the provider package plus Microsoft.EntityFrameworkCore.Design to the layer that owns Infrastructure/Context (the dedicated Infrastructure project in 4-layer, or Domain in 3-layer), generates a starter {ProjectName}DbContext, wires up AddDbContext in Program.cs, and writes matching connection strings into appsettings.Development.json.
• Dockerfile & docker-compose.yml: a multi-stage Dockerfile (SDK build → ASP.NET runtime) and a docker-compose.yml with an api service; when EF Core is also selected, a db service (Postgres or SQL Server) is included and wired up via ConnectionStrings__DefaultConnection.
• JWT Authentication boilerplate: adds Microsoft.AspNetCore.Authentication.JwtBearer, registers bearer-token authentication/authorization, and wires up two sample endpoints: POST /api/auth/token (issues a token) and GET /api/secure (requires one), so you can see it working immediately. In Standard API style, these are an AuthController + IAuthService/AuthService instead of top-level endpoints.

In microservice mode, each service gets its own appsettings.*, DbContext, Dockerfile, and docker-compose.yml.

Said no to one of these and want it later? BuildQuickPkg add efcore|jwt|docker|repository|env|caddy retrofits it onto a project you already generated, no regeneration needed. See Adding a Feature Later.

Project references are pre-wired according to Clean Architecture's dependency rule: API → Application, Infrastructure, Infrastructure → Application, Domain, Application → Domain, and Domain depends on nothing. The generated API project includes Swagger/OpenAPI, CORS, and Serilog structured logging out of the box, plus a sample /api/health endpoint, so the solution is immediately runnable and testable.

Two architecture options are offered at generation time:

• 4-layer: a dedicated Infrastructure project (shown above)
• 3-layer: Infrastructure concerns (Context/, Migrations/) folded into Domain/Infrastructure/ instead of a separate project, for smaller services that don't need the extra layer

Test project generation is optional; when enabled, it references the API project directly and includes a working WebApplicationFactory<Program>-based test for the health-check endpoint.

Monolithic vs. microservice

By default the tool generates a single solution (as above). Choose Microservice instead and it will ask how many services you need and what to name each one, then generate one fully independent Clean Architecture solution per service, with the same target framework, same architecture pattern, and same package versions across all of them:

ShopSystem/
├── ShopSystem.sln              # aggregate solution, builds every service at once
├── .gitignore
├── README.md
└── services/
    ├── OrderService/
    │   ├── OrderService.sln    # each service is also independently buildable/runnable
    │   ├── src/OrderService_API/ ...
    │   └── tests/OrderService.UnitTests/
    ├── InventoryService/
    │   └── ...
    └── PaymentService/
        └── ...

Each service gets its own HTTP/HTTPS ports, offset by 10 from your chosen base port so they don't collide when run side by side.

Structured logging (Serilog)

Every generated API ships with Serilog wired up via Serilog.AspNetCore: a console sink, UseSerilogRequestLogging() for per-request timing, and the standard fatal-exception/flush-on-shutdown bootstrap pattern in Program.cs.

Installation

dotnet tool install --global BuildQuickPkg

Upgrading, downgrading to a specific version, and uninstalling are covered in Managing your install.

Usage

BuildQuickPkg
# or, to skip the project-name prompt:
BuildQuickPkg MyAwesomeApi

You'll be prompted interactively for:

Then run the generated API:

cd MyAwesomeApi/src/MyAwesomeApi_API
dotnet run

Requirements

• .NET 8 SDK or later

Project source layout

The tool itself follows the same separation-of-concerns principle it generates for you:

BuildQuickPkg/
├── Program.cs                       # CLI entry point: routes to `add`, or runs the generation prompts
├── Commands/                        # `BuildQuickPkg add <feature>`: retrofits a feature onto an existing project
│   ├── AddFeatureCommand.cs         # Parses "efcore/jwt/docker/repository/env/caddy" and dispatches to the commands below
│   ├── AddEfCoreCommand.cs
│   ├── AddJwtCommand.cs
│   ├── AddDockerCommand.cs
│   ├── AddRepositoryCommand.cs      # Generic Repository/UnitOfWork (requires efcore first)
│   ├── AddEnvCommand.cs             # .env with dummy values matching the project's actual setup
│   ├── AddCaddyCommand.cs           # Caddyfile reverse proxy
│   └── HelpText.cs                  # --help / -h output for the root command and `add`
├── Scaffolding/
│   ├── ScaffoldingConfig.cs         # Options record: naming, architecture, API style, ports, tests, EF/Docker/JWT
│   ├── EfCoreProvider.cs            # None / PostgreSql / SqlServer
│   ├── ApiStyle.cs                  # Minimal / Controller
│   ├── SolutionScaffolder.cs        # Orchestrates folder creation, file writes, and `dotnet sln`
│   ├── ProjectStructure.cs          # Resolves layer project names and the folder tree (new projects)
│   ├── ExistingProject.cs           # Describes an already-generated project, resolved from disk
│   └── ExistingProjectLocator.cs    # Locates ExistingProject from the current working directory
├── Templates/
│   ├── CsprojTemplates.cs           # .csproj content for each layer (4-layer, 3-layer, test)
│   ├── ProgramTemplate.cs           # Generated API Program.cs (+ optional EF Core / JWT / Controller wiring)
│   ├── ControllerTemplate.cs        # Health/Auth Controller + service pairs for Standard API style
│   ├── RepositoryTemplate.cs        # Generic IRepository<T>/Repository<T> + IUnitOfWork/UnitOfWork
│   ├── AppSettingsTemplate.cs       # appsettings.json / .Development.json / .Production.json
│   ├── EfCoreTemplate.cs            # Generated DbContext + provider package/connection-string helpers
│   ├── DockerTemplate.cs            # Dockerfile + docker-compose.yml
│   ├── EnvTemplate.cs               # .env content matching the project's actual setup
│   ├── CaddyTemplate.cs             # Caddyfile reverse proxy
│   ├── HealthEndpointTestTemplate.cs # Generated xUnit health-check test
│   ├── LaunchSettingsTemplate.cs
│   └── GitignoreTemplate.cs
└── Utilities/
    ├── ProcessRunner.cs             # Wraps `dotnet` CLI process execution
    ├── CsprojEditor.cs              # Adds PackageReferences to an existing .csproj (used by `add`)
    ├── ProgramCsEditor.cs           # Patches an existing Program.cs at its stable markers (used by `add`)
    ├── AppSettingsEditor.cs         # Merges JSON sections into an existing appsettings*.json (used by `add`)
    ├── ProjectFeatureDetector.cs    # Reads an existing project's actual EF Core/JWT/API style/port (used by `add`)
    └── NameValidation.cs            # Validates a project/service name is safe as a C# namespace + folder name

Contributing

Issues and pull requests are welcome. See CONTRIBUTING.md for how to get set up, add a new generation option, and test your change.

License

MIT. See LICENSE.