You can build up a hierarchical tree structure from containers by creating more child containers with the `.CreateChildContainer()` method.
```cs
using var container = new StashboxContainer();
var child1 = container.CreateChildContainer();
var child2 = child1.CreateChildContainer();
```
You have the option to register multiple decorators for a service to extend its functionality.
The decoration order will be the same as the registration order of the decorators. The first registered decorator will decorate the service itself. Then, all the subsequent decorators will wrap the already decorated service.
```cs
container.Register();
container.RegisterDecorator();
container.RegisterDecorator();
// new ValidatorProcessor(new LoggerProcessor(new GeneralProcessor()));
var processor = container.Resolve();
```
Just as other registrations, decorators also can have their lifetime. It means, in addition to the service's lifetime, all decorator's lifetime will be applied to the wrapped service.
:::note
When you don't set a decorator's lifetime, it'll implicitly inherit the decorated service's lifetime.
:::
```cs
container.Register();
// singleton decorator will change the transient
// decorated service's lifetime to singleton.
container.RegisterDecorator(options =>
options.WithLifetime(Lifetimes.Singleton));
// Singleton[new ValidatorProcessor()](Transien[new GeneralEventProcessor()])
var processor = container.Resolve();
```
Decorators are also applied to wrapped services. It means, in addition to the decoration, you can wrap your services in supported [wrappers](/docs/advanced/wrappers-resolvers#wrappers).
```cs
container.Register();
container.RegisterDecorator();
// () => new ValidatorProcessor(new GeneralEventProcessor())
var processor = container.Resolve>();
```
The registration of a closed-generic type does not differ from registering a simple non-generic service.
You have all options available that you saw at the [basic](/docs/guides/basics) and [advanced registration](/docs/guides/advanced-registration) flows.
Open-generic types could help in such scenarios where you have generic interface-implementation pairs with numerous generic parameter variations. The registration of those different versions would look like this:
```cs
container.Register, Validator>();
container.Register, Validator>();
container.Register, Validator>();
// and so on...
```
Rather than doing that, you can register your type's generic definition and let Stashbox bind the type parameters for you. When a matching closed [service type](/docs/getting-started/glossary#service-type--implementation-type) is requested, the container will construct an equivalent closed-generic implementation.
```cs
container.Register(typeof(IValidator<>), typeof(Validator<>));
// Validator will be returned.
IValidator userValidator = container.Resolve>();
// Validator will be returned.
IValidator roleValidator = container.Resolve>();
```
A registered closed-generic type always has priority over an open-generic type at service selection.
```cs
container.Register, UserValidator>();
container.Register(typeof(IValidator<>), typeof(Validator<>));
// UserValidator will be returned.
IValidator validator = container.Resolve>();
```
### Enumerable
Stashbox can compose a collection from each implementation registered to a [service type](/docs/getting-started/glossary#service-type--implementation-type). The requested type can be wrapped by any of the collection interfaces that a .NET `Array` implements.
```cs
IJob[] jobs = container.Resolve();
IEnumerable jobs = container.Resolve>();
IList jobs = container.Resolve>();
ICollection jobs = container.Resolve>();
IReadOnlyList jobs = container.Resolve>();
IReadOnlyCollection jobs = container.Resolve>();
```
### Lazy
When requesting `Lazy<>`, the container implicitly constructs a new `Lazy<>` instance with a factory delegate as its constructor argument used to instantiate the underlying service.
```cs
container.Register();
// new Lazy(() => new DbBackup())
Lazy lazyJob = container.Resolve>();
IJob job = lazyJob.Value;
```
### Delegate
When requesting a `Delegate`, the container implicitly creates a factory used to instantiate the underlying service.
It's possible to request a delegate that expects some or all of the dependencies as delegate parameters.
Parameters are used for sub-dependencies as well, like: `(arg) => new A(new B(arg))`
When a dependency is not available as a parameter, it will be resolved from the container directly.
### Metadata & Tuple
With the `.WithMetadata()` registration option, you can attach additional information to a service.
To gather this information, you can request the service wrapped in either `Metadata<,>`, `ValueTuple<,>`, or `Tuple<,>`.
`Metadata<,>` is a type from the `Stashbox` package, so you might prefer using `ValueTuple<,>` or `Tuple<,>` if you want to avoid referencing Stashbox in certain parts of your project.
You can also filter a collection of services by their metadata. Requesting `IEnumerable>` will yield only those services that have the given type of metadata.
### KeyValuePair & ReadOnlyKeyValue
With named registration, you can give your service unique identifiers. Requesting a service wrapped in a `KeyValuePair` or `ReadOnlyKeyValue` returns the requested service with its identifier as key.
`ReadOnlyKeyValue<,>` is a type from the `Stashbox` package, so you might prefer using `KeyValuePair<,>` if you want to avoid referencing Stashbox in certain parts of your project.
Requesting an `IEnumerable>` will return all services of the requested type along their identifiers. When a service don't have an identifier the `Key` will be set to `null`.
```cs
container.Register("FirstServiceId");
container.Register("SecondServiceId");
container.Register();
var serviceKeyValue1 = container
.Resolve>("FirstServiceId");
// prints: "FirstServiceId"
Console.WriteLine(serviceKeyValue1.Key);
var serviceKeyValue2 = container
.Resolve>("SecondServiceId");
// prints: "SecondServiceId"
Console.WriteLine(serviceKeyValue2.Key);
// ["FirstServiceId": Service1, "SecondServiceId": Service2, null: Service3 ]
var servicesWithKeys = container.Resolve[]>();
```
The container's constructor has an `Action` parameter used to configure its behavior.
The configuration API is fluent, which means you can chain the configuration methods after each other.
```cs
var container = new StashboxContainer(options => options
.WithDisposableTransientTracking()
.WithConstructorSelectionRule(Rules.ConstructorSelection.PreferLeastParameters)
.WithRegistrationBehavior(Rules.RegistrationBehavior.ThrowException));
```
**Re-configuration** of the container is also supported by calling its `.Configure()` method.
```cs
var container = new StashboxContainer();
container.Configure(options => options.WithDisposableTransientTracking());
```
With this option, you can enable or disable the tracking of disposable transient objects.
```cs
new StashboxContainer(options => options
.WithDisposableTransientTracking());
```
### `PropertiesWithPublicSetter`
With this flag, the container will perform auto-injection on properties with public setters.
```cs
new StashboxContainer(options => options
.WithAutoMemberInjection(
Rules.AutoMemberInjectionRules.PropertiesWithPublicSetter));
```
### `PropertiesWithLimitedAccess`
With this flag, the container will perform auto-injection on properties even when they don't have a public setter.
```cs
new StashboxContainer(options => options
.WithAutoMemberInjection(
Rules.AutoMemberInjectionRules.PropertiesWithLimitedAccess));
```
### `PrivateFields`
With this flag, the container will perform auto-injection on private fields too.
```cs
new StashboxContainer(options => options
.WithAutoMemberInjection(
Rules.AutoMemberInjectionRules.PrivateFields));
```
### Combined rules
You can also combine these flags with bitwise logical operators to get a merged ruleset.
```cs
new StashboxContainer(options => options
.WithAutoMemberInjection(Rules.AutoMemberInjectionRules.PrivateFields |
Rules.AutoMemberInjectionRules.PropertiesWithPublicSetter));
```
#### Member selection filter
You can pass your own member selection logic to control which members should be auto injected.
```cs
new StashboxContainer(options => options
.WithAutoMemberInjection(
filter: member => member.Type != typeof(ILogger)));
```
With this option, you can enable or disable the auto injection of members defined with C# 11's [`required`](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/required) keyword.
```cs
new StashboxContainer(options => options
.WithRequiredMemberInjection(enabled: false));
```
### `PreferMostParameters`
It prefers the constructor which has the most extended parameter list.
```cs
new StashboxContainer(options => options
.WithConstructorSelectionRule(
Rules.ConstructorSelection.PreferMostParameters));
```
### `PreferLeastParameters`
It prefers the constructor which has the shortest parameter list.
```cs
new StashboxContainer(options => options
.WithConstructorSelectionRule(
Rules.ConstructorSelection.PreferLeastParameters));
```
### `SkipDuplications`
The container will skip new registrations when the given [implementation type](/docs/getting-started/glossary#service-type--implementation-type) is already registered.
```cs
new StashboxContainer(options => options
.WithRegistrationBehavior(
Rules.RegistrationBehavior.SkipDuplications));
```
### `ThrowException`
The container throws an [exception](/docs/diagnostics/validation#servicealreadyregisteredexception) when the given [implementation type](/docs/getting-started/glossary#service-type--implementation-type) is already registered.
```cs
new StashboxContainer(options => options
.WithRegistrationBehavior(
Rules.RegistrationBehavior.ThrowException));
```
### `ReplaceExisting`
The container will replace the already [registered service](/docs/getting-started/glossary#service-registration--registered-service) with the given one when they have the same [implementation type](/docs/getting-started/glossary#service-type--implementation-type).
```cs
new StashboxContainer(options => options
.WithRegistrationBehavior(
Rules.RegistrationBehavior.ReplaceExisting));
```
### `PreserveDuplications`
The container will keep registering the new services with the same [implementation type](/docs/getting-started/glossary#service-type--implementation-type).
```cs
new StashboxContainer(options => options
.WithRegistrationBehavior(
Rules.RegistrationBehavior.PreserveDuplications));
```
With this option, you can set the default lifetime used when a service doesn't have a configured one.
```cs
new StashboxContainer(options => options
.WithDefaultLifetime(Lifetimes.Scoped));
```
With this option, you can enable or disable the life-span and [root scope](/docs/getting-started/glossary#root-scope) resolution [validation](/docs/diagnostics/validation#lifetime-validation) on the dependency tree.
```cs
new StashboxContainer(options => options
.WithLifetimeValidation());
```
With this option, you can enable or disable the check for [generic covariance and contravariance](/docs/advanced/generics#variance) during the resolution of generic type collections.
_This option is enabled by default_.
```cs
new StashboxContainer(options => options
.WithVariantGenericTypes());
```
With this option, you can enable or disable the throwing of a `ResolutionFailedException` when no services are found for a collection resolution request. When this feature is disabled _(default)_, the container returns an empty array for those request.
```cs
new StashboxContainer(options => options
.WithExceptionOverEmptyCollection());
```
With this option, you can enable or disable conventional resolution, which means the container treats the constructor/method parameter or member names as dependency names used by [named resolution](/docs/getting-started/glossary#named-resolution).
```cs
new StashboxContainer(options => options
.TreatParameterAndMemberNameAsDependencyName());
```
With this option, you can enable or disable the selection of named registrations when the resolution request is un-named but with the same type.
The `enabledForCollectionRequests` argument controls whether named registrations should be returned for an unnamed collection resolution request. It's **enabled** by default.
```cs
new StashboxContainer(options => options
.WithNamedDependencyResolutionForUnNamedRequests(
enabled: true,
enabledForCollectionRequests: true
));
```
### `WithUniversalName`
Sets the universal name that represents a special name which allows named resolution work for any given name.
```cs
new StashboxContainer(options => options
.WithUniversalName("Any"));
```
### `WithAdditionalDependencyNameAttribute`
Adds an attribute type that is considered a dependency name indicator just like the [`DependencyName` attribute](/docs/guides/service-resolution#attributes).
```cs
new StashboxContainer(options => options
.WithAdditionalDependencyNameAttribute());
```
### `WithAdditionalDependencyAttribute`
Adds an attribute type that is considered a dependency indicator just like the [`Dependency` attribute](/docs/guides/service-resolution#attributes).
```cs
new StashboxContainer(options => options
.WithAdditionalDependencyAttribute());
```
### `WithIgnoreServicesWithUniversalNameForUniversalNamedRequests`
Enables or disables the selection of services with `UniversalName` for a universal named resolution request.
```cs
new StashboxContainer(options => options
.WithIgnoreServicesWithUniversalNameForUniversalNamedRequests());
```
### `WithForceThrowWhenNamedDependencyIsNotResolvable`
Enables or disables throwing a `ResolutionFailedException` when a named dependency is not resolvable. Requests initiated by `.ResolveOrDefault()` may also throw when a named subdependency is not resolvable for example through the `Dependency` attribute.
```cs
new StashboxContainer(options => options
.WithForceThrowWhenNamedDependencyIsNotResolvable());
```
With this option, you can override the default `ResolutionFailedException` type thrown when the service resolution fails.
The details of the exception remain the same, only the type gets overridden.
```cs
new StashboxContainer(options => options
.OverrideResolutionFailedExceptionWith());
```
With this option, you can enable or disable the default value injection.
```cs
new StashboxContainer(options => options
.WithDefaultValueInjection());
```
With this option, you can enable or disable the resolution of unregistered types. You can also use a configurator delegate to configure the registrations the container will create from the unknown types.
```cs
new StashboxContainer(options => options
.WithUnknownTypeResolution(config => config.AsImplementedTypes()));
```
With this option, you can set an external expression tree compiler. It can be useful on platforms where the IL generator modules are not available; therefore, the expression compiler in Stashbox couldn't work.
```cs
new StashboxContainer(options => options
.WithExpressionCompiler(
Rules.ExpressionCompilers.MicrosoftExpressionCompiler));
```
With this option, you can enable or disable the re-building of singletons in child containers. It allows the child containers to override singleton dependencies in the parent.
```cs
new StashboxContainer(options => options
.WithReBuildSingletonsInChildContainer());
```
Most of the registration methods have an `Action` parameter, enabling several customization options on the given registration.
Here are three examples that show how the API's usage looks like.
They cover the exact functionalities you've read about in the [basics](/docs/guides/basics) section but are achieved with the options API.
The registration configuration API is fluent, which means all option methods can be chained after each other.
This provides an easier way to configure complicated registrations.
```cs
container.Register(options => options
.WithName("DbBackup")
.WithLifetime(Lifetimes.Singleton)
.WithoutDisposalTracking());
```
### `WithName`
Sets the name identifier of the registration.
```cs
container.Register(config => config
.WithName("Console"));
```
### `WithInstance`
Sets an existing instance for the registration.
Passing true for the `wireUp` parameter means that the container performs member / method injection on the registered instance.
### `WithoutDisposalTracking`
Force disables the disposal tracking on the registration.
```cs
container.Register(options => options
.WithoutDisposalTracking());
```
### `WithMetadata`
Sets additional metadata for the registration. It's attached to the service upon its resolution through `ValueTuple<,>`, `Tuple<,>`, or `Metadata<,>` wrappers.
```cs
container.Register(options => options
.WithMetadata(connectionString));
var jobWithConnectionString = container.Resolve>();
Console.WriteLine(jobWithConnectionString.Item2); // prints the connection string.
```
### `WithDynamicResolution`
Indicates that the service's resolution should be handled by a dynamic `Resolve()` call on the current `IDependencyResolver` instead of a pre-built instantiation expression.
```cs
container.Register();
container.Register(options => options
.WithDynamicResolution());
// new DbBackup(currentScope.Resolve());
var job = container.Resolve();
```
### `HasServiceType`
Used to build conditions based on service type in batch/assembly registrations.
It determines whether the registration is mapped to the given service type.
```cs
container.RegisterAssemblyContaining(configurator: options =>
{
if (options.HasServiceType())
options.WithScopedLifetime();
});
```
### `WithFinalizer`
Sets a custom cleanup delegate that will be invoked when the scope / container holding the instance is being disposed.
```cs
container.Register(options => options
.WithFinalizer(logger => logger
.CloseFile()));
```
### `WithInitializer`
Sets a custom initializer delegate that will be invoked when the given service is being instantiated.
```cs
container.Register(options => options
.WithInitializer((logger, resolver) => logger
.OpenFile()));
```
### `AsImplementedTypes`
The service will be mapped to all of its implemented interfaces and base types.
```cs
container.Register(options => options
.AsImplementedTypes());
```
### `AsServiceAlso`
Binds the currently configured registration to an additional [service type](/docs/getting-started/glossary#service-type--implementation-type). The registered type must implement or extend the additional [service type](/docs/getting-started/glossary#service-type--implementation-type).
```cs
container.Register(options => options
.AsServiceAlso()
// or
.AsServiceAlso(typeof(IRepository)));
```
### `WithSingletonLifetime`
Sets a singleton lifetime for the registration.
```cs
container.Register(config => config
.WithSingletonLifetime());
```
### `WithScopedLifetime`
Sets a scoped lifetime for the registration.
```cs
container.Register(config => config
.WithScopedLifetime());
```
### `WithPerRequestLifetime`
Sets the lifetime to `PerRequestLifetime`. This lifetime will create a new instance between resolution requests. Within the request the same instance will be re-used.
```cs
container.Register(options => options
.WithPerRequestLifetime());
```
### `WithAutoLifetime`
Sets the lifetime to auto lifetime. This lifetime aligns to the lifetime of the resolved service's dependencies. When the underlying service has a dependency with a higher lifespan, this lifetime will inherit that lifespan up to a given boundary.
```cs
container.Register(options => options
.WithAutoLifetime(Lifetimes.Scoped /* boundary lifetime */));
```
### `WithLifetime`
Sets a custom lifetime for the registration.
```cs
container.Register(config => config
.WithLifetime(new CustomLifetime()));
```
### `WhenHas`
Sets an attribute condition for the registration.
```cs
container.Register(config => config
.WhenHas());
```
### `WhenResolutionPathHas`
Sets a resolution path condition for the registration. The service will be selected only in the resolution path of the target that has the given attribute.
This means that only the direct and sub-dependencies of the target type that has the given attribute will get the configured service.
```cs
container.Register(config => config
// Each direct and sub-dependency of any service that has
// a ConsoleAttribute will get FileLogger wherever they
// depend on ILogger.
.WhenResolutionPathHas());
```
### `WhenDependantIs`
Sets a parent target condition for the registration.
```cs
container.Register(config => config
.WhenDependantIs());
```
### `WhenInResolutionPathOf`
Sets a resolution path condition for the registration. The service will be selected only in the resolution path of the given target.
This means that only the direct and sub-dependencies of the target type will get the configured service.
```cs
container.Register(config => config
// Each direct and sub-dependency of UserRepository
// will get FileLogger wherever they depend on ILogger.
.WhenInResolutionPathOf());
```
### `When`
Sets a custom user-defined condition for the registration.
```cs
container.Register(config => config
.When(typeInfo => typeInfo.ParentType == typeof(UserRepository)));
```
### `WithConstructorSelectionRule`
Sets the constructor selection rule for the registration.
```cs
container.Register(options => options
.WithConstructorSelectionRule(...));
```
#### PreferMostParameters
Selects the constructor which has the longest parameter list.
```cs
options.WithConstructorSelectionRule(
Rules.ConstructorSelection.PreferMostParameters)
```
#### PreferLeastParameters
Selects the constructor which has the shortest parameter list.
```cs
options.WithConstructorSelectionRule(
Rules.ConstructorSelection.PreferLeastParameters)
```
#### Custom
You can set your own custom constructor ordering logic.
```cs
options.WithConstructorSelectionRule(
constructors => { /* custom constructor sorting logic */ })
```
### `WithConstructorByArgumentTypes`
Selects a constructor by its argument types.
```cs
container.Register(options => options
.WithConstructorByArgumentTypes(typeof(ILogger)));
```
### `WithConstructorByArguments`
Selects a constructor by its arguments to use during resolution. These arguments are used to invoke the selected constructor.
```cs
container.Register(options => options
.WithConstructorByArguments(new ConsoleLogger()));
```
### `WithAutoMemberInjection`
Enables the auto member injection and sets the rule for it.
```cs
container.Register(options => options
.WithAutoMemberInjection(...));
```
#### PropertiesWithPublicSetter
With this flag, the container will perform auto-injection on properties with a public setter.
```cs
options.WithAutoMemberInjection(
Rules.AutoMemberInjectionRules.PropertiesWithPublicSetter)
```
#### PropertiesWithLimitedAccess
With this flag, the container will perform auto-injection on properties which has a non-public setter as well.
```cs
options.WithAutoMemberInjection(
Rules.AutoMemberInjectionRules.PropertiesWithLimitedAccess)
```
#### PrivateFields
With this flag, the container will perform auto-injection on private fields too.
```cs
options.WithAutoMemberInjection(
Rules.AutoMemberInjectionRules.PrivateFields)
```
#### Combined rules
As these rules are [bit flags](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/enum#enumeration-types-as-bit-flags), you can use them combined together with bitwise logical operators.
```cs
options.WithAutoMemberInjection(Rules.AutoMemberInjectionRules.PrivateFields |
Rules.AutoMemberInjectionRules.PropertiesWithPublicSetter)
```
#### Member selection filter
You can pass your own member selection logic to control which members should be auto injected.
```cs
container.Register(options => options
.WithAutoMemberInjection(filter: member => member.Type != typeof(ILogger)));
```
With this option, you can enable or disable the auto injection of members defined with C# 11's [`required`](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/required) keyword.
```cs
container.Register(options => options
.WithRequiredMemberInjection(enabled: false));
```
### `WithInjectionParameters`
Sets multiple injection parameters for the registration.
```cs
container.Register(options => options
.WithInjectionParameters(new KeyValuePair("logger", new ConsoleLogger()));
```
### `WithInjectionParameter`
Sets a single injection parameter for the registration.
```cs
container.Register(options => options
.WithInjectionParameter("logger", new ConsoleLogger());
```
### `InNamedScope`
Sets a scope name condition for the registration; it will be used only when a scope with the same name requests it.
```cs
container.Register(options => options
.InNamedScope("UserRepo"));
```
### `InScopeDefinedBy`
Sets a condition for the registration; it will be used only within the scope defined by the given type.
```cs
container.Register(options => options
.InScopeDefinedBy());
container.Register(options => options
.DefinesScope());
```
### `DefinesScope`
This registration is used as a logical scope for it's dependencies. Dependencies registered with `InNamedScope()` with the same name are preferred during resolution.
When the `name` is not set, the [service type](/docs/getting-started/glossary#service-type--implementation-type) is used as the name. Dependencies registered with `InScopeDefinedBy()` are selected.
```cs
container.Register(options => options
.DefinesScope("UserRepo"));
// or
container.Register(options => options
.DefinesScope());
```
### `WhenDecoratedServiceIs`
Sets a decorated target condition for the registration.
```cs
container.RegisterDecorator(options => options
.WhenDecoratedServiceIs());
```
### `WhenDecoratedServiceHas`
Sets an attribute condition that the decorated target has to satisfy.
```cs
container.RegisterDecorator(options => options
.WhenDecoratedServiceHas());
```
### `SetImplementationType`
Sets the current registration's [implementation type](/docs/getting-started/glossary#service-type--implementation-type).
```cs
var container = new StashboxContainer(c => c.WithUnknownTypeResolution(config =>
{
if (config.ServiceType == typeof(IService))
config.SetImplementationType(typeof(Service));
}));
```
### `Skip`
Marks the current unknown type registration as skipped.
```cs
var container = new StashboxContainer(c => c.WithUnknownTypeResolution(config =>
{
if (config.ServiceType == typeof(IService))
config.Skip();
}));
```
With the `IsRegistered()` function, you can find out whether a service is registered into the container or not.
It returns `true` only when the container has a registration with the given type (and name). It only checks the actual container's registrations. For every cases, you should use the `CanResolve()` method.
There might be cases when you are more interested in whether a service is resolvable from the container's actual state rather than finding out whether it's registered.
`CanResolve()` returns `true` only when at least one of the following is true:
- The requested type is registered in the current or one of the parent containers.
- The requested type is a closed generic type, and its open generic definition is registered.
- The requested type is a wrapper (`IEnumerable<>`, `Lazy<>`, `Func<>`, `KeyValuePair<,>`, `ReadOnlyKeyValue<,>`, `Metadata<,>`, `ValueTuple<,>`, or `Tuple<,>`), and the underlying type is registered.
- The requested type is not registered, but it's resolvable, and [unknown type resolution](/docs/configuration/container-configuration#unknown-type-resolution) is enabled.
You can get all registrations in a key-value pair collection (where the key is the [service type](/docs/getting-started/glossary#service-type--implementation-type) and the value is the actual registration) by calling the `.GetRegistrationMappings()` method.
```cs
IEnumerable> mappings =
container.GetRegistrationMappings();
```
You can get a much more readable version of the registration mappings by calling the `.GetRegistrationDiagnostics()` method.
`RegistrationDiagnosticsInfo` has an overridden `.ToString()` method that returns the mapping details formatted in a human-readable form.
```cs
container.Register("DbBackupJob");
container.Register(typeof(IEventHandler<>), typeof(EventHandler<>));
IEnumerable diagnostics =
container.GetRegistrationDiagnostics();
diagnostics.ForEach(Console.WriteLine);
// output:
// IJob => DbBackup, name: DbBackupJob
// IEventHandler<> => EventHandler<>, name: null
```
Example where a *Service type* is mapped to an *Implementation type*:
```cs
container.Register();
```
The *Service type* used for requesting a service from the container:
```cs
container.Resolve(); // returns Implementation
```
In this example, we are registering a named service. The container will create a service registration entity to store the type mapping and the name. During resolution, the container will find the registration by checking for the *Service type* and the *name*.
```cs
// the registration entity will look like:
// IService => Implementation, name: Example
container.Register("Example");
var service = container.Resolve("Example");
```
It's a constructor/method argument or a property/field of a registered *Implementation type* that gets evaluated (*injected*) by Stashbox during the service's construction.
In this example, `Implementation` has an `IDependency` *injectable dependency* in its constructor.
```cs
class Implementation : IService
{
public Implementation(IDependency dependency)
{ }
}
```
It's a resolution request for a named service. The same applies, when the container sees a dependency in the resolution tree with a name (set by [attributes](/docs/guides/service-resolution#attributes) or [bindings](/docs/guides/service-resolution#dependency-binding)); it will search for a matching [Named registration](/docs/guides/basics#named-registration) to inject.
```cs
container.Register("Example");
// the named request.
var service = container.Resolve("Example");
```
It's a service registration that's mapped to itself. This means its service and implementation type is the same.
```cs
// equivalent to container.Register();
container.Register();
```
You can bind a factory delegate to a registration that the container will invoke directly to instantiate your service.
You can use parameter-less and custom parameterized delegates as a factory. [Here](/docs/configuration/registration-configuration#factory) is the list of all available options.
You can also get the current [dependency resolver](/docs/getting-started/glossary#dependency-resolver) as a delegate parameter to resolve any additional dependencies required for the service construction.
Delegate factories are useful when your service's instantiation is not straight-forward for the container, like when it depends on something that is not available at resolution time. E.g., a connection string.
```cs
container.Register(options => options
.WithFactory(logger =>
new DbBackup(Configuration["DbConnectionString"], logger));
```
### Factories with parameter overrides
Stashbox can implicitly [wrap](/docs/advanced/wrappers-resolvers#delegate) your service in a `Delegate` and lets you pass parameters that can override your service's dependencies. Moreover, you can register your own custom delegate that the container will resolve when you request your service wrapped in a `Delegate`.
If a service has multiple constructors, the container visits those first, that has matching parameters passed to the factory, with respecting the additional [constructor selection rules](/docs/configuration/registration-configuration#constructor-selection).
```cs
class Service
{
public Service(int number) { }
public Service(string text) { }
}
container.Register();
// create the factory with an int input parameter.
var func = constainer.Resolve>();
// the constructor with the int param
// is used for instantiation.
var service = func(2);
```
### Consider this before using the resolver parameter inside a factory
Delegate factories are a black-box for the container. It doesn't have control over what's happening inside a delegate, which means when you resolve additional dependencies with the [dependency resolver](/docs/getting-started/glossary#dependency-resolver) parameter, they could easily bypass the [lifetime](/docs/diagnostics/validation#lifetime-validation) and [circular dependency](/docs/diagnostics/validation#circular-dependency) validations. Fortunately, you have the option to keep them validated anyway with parameterized factory delegates.
#### Delegates with dependencies passed as parameters
Rather than using the [dependency resolver](/docs/getting-started/glossary#dependency-resolver) parameter inside the factory, let the container inject the dependencies into the delegate as parameters. This way, the [resolution tree's](/docs/getting-started/glossary#resolution-tree) integrity remains stable because no service resolution happens inside the black-box, and each parameter is validated.
```cs
interface IEventProcessor { }
class EventProcessor : IEventProcessor
{
public EventProcessor(ILogger logger, IEventValidator validator)
{ }
}
container.Register();
container.Register();
container.Register(options => options
// Ilogger and IEventValidator instances are injected
// by the container at resolution time, so they will be
// validated against circular and captive dependencies.
.WithFactory((logger, validator) =>
new EventProcessor(logger, validator));
// the container resolves ILogger and IEventValidator first, then
// it passes them to the factory as delegate parameters.
IEventProcessor processor = container.Resolve();
```
### Accessing the currently resolving type in factories
To access the currently resolving type in factory delegates, you can set the `TypeInformation` type as an input parameter of the factory.
The `TypeInformation` holds every reflected context information about the currently resolving type.
This can be useful when the resolution is, e.g., in an open generic context, and we want to know which closed generic variant is requested.
```cs
interface IService { }
class Service : IService { }
container.Register(typeof(IService<>), typeof(Service<>), options =>
options.WithFactory(typeInfo =>
{
// typeInfo.Type here holds the actual type like
// IService based on the resolution request below.
}));
container.Resolve>();
```
As we previously saw in the [Named registration](/docs/guides/basics#named-registration) topic, Stashbox allows you to have multiple implementations bound to a particular [service type](/docs/getting-started/glossary#service-type--implementation-type). You can use names to distinguish them, but you can also access them by requesting a typed collection using the [service type](/docs/getting-started/glossary#service-type--implementation-type).
:::note
The returned collection is in the same order as the services were registered.
Also, to request a collection, you can use any interface implemented by an array.
:::
```cs
container.Register();
container.Register();
container.Register();
```
```cs
// jobs contain all three services in registration order.
IEnumerable jobs = container.ResolveAll();
```
```cs
// jobs contain all three services in registration order.
IJob[] jobs = container.Resolve();
```
```cs
// jobs contain all three services in registration order.
IEnumerable jobs = container.Resolve>();
```
```cs
// jobs contain all three services in registration order.
IList jobs = container.Resolve>();
```
```cs
// jobs contain all three services in registration order.
ICollection jobs = container.Resolve>();
```
When you have multiple implementations registered to a service, a request to the [service type](/docs/getting-started/glossary#service-type--implementation-type) without a name will return the **last registered implementation**.
:::info
Not only names can be used to distinguish registrations, [conditions](/docs/guides/service-resolution#conditional-resolution), [named scopes](/docs/guides/scopes#named-scopes), and [metadata](/docs/advanced/wrappers-resolvers#metadata--tuple) can also influence the results.
:::
```cs
container.Register();
container.Register();
container.Register();
// job will be the ImageProcess.
IJob job = container.Resolve();
```
When you have a service that implements multiple interfaces, you have the option to bind its registration to all or some of those additional interfaces or base types.
Suppose we have the following class declaration:
```cs
class DbBackup : IJob, IScheduledJob
{
public DbBackup() { }
}
```
You have the option to register multiple services in a single registration operation.
**Filters (optional):**
First, the container will use the *implementation filter* action to select only those types from the collection we want to register. When we have those, the container will execute the *service filter* on their implemented interfaces and base classes to select which [service type](/docs/getting-started/glossary#service-type--implementation-type) they should be mapped to.
:::note
Framework types like `IDisposable` are excluded from being considered as a [service type](/docs/getting-started/glossary#service-type--implementation-type) by default.
:::
:::tip
You can use the registration configuration API to configure individual registrations.
:::
Another type of service filter is the `.RegisterTypesAs()` method, which registers only those types that implements the `T` [service type](/docs/getting-started/glossary#service-type--implementation-type).
:::note
This method also accepts an implementation filter and a registration configurator action like `.RegisterTypes()`.
:::
:::caution
`.RegisterTypesAs()` doesn't create [self registrations](/docs/getting-started/glossary#self-registration) as it only maps the implementations to the given `T` [service type](/docs/getting-started/glossary#service-type--implementation-type).
:::
The batch registration API *(filters, registration configuration action, self-registration)* is also usable for registering services from given assemblies.
In this example, we assume that the same three services we used in the [batch registration](#batch-registration) section are in the same assembly.
:::info
The container also detects and registers open-generic definitions (when applicable) from the supplied type collection. You can read about [open-generics here](/docs/advanced/generics#open-generics).
:::
The [Composition Root](https://blog.ploeh.dk/2011/07/28/CompositionRoot/) is an entry point where all services required to make a component functional are wired together.
Stashbox provides an `ICompositionRoot` interface that can be used to define an entry point for a given component or even for an entire assembly.
You can wire up your *composition root* implementation with `ComposeBy()`, or you can let the container find and execute all available *composition root* implementations within an assembly.
:::note
Your `ICompositionRoot` implementation also can have dependencies that the container will resolve.
:::
```cs
class ExampleRoot : ICompositionRoot
{
public ExampleRoot(IDependency rootDependency)
{ }
public void Compose(IStashboxContainer container)
{
container.Register();
container.Register();
}
}
```
```cs
// compose a single root.
container.ComposeBy();
```
```cs
// compose every root in the given assembly.
container.ComposeAssembly(typeof(IServiceA).Assembly);
```
```cs
// compose a single root with dependency override.
container.ComposeBy(new CustomRootDependency());
```
If you have pre-evaluated dependencies you'd like to inject at resolution time, you can set them as injection parameters during registration.
:::note
Injection parameter names are matched to constructor arguments or field/property names.
:::
```cs
container.Register(options => options
.WithInjectionParameter("logger", new ConsoleLogger())
.WithInjectionParameter("eventBroadcaster", new MessageBus());
// the injection parameters will be passed to DbBackup's constructor.
IJob backup = container.Resolve();
```
The container provides specific extension points to let you react to lifetime events of an instantiated service.
For this reason, you can specify *Initializer* and *Finalizer* delegates. The *finalizer* is called upon the service's [disposal](/docs/guides/scopes#disposal), and the *initializer* is called upon the service's construction.
```cs
container.Register(options => options
// delegate that called right after instantiation.
.WithInitializer((logger, resolver) => logger.OpenFile())
// delegate that called right before the instance's disposal.
.WithFinalizer(logger => logger.CloseFile()));
```
Stashbox allows registration operations via the `Register()` methods.
During registration, the container checks whether the [service type](/docs/getting-started/glossary#service-type--implementation-type) is assignable from the [implementation type](/docs/getting-started/glossary#service-type--implementation-type) and if not, the container throws an [exception](/docs/diagnostics/validation#registration-validation).
Also, when the implementation is not resolvable, the container throws the same [exception](/docs/diagnostics/validation#registration-validation).
The example registers `DbBackup` to be returned when `IJob` is requested.
You can register a service to itself without specifying a [service type](/docs/getting-started/glossary#service-type--implementation-type), only the implementation ([self registration](/docs/getting-started/glossary#self-registration)).
In this case, the given implementation is considered the [service type](/docs/getting-started/glossary#service-type--implementation-type) and must be used to request the service (`DbBackup` in the example).
The container's API is fluent, which means you can chain the calls on its methods after each other.
```cs
var job = container.Register()
.Register()
.Resolve();
```
The example shows how you can bind more implementations to a [service type](/docs/getting-started/glossary#service-type--implementation-type) using names for identification.
The same name must be used to resolve the named service.
:::note
The name is an `object` type.
:::
You can also get each service that share the same name by requesting an `IEnumerable<>` or using the `ResolveAll()` method with the `name` parameter.
```cs
container.Register("StorageJobs");
container.Register("StorageJobs");
container.Register();
// jobs will be [DbBackup, StorageCleanup].
IEnumerable jobs = container.Resolve>("StorageJobs");
```
With instance registration, you can provide an already created external instance to use when the given [service type](/docs/getting-started/glossary#service-type--implementation-type) is requested.
Stashbox automatically handles the [disposal](/docs/guides/scopes#disposal) of the registered instances, but you can turn this feature off with the `withoutDisposalTracking` parameter.
When an `IJob` is requested, the container will always return the external instance.
The instance registration API allows the batched registration of different instances.
```cs
container.RegisterInstances(new DbBackup(), new StorageCleanup());
IEnumerable jobs = container.ResolveAll();
```
With re-map, you can bind new implementations to a [service type](/docs/getting-started/glossary#service-type--implementation-type) and delete old registrations in one action.
:::caution
When there are multiple registrations mapped to a [service type](/docs/getting-started/glossary#service-type--implementation-type), `.ReMap()` will replace all of them with the given [implementation type](/docs/getting-started/glossary#service-type--implementation-type). If you want to replace only one specific service, use the `.ReplaceExisting()` [configuration option](/docs/configuration/registration-configuration#replace).
:::
Wiring up is similar to [Instance registration](#instance-registration) except that the container will perform property/field injection (if configured so and applicable) on the registered instance during resolution.
A service's lifetime indicates how long its instance will live and which re-using policy should be applied when it gets injected.
This example shows how you can use the registration API's shortcuts for lifetimes. These are just sugars, and there are more ways explained in the [lifetimes](/docs/guides/lifetimes) section.
:::info
The `DefaultLifetime` is [configurable](/docs/guides/lifetimes#default-lifetime).
:::
When you are not specifying a lifetime during registration, Stashbox will use the default lifetime. By default, it's set to [Transient](#transient-lifetime), but you can override it with the `.WithDefaultLifetime()` [container configuration option](/docs/configuration/container-configuration#default-lifetime).
You can choose either from the pre-defined lifetimes defined on the `Lifetimes` static class or use a [custom lifetime](#custom-lifetime).
A new instance is created for each resolution request. If a transient is referred by multiple consumers in the same [resolution tree](/docs/getting-started/glossary#resolution-tree), each will get a new instance.
```cs
container.Register(options => options
.WithLifetime(Lifetimes.Transient));
```
A single instance is created and reused for each resolution request and injected into each consumer.
:::note
Singleton services are disposed when the container ([root scope](/docs/getting-started/glossary#root-scope)) is being disposed.
:::
A new instance is created for each [scope](/docs/guides/scopes), which will be returned for every resolution request initiated on the given scope. It's like a singleton lifetime within a scope.
:::note
Scoped services are disposed when their scope is being disposed.
:::
It is the same as scoped lifetime, except the given service will be selected only when a scope with the same name initiates the resolution request.
You can also let a service [define](/docs/guides/scopes#service-as-scope) its own named scope. During registration, this scope can be referred to by its name upon using a named scope lifetime.
The requested service will be reused within the whole resolution request. A new instance is created for each individual request .
```cs
container.Register(options => options
.WithPerRequestLifetime());
```
The requested service's lifetime will align to the lifetime of its dependencies. When the requested service has a dependency with a higher lifespan, this lifetime will inherit that lifespan up to a given boundary.
```cs
container.Register(options => options
.WithAutoLifetime(Lifetimes.Scoped /* boundary lifetime */));
```
If the requested service has auto lifetime with a scoped boundary and it has only transient dependencies, it'll inherit their transient lifetime.
```cs
container.Register();
container.Register(options => options
.WithAutoLifetime(Lifetimes.Scoped /* boundary lifetime */));
// job has transient lifetime.
var job = container.Resolve();
```
When there's a dependency with higher lifespan than the given boundary, the requested service will get the boundary lifetime.
```cs
container.RegisterSingleton();
container.Register(options => options
.WithAutoLifetime(Lifetimes.Scoped /* boundary lifetime */));
// job has scoped lifetime.
var job = container.Resolve();
```
You can create a scope from the container by calling its `.BeginScope()` method.
Scopes can be **nested**, which means you can create sub-scopes from existing ones with their `.BeginScope()` method.
Scoped service instances are not shared across parent and sub-scope relations.
Nested scopes can be **attached to their parent's lifetime**, which means when a parent gets disposed all child scopes attached to it will be disposed.
Scopes are `IDisposable`; they track all `IDisposable` instances they resolved. Calling their `Dispose()` method or wrapping them in `using` statements is a crucial part of their service's lifetime management.
There might be cases where you don't want to use a service globally across every scope, only in specific ones.
For this reason, you can differentiate specific scope groups from other scopes with a **name**.
You can set a service's lifetime to [named scope lifetime](/docs/guides/lifetimes#named-scope-lifetime) initialized with the **scope's name** to mark it usable only for that named scope.
```cs
container.Register(options =>
options.InNamedScope("DbScope"));
container.Register(options =>
options.InNamedScope("DbScope"));
container.Register(options =>
options.InNamedScope("DbSubScope"));
container.Register(options =>
options.InNamedScope("StorageScope"));
```
:::note
Services with named scope lifetime are **shared across parent and sub-scope relations**.
:::
If you request a name-scoped service from an un-named scope, you'll get an error or no result (depending on the configuration) because those services are selectable only by named scopes with a matching name.
```cs
using (var dbScope = container.BeginScope("DbScope"))
{
// DbBackup and DbCleanup will be returned.
IEnumerable jobs = dbScope.ResolveAll();
// create a sub-scope of dbScope.
using var sub = dbScope.BeginScope();
// DbBackup and DbCleanup will be returned from the named parent scope.
IEnumerable jobs = sub.ResolveAll();
// create a named sub-scope.
using var namedSub = dbScope.BeginScope("DbSubScope");
// DbIndexRebuild will be returned from the named sub-scope.
IEnumerable jobs = namedSub.ResolveAll();
}
using (var storageScope = container.BeginScope("StorageScope"))
{
// StorageCleanup will be returned.
IJob job = storageScope.Resolve();
}
// create a common scope without a name.
using (var unNamed = container.BeginScope())
{
// empty result as there's no service registered without named scope.
IEnumerable jobs = unNamed.ResolveAll();
// throws an exception because there's no unnamed service registered.
IJob job = unNamed.Resolve();
}
```
You can configure a service to behave like a nested named scope. At the resolution of this kind of service, a new dedicated named scope is created implicitly for managing the service's dependencies.
With this feature, you can organize your dependencies around logical groups (named scopes) instead of individual services.
Using `InScopeDefinedBy()`, you can bind services to a defined scope without giving it a name. In this case, the defining service's [implementation type](/docs/getting-started/glossary#service-type--implementation-type) is used for naming the scope.
:::note
The lifetime of the defined scope is attached to the current scope that was used to create the service.
:::
You can add an already instantiated service to a scope. The instance's lifetime will be tracked by the given scope.
```cs
using var scope = container.BeginScope();
scope.PutInstanceInScope(new DbBackup());
```
You can disable the tracking by passing `true` for the `withoutDisposalTracking` parameter. In this case, only the strong reference to the instance is dropped when the scope is disposed.
```cs
using var scope = container.BeginScope();
scope.PutInstanceInScope(new DbBackup(), withoutDisposalTracking: true);
```
You can also give your instance a name to use it like a [named registration](/docs/guides/basics#named-registration):
```cs
using var scope = container.BeginScope();
scope.PutInstanceInScope(new DbBackup(), false, name: "DbBackup");
```
The currently resolving scope tracks services that implement either `IDisposable` or `IAsyncDisposable`. This means that when the scope is disposed, all the tracked disposable instances will be disposed with it.
:::note
Disposing the container will dispose all the singleton instances and their dependencies.
:::
You can disable the disposal tracking on a [service registration](/docs/getting-started/glossary#service-registration--registered-service) with the `.WithoutDisposalTracking()` option.
```cs
container.Register(options =>
options.WithoutDisposalTracking());
```
### Async disposal
As the container and its scopes implement the `IAsyncDisposable` interface, you can dispose them asynchronously when they are used in an `async` context.
Calling `DisposeAsync` disposes both `IDisposable` and `IAsyncDisposable` instances; however, calling `Dispose` only disposes `IDisposable` instances.
### Finalizer delegate
During [service registration](/docs/getting-started/glossary#service-registration--registered-service), you can set a custom finalizer delegate that will be invoked at the service's disposal.
```cs
container.Register(options =>
options.WithFinalizer(backup =>
backup.CloseDbConnection()));
```
**Constructor injection** is the *primary dependency injection pattern*. It encourages the organization of dependencies to a single place - the constructor.
Stashbox, by default, uses the constructor that has the most parameters it knows how to resolve. This behavior is configurable through [constructor selection](/docs/configuration/registration-configuration#constructor-selection).
[Property/field injection](/docs/configuration/registration-configuration#property-field-injection) is also supported in cases where constructor injection is not applicable.
Members defined with C# 11's [`required`](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/required) keyword are automatically injected by the container.
This behavior can be controlled with [registration](/docs/configuration/registration-configuration#required-member-injection) or [container](/docs/configuration/container-configuration#required-member-injection) configuration options
:::info
[Constructor selection](/docs/configuration/container-configuration#constructor-selection) and [property/field injection](/docs/configuration/container-configuration#auto-member-injection) is also configurable container-wide.
:::
Attributes can give you control over how Stashbox selects dependencies for a service's resolution.
**Dependency attribute**:
- **On a constructor/method parameter**: used with the *name* property, it works as a marker for [named resolution](/docs/getting-started/glossary#named-resolution).
- **On a property/field**: first, it enables *auto-injection* on the marked property/field (even if it wasn't configured at registration explicitly), and just as with the method parameter, it allows [named resolution](/docs/getting-started/glossary#named-resolution).
**DependencyName attribute**: a parameter marked with this attribute will get the related service's dependency name.
**InjectionMethod attribute**: marks a method to be called when the requested service is instantiated.
There's an option to extend the container's dependency finding mechanism with your own attributes.
- **Additional Dependency attributes**: you can use the [`.WithAdditionalDependencyAttribute()`](/docs/configuration/container-configuration#withadditionaldependencyattribute) container configuration option to let the container know that it should watch for additional attributes besides the built-in [`Dependency`](/docs/guides/service-resolution#attributes) attribute upon building up the [resolution tree](/docs/getting-started/glossary#resolution-tree).
- **Additional DependencyName attributes**: you can use the [`.WithAdditionalDependencyNameAttribute()`](/docs/configuration/container-configuration#withadditionaldependencynameattribute) container configuration option to use additional dependency name indicator attributes besides the built-in [`DependencyName`](/docs/guides/service-resolution#attributes) attribute.
The same dependency configuration functionality as attributes, but without attributes.
- **Binding to a parameter**: the same functionality as the [`Dependency`](/docs/guides/service-resolution#attributes) attribute on a constructor or method parameter, enabling [named resolution](/docs/getting-started/glossary#named-resolution).
- **Binding to a property/field**: the same functionality as the [`Dependency`](/docs/guides/service-resolution#attributes) attribute, enabling the injection of the given property/field.
:::info
There are further dependency binding options [available](/docs/configuration/registration-configuration#dependency-configuration) on the registration configuration API.
:::
When you enable conventional resolution, the container treats member and method parameter names as their dependency identifier.
It's like an implicit dependency binding on every class member.
First, you have to enable conventional resolution through the configuration of the container:
```cs
new StashboxContainer(options => options
.TreatParameterAndMemberNameAsDependencyName());
```
:::note
The container will attempt a [named resolution](/docs/getting-started/glossary#named-resolution) on each dependency based on their parameter or property/field name.
:::
Stashbox can resolve a particular dependency based on its context. This context is typically the reflected type of dependency, its usage, and the type it gets injected into.
- **Attribute**: you can filter on constructor, method, property, or field attributes to select the desired dependency for your service. In contrast to the `Dependency` attribute, this configuration doesn't tie your application to Stashbox because you use your own attributes.
- **Parent type**: you can filter on what type the given service is injected into.
- **Resolution path**: similar to the parent type and attribute condition but extended with inheritance. You can set that the given service is only usable in a type's resolution path. This means that each direct and sub-dependency of the selected type must use the provided service as a dependency.
- **Custom**: with this, you can build your own selection logic based on the given contextual type information.
In cases where it's not guaranteed that a service is resolvable, either because it's not registered or any of its dependencies are missing, you can attempt an optional resolution using the `ResolveOrDefault()` method.
When the resolution attempt fails, it will return `null` (or `default` in case of value types).
At resolution time, you can override a service's dependencies by passing an `object[]` to the `Resolve()` method.
```cs
class DbBackup : IJob
{
public DbBackup(ILogger logger)
{ }
}
```
To get more control over your overrides (like giving them name to allow [named resolution](/docs/getting-started/glossary#named-resolution)), you can use the `Override` built-in wrapper.
```cs
class DbBackup : IJob
{
public DbBackup([Dependency("console")]ILogger logger)
{ }
}
```
You can use the container's `.Activate()` method when you only want to build up an instance from a type on the fly without registration.
It allows dependency overriding with `object` arguments and performs property/field/method injection (when configured).
It works like `Activator.CreateInstance()` except that Stashbox supplies the dependencies.
### Build-up
With the `.BuildUp()` method, you can do the same *on the fly* post-processing (property/field/method injection) on already constructed instances.
:::caution
`.BuildUp()` won't register the given instance into the container.
:::
```cs
class DbBackup : IJob
{
public ILogger Logger { get; set; }
}
DbBackup backup = new DbBackup();
// the container fills the Logger property.
container.BuildUp(backup);
```
', }, { type: 'html', className: 'navbar-title', value: 'ASP.NET', }, { href: 'https://github.com/z4kn4fein/stashbox-extensions/tree/main/src/stashbox-web-webapi', label: 'Web API', }, { href: 'https://github.com/z4kn4fein/stashbox-extensions/tree/main/src/stashbox-web-mvc', label: 'MVC', }, { href: 'https://github.com/z4kn4fein/stashbox-extensions/tree/main/src/stashbox-signalr', label: 'SignalR', }, { type: 'html', value: '
', }, { type: 'html', className: 'navbar-title', value: 'OWIN', }, { href: 'https://github.com/z4kn4fein/stashbox-extensions/tree/main/src/stashbox-owin', label: 'OWIN', }, { href: 'https://github.com/z4kn4fein/stashbox-extensions/tree/main/src/stashbox-webapi-owin', label: 'Web API', }, { href: 'https://github.com/z4kn4fein/stashbox-extensions/tree/main/src/stashbox-signalr-owin', label: 'SignalR', }, { type: 'html', value: '
', }, { type: 'html', className: 'navbar-title', value: 'Other', }, { href: 'https://github.com/z4kn4fein/stashbox-extensions/tree/main/src/stashbox-hangfire', label: 'Hangfire', }, { href: 'https://github.com/z4kn4fein/stashbox-mocking', label: 'Mocking', }, ] }, { type: 'dropdown', position: 'left', label: 'Benchmarks', items: [ { href: 'https://danielpalme.github.io/IocPerformance', label: 'Performance', }, ] }, { position: 'left', label: 'Changelog', href: 'https://github.com/z4kn4fein/stashbox/releases' }, { type: 'custom-icon', icon: 'nuget', position: 'right', className: 'nav-icon', href: 'https://www.nuget.org/packages/Stashbox' }, { type: 'custom-icon', icon: 'github', position: 'right', className: 'nav-icon', href: 'https://github.com/z4kn4fein/stashbox' }, { type: 'custom-separator', position: 'right', }, ], }, footer: { style: 'dark', links: [ { title: 'GUIDES', items: [ { label: 'Basic usage', to: 'docs/guides/basics' }, { label: 'Advanced registration', to: 'docs/guides/advanced-registration' }, { label: 'Service resolution', to: 'docs/guides/service-resolution' }, { label: 'Lifetimes', to: 'docs/guides/lifetimes' }, { label: 'Scopes', to: 'docs/guides/scopes' }, ], }, { title: 'ADVANCED', items: [ { label: 'Generics', to: 'docs/advanced/generics' }, { label: 'Decorators', to: 'docs/advanced/decorators' }, { label: 'Wrappers & resolvers', to: 'docs/advanced/wrappers-resolvers' }, { label: 'Child containers', to: 'docs/advanced/child-containers' }, { label: 'Special resolution cases', to: 'docs/advanced/special-resolution-cases' }, ], } ], copyright: `Copyright © ${new Date().getFullYear()} Peter Csajtai. Built with Docusaurus.`, }, docs: { sidebar: { hideable: true, }, }, prism: { theme: prismLightTheme, additionalLanguages: [ 'csharp', 'powershell', 'bash', ], }, colorMode: { defaultMode: 'light', disableSwitch: false, respectPrefersColorScheme: true, }, algolia: { appId: 'CYYLE77D6F', apiKey: '70fdb3ec7ec00e65922f35e5a5e35562', indexName: 'stashbox' }, }), }; async function createConfig() { const darkTheme = (await import('./src/utils/prismDark.mjs')).default; // @ts-expect-error: it exists config.themeConfig.prism.darkTheme = darkTheme; return config; } module.exports = createConfig; ================================================ FILE: docs/package.json ================================================ { "name": "website", "version": "0.0.0", "private": true, "scripts": { "docusaurus": "docusaurus", "start": "docusaurus start", "build": "docusaurus build", "swizzle": "docusaurus swizzle", "deploy": "docusaurus deploy", "clear": "docusaurus clear", "serve": "docusaurus serve", "write-translations": "docusaurus write-translations", "write-heading-ids": "docusaurus write-heading-ids" }, "dependencies": { "@docusaurus/core": "3.9.2", "@docusaurus/preset-classic": "3.9.2", "@mdx-js/react": "^3.0.0", "clsx": "^2.0.0", "docusaurus-plugin-sass": "^0.2.6", "prism-react-renderer": "^2.1.0", "react": "^18.2.0", "react-dom": "^18.2.0", "sass": "^1.69.5" }, "devDependencies": { "@docusaurus/module-type-aliases": "3.0.0" }, "browserslist": { "production": [ ">0.5%", "not dead", "not op_mini all" ], "development": [ "last 1 chrome version", "last 1 firefox version", "last 1 safari version" ] }, "engines": { "node": ">=20.0" } } ================================================ FILE: docs/sidebars.js ================================================ /** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */ const sidebars = { docs: [ { type: 'category', label: 'Get started', collapsed: false, items: [ 'getting-started/overview', 'getting-started/introduction', 'getting-started/glossary', ], }, { type: 'category', label: 'Guides', collapsed: false, items: [ 'guides/basics', 'guides/advanced-registration', 'guides/service-resolution', 'guides/lifetimes', 'guides/scopes', ], }, { type: 'category', label: 'Configuration', collapsed: false, items: [ 'configuration/registration-configuration', 'configuration/container-configuration', ], }, { type: 'category', label: 'Advanced', collapsed: false, items: [ 'advanced/generics', 'advanced/decorators', 'advanced/wrappers-resolvers', 'advanced/child-containers', 'advanced/special-resolution-cases', ], }, { type: 'category', label: 'Diagnostics', collapsed: false, items: [ 'diagnostics/validation', 'diagnostics/utilities', ], }, ] }; module.exports = sidebars; ================================================ FILE: docs/src/components/CodeDescPanel/index.tsx ================================================ import React from 'react'; import styles from './styles.module.scss'; export default function CodeDescPanel({children}) { let notNullChildren = React.Children.toArray(children).filter(c => c); return (
{notNullChildren[0]}
{notNullChildren[1]}
}){kind=icon}
{siteConfig.title}
{siteConfig.tagline}
🚀 Thread-safe and lock-free.
⚡️️ Easy-to-use Fluent API.
♻️ Small memory footprint.
⚡️️ Easy-to-use Fluent API.
♻️ Small memory footprint.
{'$'} dotnet add package Stashbox --version 5.20.0
Get Started
GitHub
NuGet