dotnet-service-patterns

Guides design and implementation of modular .NET services using DI scanning, providers, pipelines, and plugin hosting.

Updated Jul 24, 2026
One-click install
npx skills add https://github.com/gweone/agent-plugins --skill dotnet-service-patterns-gweone
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dotnet-service-patterns
Source: https://github.com/gweone/agent-plugins/tree/main/plugin/sharpps-dotnet/skills/dotnet-service-patterns
Command: npx skills add https://github.com/gweone/agent-plugins --skill dotnet-service-patterns-gweone

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large .NET solutions split into many independently-shipped projects repeatedly reinvent four problems: wiring services into dependency injection without a central registration file, supporting interchangeable backend implementations, running ordered extensible step sequences, and discovering plugin modules at runtime. This Skill provides four verified patterns from the SharpPS solution that answer each problem. ## Core Features & Use Cases - Convention-based DI auto-registration: Marker interfaces (IService, IServiceScoped, IServiceSingleton) plus an assembly scanner eliminate hand-maintained central registration lists across modules. - Pluggable provider pattern: Fluent builder registration (AddStorage, UseGoogleDriveStorage) enables named, configuration-selected backend implementations without switch statements. - Lightweight processor pipeline: IProcessor<TArgs> with patch-based reordering (MoveBefore, ReplaceWith, Remove) lets modules extend cross-cutting flows without editing each other's code. - Plugin-style host bootstrap: A single AspNetHosting.Main entry point loads feature assemblies via isolated AssemblyLoadContext with per-hostname filtering and per-module JSON configuration. - Use Case: When building a new ASP.NET Core feature module in a multi-project solution, apply these patterns to ship it as a NuGet package that a host discovers and loads without any compile-time reference. ## Quick Start Ask the AI to design a new .NET feature module using the SharpPS service patterns with auto-registered DI services and a pipeline-based startup hook.

Frequently Asked Questions about dotnet-service-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I auto-register services in .NET dependency injection?

Define marker interfaces like IService, IServiceScoped, and IServiceSingleton, then write one RegisterServices extension that reflects over an assembly and registers each implementing class with the lifetime its marker names. Each module ships one configurator class calling this scanner.

How to implement multiple interchangeable storage providers in .NET?

Define one interface all backends implement with a Name and Initialize method, then use a fluent builder where each backend ships its own Use extension registering the provider type per name. Resolve the default named options via IOptionsMonitor and re-resolve per name inside Initialize.

When should I use a processor pipeline instead of a mediator library?

Use a lightweight IProcessor<TArgs> pipeline when steps are contributed by multiple modules and need reordering via patch operations like MoveBefore or ReplaceWith. For a fixed single-module sequence, plain method calls are simpler and sufficient.

Can ASP.NET Core load plugin assemblies at runtime?

Yes, by scanning a plugin directory, loading each assembly through an isolated AssemblyLoadContext, registering controllers as MVC application parts, and running per-assembly service configuration. A manifest file can filter which hostnames each plugin serves.

When is convention-based DI registration not worth it?

Skip marker-interface scanning for single-project apps or a handful of services, where plain AddFoo extension methods are simpler and more discoverable. The pattern pays off only when many independently-shipped modules would otherwise require a central registration list.