aspnet-core-service-workflow

ASP.NET Core Service Workflow

Purpose

Build or modify an ASP.NET Core service with clear ownership, configuration, endpoints, tests, and validation.

The practical decision is what the service exposes, which project owns the HTTP host, where domain logic lives, how configuration reaches the app, and how tests prove behavior without turning the whole service into a fragile integration fixture.

When To Use

• Use this skill when adding or changing an ASP.NET Core API or service.
• Use this skill when deciding whether a .NET project should be a web service or a library consumed by one.
• Use this skill when adding endpoints, middleware, configuration, dependency injection, or service tests.
• Use this skill after dotnet:choose-project-shape has identified an ASP.NET Core service shape.

Source Check

Use repo-local .NET files, checked-out dependency sources, Dash MCP or Dash HTTP for installed .NET docsets, and then official Microsoft documentation when Dash/local coverage is missing or stale:

• ASP.NET Core documentation
• Minimal APIs documentation
• ASP.NET Core configuration
• ASP.NET Core dependency injection
• ASP.NET Core integration tests

Planning Workflow

1. Inspect project shape:
   • web project
   • domain library
   • test project
   • config files
   • existing endpoints
   • existing hosting style
2. Identify the service job:
   • HTTP API
   • local service
   • webhook receiver
   • background worker plus HTTP health surface
   • internal admin tool
3. Choose language and boundary:
   • F# service
   • C# service
   • C# host with F# domain library
   • F# host with C# infrastructure library
4. Keep domain logic outside endpoint handlers when it has real behavior.
5. Keep configuration explicit and environment-safe.
6. Add tests at the smallest useful level.
7. Validate with dotnet build and dotnet test.