Introduction

In .NET 6 minimal hosting, Startup.cs is optional and often absent by design. Projects created from modern templates typically configure services and middleware directly in Program.cs. Developers migrating from ASP.NET Core 3.1/5 can mistake this for a missing-file error. The right fix is to understand hosting model differences and apply configuration in the correct place.

Core Sections

1. Minimal hosting pattern in .NET 6

1var builder = WebApplication.CreateBuilder(args);
2
3builder.Services.AddControllers();
4
5var app = builder.Build();
6
7app.UseHttpsRedirection();
8app.MapControllers();
9
10app.Run();

No Startup class required.

2. Mapping old Startup methods

Legacy:

• ConfigureServices -> builder.Services...
• Configure -> app.Use... / app.Map...

This direct mapping simplifies app bootstrapping.

3. When keeping Startup still makes sense

Large codebases sometimes keep a Startup-style class for separation. You can still call custom extension methods from Program.cs to preserve structure.

4. Common migration issue patterns

• docs/tutorial expects Startup.cs
• reflection-based code looks for Startup type
• partial migration mixes old/new hosting APIs

Resolve by updating integration points to minimal hosting conventions.

5. Environment-specific configuration

Use builder configuration and appsettings as usual; minimal hosting does not remove environment/profile support.

6. Testing implications

Integration tests using WebApplicationFactory may need updates if they relied on Startup class type arguments.

Validation and production readiness

A solution that works once in a local test is not enough for long-term reliability. Add explicit validation around inputs, outputs, and failure paths so behavior remains predictable after refactors. Start with a compact test matrix that covers expected inputs, boundary values, malformed values, and one realistic load scenario. This catches most regressions before they reach runtime environments where debugging is slower and costlier.

When external dependencies are involved, verify the unhappy path intentionally. Simulate missing files, network timeouts, permission errors, and unavailable services. The goal is to confirm the code fails in a controlled, observable way. Silent failure, broad exception swallowing, and unbounded retries are frequent causes of production incidents. Prefer explicit failure states and bounded retry policies.

1reliability_checklist:
2  - happy path tested with representative data
3  - boundary and malformed cases tested
4  - timeouts and retries are bounded
5  - dependency failures produce clear errors
6  - logs and metrics expose outcome and latency

Observability should be designed into the implementation, not added later. Emit structured logs for key branch decisions and final outcomes. Include identifiers and context needed for triage, but avoid sensitive payloads. For asynchronous or multi-step flows, add correlation IDs so related events can be traced end-to-end. If the workflow is performance sensitive, record duration metrics and establish rough service-level thresholds.

Configuration discipline is equally important. Keep environment-specific values (paths, credentials, endpoints, feature flags) outside code and validate them at startup. Fail fast on invalid configuration rather than partially starting with broken defaults. In team settings, document required runtime versions and compatibility constraints near the code so local, CI, and production environments behave consistently.

Before shipping, run a lightweight rollout checklist that includes backward compatibility, rollback strategy, and smoke verification steps. For data or schema changes, include idempotency checks so reruns do not create duplicates or corruption. Teams that standardize these practices usually spend less time on repeated incident triage and more time delivering reliable improvements.

Common Pitfalls

• Assuming missing Startup.cs means broken project template.
• Copying old Startup code verbatim without adapting to Program.cs.
• Mixing obsolete host builder APIs with minimal hosting.
• Forgetting to map endpoints after service registration.
• Keeping outdated docs/examples in team wiki after migration.

Summary

Startup.cs being missing in .NET 6 is usually expected with minimal hosting. Move service and middleware setup into Program.cs or wrap them in extension methods for organization. Once migration conventions are applied consistently, app behavior remains equivalent and easier to maintain.