Create projects with Forge templates¶
Forge templates create an application's starting structure and add capabilities to an existing project. For a first application, follow the guided tutorial; use this page when you need to discover template options or understand the generated test runner.
Setup¶
Install Production Templates¶
Follow SAIF CLI installation for NuGet feed access and tool setup. saif doctor fix installs or updates the platform tools and templates.
Creating and Using Templates¶
Using SAIF CLI¶
List templates and inspect the selected template's options before generation:
--no-publish keeps generation local. Without it, the normal saif new flow also publishes the repository and registers its pipelines. See the first application tutorial for the full journey and pipeline reference for the resulting pipeline files.
Provide parameters upfront¶
saif new <template> prompts for each required parameter. Pass the parameters on the command line to skip the prompts, for example saif new saif-event-service --name myapp --owner Platform. Each template's --help output and its task guide list the parameters it accepts.
Generation succeeded when the CLI reports that files were generated, prints no errors, and creates the new project folder. Change into that folder with cd <your-project-name> before continuing with the template's task guide.
An agent can use Forge MCP's list_templates and get_template to discover names and parameters without invoking the shell.
Using dotnet new¶
The underlying package is SAIF.Platform.Templates. For direct .NET template use after configuring the feed:
Review the chosen template's parameters and post-actions before generating. Use saif new when you want Forge's publishing workflow; direct dotnet new generation does not replace that workflow.
Post-Generation¶
Open the generated solution, start its AppHost, and verify the resources in the Aspire dashboard. The tutorial's local-run steps cover this sequence.
Generated project layout¶
Service templates share a top-level layout. Pipeline file names vary by template: the event service template generates azure-pipelines.yml, while API and frontend templates generate one pair per component, such as azure-pipelines-api.yml or azure-pipelines-web.yml. Each template's task guide describes the folders specific to that service type.
your-project/
├── .azdo/ # Azure Pipelines configuration
│ ├── azure-pipelines[-<component>].yml # Deployment pipeline
│ ├── azure-pipelines[-<component>]-pr.yml # Pull request validation pipeline
│ └── vars/ # Pipeline variables
├── infra/ # Infrastructure as Code (Terraform)
│ ├── bootstrap/ # Environment bootstrapping
│ └── <component>/ # Service infrastructure, e.g. api/, event/, web/
├── src/ # Source code
└── .gitignore
.azdo/holds the PR validation and deployment pipelines; see the pipeline reference.infra/holds the Terraform configuration for the service's Azure resources.src/holds the application, AppHost, and TypeSpec projects the template generates.
Test Execution: Native Microsoft Testing Platform (MTP)¶
Follow Testing for the generated runner configuration, test selectors, coverage command, and prerequisites when adding tests to an older application. That page owns the test-execution instructions.
Contributor documentation¶
Template authoring, composition, and local validation belong in the repository contributor guide, not the application setup path.