What this prompt does
This prompt makes the model a senior .NET architect reviewing dependency injection in a large ASP.NET Core app, returning concrete recommendations with code. You supply [dotnet_version], [app_shape], [pain_points], and [registration_style], and it audits service lifetimes for captive-dependency risks, recommends module-style registration, demonstrates keyed services, sets up a typed HttpClient with resilience, applies the options pattern with ValidateOnStart, and flags anti-patterns.
The structure works because it starts where the expensive, subtle bugs actually live — service lifetimes. A Singleton holding a Scoped service leaks state across requests and nobody notices until production, so the audit leads with lifetime mismatches before touching anything cosmetic. [registration_style] tells the model what your Program.cs looks like now (for example, everything registered inline), [pain_points] focuses the review on your known issues, [app_shape] sets the scale, and [dotnet_version] decides which features like keyed services are available. Because it returns before/after registration snippets rather than abstract advice, you can compare your current wiring against the recommended module-style version directly and apply the change with full context for why it matters.
When to use it
- Your
Program.cshas grown into a tangled wall of inline registrations. - You suspect captive dependencies — a Singleton capturing a Scoped service.
- You want module-style registration to keep startup clean and testable.
- You need keyed services to swap implementations by key on a modern .NET version.
- You're wiring a typed HttpClient and want named config plus resilience handlers.
- You want config classes validated at startup with the options pattern.
Example output
Expect a prioritized findings list led by lifetime and captive-dependency issues, followed by before/after registration snippets: the tangled inline Program.cs versus module-style extension methods, keyed-service examples, a typed HttpClient registration with resilience, and options-pattern config with ValidateOnStart. Anti-patterns like service locator and over-Singleton-ing are called out with the fix.
Pro tips
- Describe
[pain_points]honestly — "suspected captive deps" or "bloated Program.cs" steers the audit to what actually hurts. - Set
[dotnet_version]accurately; keyed services and some options features only exist on newer versions. - Start with the step 1 lifetime findings; mismatched lifetimes cause more incidents than any missing feature.
- Use
[registration_style]to show the current state so the before/after snippets reflect your real code. - Apply ValidateOnStart so misconfigured options fail fast at boot instead of mid-request.
- After refactoring registration into modules, re-run the audit to confirm no new captive dependencies crept in.
- Use the typed HttpClient with resilience handlers for outbound calls; a raw HttpClient created per request is a classic source of socket exhaustion.
- Reach for keyed services only where you genuinely swap implementations by key — overusing them just trades one form of complexity for another.
- Treat the anti-pattern flags as a checklist for the whole team, since service locator and over-Singleton-ing tend to spread by copy-paste once one example exists.
