2. To provide parameters which are not available at resolution time:

```csharp
using System;
using StrongInject;

public class Server
{
private Handler _frobbingHandler;
private Handler _nonFrobbingHandler;
public Server(Func handlerFunc) => (_frobbingHandler, _nonFrobbingHandler) = (handlerFunc(true), handlerFunc(false));

public bool HandleRequest(Request request, bool shouldFrob) => shouldFrob ? _frobbingHandler.HandleRequest(request) : _nonFrobbingHandler.HandleRequest(request);
}

public class Handler
{
public Handler(bool shouldFrob) => ...
}

[Register(typeof(Server))]
[Register(typeof(Handler))]
public class Container : IContainer {}
```

If the return type can only be resolved asynchronously (see [below](#async-support)), the delegate must return `Task` or `ValueTask`. e.g.

```csharp
using System;
using StrongInject;
using System.Threading.Tasks;

public class Server
{
private Func> _handlerFunc;
public Server(Func> handlerFunc) => _handlerFunc = handlerFunc;

public async Task HandleRequest(Request request, bool shouldFrob) => (await _handlerFunc(shouldFrob)).HandleRequest(request);
}

public class Handler : IRequiresAsyncInitialization
{
public Handler(bool shouldFrob) => ...
public async ValueTask InitializeAsync() => ...
}

[Register(typeof(Server))]
[Register(typeof(Handler))]
public class Container : IContainer {}
```

### `Owned` support

Using `Owned` instead of `T` gives a component the control over when the `T` instance and all its dependencies are released back to the container. You access the `T` instance using the `Owned.Value` property, and you dispose the `Owned` instance to release the `T` instance and its dependencies back to the container. It’s your responsibility to call `Owned.Dispose()` when you’re ready. If you don’t, the `T` instance and all its dependencies will never be cleaned up, not even when the container itself is disposed.

`Owned` offers a clean alternative to disposing the `T` instance directly. Disposing `T` directly can lead to leaks where the dependencies of the `T` instance itself are not disposed or released back to the container soon enough. Advanced situations like pooling also require `Owned` to release the `T` back to the pool without disposing it.

Injecting `Owned` or delegates returning `Owned` is enabled out of the box, and so are the `AsyncOwned` versions of these. `AsyncOwned` will be required to be used instead of `Owned` when the `T` in question or any of its dependencies require asynchronous disposal.

The typical scenario is when you combine this with delegates by injecting `Func>` or `Func>` into a component. This enables the component to acquire and release `Y` instances as many times as it needs, possibly with varying parameters, and possibly overlapping with each other before releasing them back to the container. Here’s one such usage:

```csharp
using Microsoft.Data.SqlClient;
using Microsoft.EntityFrameworkCore;
using StrongInject;
using System;
using System.Threading.Tasks;

[Register(typeof(SomeViewModel))]
[Register(typeof(SomeDbContext))]
public partial class Container : IContainer
{
[Factory]
public static SqlConnection CreateSqlConnection()
{
throw new NotImplementedException();
}
}

public class SomeViewModel
{
private readonly Func> dbContextFactory;

public SomeViewModel(Func> dbContextFactory)
{
this.dbContextFactory = dbContextFactory;
}

public async Task SaveAsync(string newName)
{
// Using Func> instead of Func ensures that the context will not be
// disposed while this method is still using it, even if SomeViewModel is released back to the container.

// Using Func> instead of Owned gives the ability for SaveAsync to
// get a new SomeDbContext instance that is not being used anywhere else, so overlapping calls to SaveAsync
// are no problem.

using Owned dbContext = dbContextFactory.Invoke();

dbContext.Value.Set().Add(new SomeEntity { Name = newName });
await dbContext.Value.SaveChangesAsync();
}
}

public class SomeDbContext : DbContext
{
public SomeDbContext(SqlConnection connection)
: base(new DbContextOptionsBuilder().UseSqlServer(connection).Options)
{
}
}

public class SomeEntity
{
public string Name { get; set; }
}
```

### Post Constructor Initialization

If your type implements `IRequiresInitialization`, `Initialize` will be called after construction.
Whilst this is only useful in a few edge cases for synchronous methods, `IRequiresAsyncInitialization` is extremely useful as constructors cannot be async. Therefore I'll leave an example of using this API for the section on async support.

### Async Support

Every interface used by StrongInject has an asynchronous counterpart.
There's `IAsyncContainer`, `IAsyncFactory` and `IRequiresAsyncInitialization`.

You can resolve an instance of `T` asynchronously from an `IAsyncContainer` by calling `StrongInject.AsyncContainerExtensions.RunAsync`. RunAsync has overloads allowing you to pass in sync or async lambdas. As such `IAsyncContainer` is useful even if resolution is completely synchronous if usage is asynchronous.

It is an error resolving `T` in an `IContainer` if it depends on an asynchronous dependency.

A type can implement both `IContainer` and `IAsyncContainer`. They will share single instance dependencies.

Here is a full fledged example where data will be loaded from the database as part of resolution using `IRequiresAsyncInitialization`:

```csharp
using StrongInject;
using System;
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;

public interface IDb
{
Task> GetUserPasswordsAsync();
}

public class PasswordChecker : IRequiresAsyncInitialization, IAsyncDisposable
{
private readonly IDb _db;

private Dictionary _userPasswords;

private Timer _timer;

public PasswordChecker(IDb db)
{
_db = db;
}

public async ValueTask InitializeAsync()
{
_userPasswords = await _db.GetUserPasswordsAsync();
_timer = new Timer(async _ => { _userPasswords = await _db.GetUserPasswordsAsync(); }, null, 60000, 60000);
}

public bool CheckPassword(string user, string password) => _userPasswords.TryGetValue(user, out var correctPassword) && password == correctPassword;

public ValueTask DisposeAsync()
{
return _timer.DisposeAsync();
}
}

[Register(typeof(PasswordChecker), Scope.SingleInstance)]
public partial class Container : IAsyncContainer
{
private readonly IDb _db;

public Container(IDb db)
{
_db = db;
}

[Factory]
IDb GetDb() => _db;
}

public static class Program
{
public static async Task Main(string[] args)
{
await new Container(new Db()).RunAsync(x =>
Console.WriteLine(x.CheckPassword(args[0], args[1])
? "Password is valid"
: "Password is invalid"));
}
}
```

#### Parallel Resolution

StrongInject makes the assumption that async dependencies will usually be doing IO. In order to increase performance it kicks off all async tasks in parallel as early as it can, and only awaits them once it's completed resolving all dependencies that don't require them. For example, if most of your components call the database as part of resolution, they will all do so in parallel rather than one after the other.

This improves async resolution time hugely - instead of resolution time being the sum of the time to resolve all components, it's the the amount of time it takes to resolve the longest chain of dependent components, no matter how many other components there are.

What this means is that components used as part of async resolution should be thread safe. If they are not, mark them as `InstancePerDependency`, which will ensure that they are only ever used by one thread of resolution at a time.

### Resolving all instances of a type

When resolving an array type, if there are no user provided registrations for the array type, the array will be created by resolving all registrations (including generic registrations) for the element type, and filling the array with these instances.

For example:

```csharp
public class A : IInterface {}
public class B : IInterface {}
public interface IInterface {}

[Register(typeof(A), typeof(IInterface))]
[Register(typeof(B), typeof(IInterface))]
public class Container : IContainer
```

This will resolve an array containing an instance of type `A` and an instance of type `B`.

The contents of the array are arbitrary but deterministic. A new array is created for every dependency, so users are free to mutate it.

Note that duplicate registrations will be deduplicated, so in the following case:

```csharp
public class A : IInterface {}
public interface IInterface {}

[Register(typeof(A), typeof(IInterface))]
[Register(typeof(A), typeof(IInterface))]
public class Container : IContainer
```

The array will contain 1 item, but in this case:

```csharp
public class A : IInterface {}
public interface IInterface {}

[Register(typeof(A), typeof(IInterface))]
[Register(typeof(A), Scope.SingleInstance, typeof(IInterface))]
public class Container : IContainer
```

It will contain 2 items.

### Optional Parameters

If a parameter to a type or method is optional, StrongInject will not error if it cannot be resolved, and will instead just use the default value.

An example of where this can be useful is for providing a default instance of an interface if none is registered:

```csharp
public class DefaultImplementation : IInterface {}
public interface IInterface {}

[Register(typeof(DefaultImplementation))]
public class Module
{
[Decorator] GetIInterface(IInterface? impl = null, DefaultImplementation defaultImpl) => impl ?? defaultImpl;
}
```

### Disposal

Once a call to `Run` or `RunAsync` is complete, any Instance Per Resolution or Instance Per Dependency instances created as part of the call to `Run` or `RunAsync` will be disposed.

Similarly when an `Owned` is disposed, any Instance Per Resolution or Instance Per Dependency instances created as part of resolving `T` will be disposed.

In `RunAsync`/`ResolveAsync` if the types implement `IAsyncDisposable` it will be preferred over `IDisposable`. `Dispose` and `DisposeAsync` will not both be called, just `DisposeAsync`.
In `Run`/`Resolve`, `IAsyncDisposable` will be ignored. Only `Dispose` will ever be called.

Since `IFactory` is free to create a new instance every time or return a singleton, StrongInject cannot call dispose directly. Instead it calls `IFactory.Release(T instance)`. The factory is then free to dispose the class or not. When referencing the .NET Standard 2.1 package `Release` has a default implementation which does nothing. You only need to implement it if you want custom behaviour. If you reference the .NET Standard 2.0 package you will need to implement it either way.

Single Instance dependencies and their dependencies are disposed when the container is disposed. If the container implements `IAsyncDisposable` it must be disposed asynchronously even if it also implements `IDisposable`.

Note that dependencies may not be disposed in the following circumstances:
1. Resolution of a SingleInstance dependency throws.
2. Disposal of other dependencies throws.

When either of these happen it is most likely best to restart the application anyway, as a safe recovery is very unlikely.

### Thread Safety

StrongInject provides the following thread safety guarantees:
1. Resolution is thread safe, so long as it doesn't call back into the container recursively (e.g. a factory calling `container.RunAsync`).
2. If the container is disposed during resolution, then either dependencies will be created by the resolution, and will then be disposed, or resolution will throw and no dependencies will be created. Dependencies will not be created and then not disposed.
3. A SingleInstance dependency will never be created more than once.

### Inbuilt Modules

StrongInject provides a number of inbuilt modules which can be used 'out of the box' in the `StrongInject.Modules` namespace for the most commonly required functionality. You still need to import these modules via `RegisterModule`, although you can get all of the less opinionated modules in one go by importing the `StandardModule`.

At the moment the following modules are provided:

1. `LazyModule` (registers `Lazy`)
1. `CollectionsModule` (registers `IEnumerable`, `IReadOnlyList` and `IReadOnlyCollection`)
1. `ValueTupleModule` (registers all tuples from sizes 2 till 10)
1. `SafeImmutableArrayModule` (registers `ImmutableArray`)
1. `UnsafeImmutableArrayModule` (provides a faster non-copying registration for `ImmutableArray` which cannot be used if a custom registration for `T[]` exists)

At the moment the `StandardModule` imports `lazyModule`, `CollectionsModule` and `ValueTuple` module.

If you would like more modules/registrations added please open an issue.

## Product Roadmap

https://github.com/YairHalberstadt/stronginject/projects/1

## Contributing

Please do open issues if you spot any bugs, or would like to suggest new features/API changes.

Please feel free to work on any open issue and open a PR. Ideally open an issue before working on something, so that the effort doesn't go to waste if it's not suitable.

Note that I will tend to be very available if you need any help whilst contributing - see next section about how to contact me.

## Need Help?

I tend to hang around on Gitter so feel free to chat at https://gitter.im/stronginject/community.