...

/*await/* using(var scope1 = cluster.CreateCustomScope())
{
var a1 = cluster.Get(scope1);

/*await/* using(var scope2 = cluster.CreateCustomScope())
{
var a2 = cluster.Get(scope2);
} //here we dispose a2 if target for IA is IDisposable /*or IAsyncDisposable*/
} //here we dispose a1 if target for IA is IDisposable /*or IAsyncDisposable*/
```

`IDisposable` custom-binded objects will be disposed at the moment of the scope object dispose. DO NOT forget to invoke `Dispose` on scope object! Otherwise, Custom-scoped disposable objects will not be disposed too.

If you have at least one custom scoped binding with `IAsyncDisposable` interface, but without `IDisposable` interface, you need to invoke `DisposeAsync` instead of `Dispose` at the scope object. The rule is simple: `Dispose` scope object -> `Dispose` its bindings, `AsyncDispose` scope object -> `Dispose` + `DisposeAsync` its bindings. So, I recommend always use `DisposeAsync` for a scope objects. **Disposing order is undefined.**

Keep in mind, custom-scoped bindings are resolved much slower than singleton/transient/constant bindings.

## Conditional binding

Each bind clause may have an additional filter e.g.

Please refer unit tests to see the examples. Please note, than any filter makes a resolution process slower (a much slower! 10x slower in compare of unconditional binding!), so use this feature responsibly. Resolution slowdown with conditional bindings has an effect even on those bindings that do not have conditions, but they directly or indirectly takes conditional binding as its dependency. Therefore, it is advisable to place conditions as close to the resolution root as possible.

Also, these predicates cannot be debugged because they are rewrited by Dpdt. See below how to overcome it.

## Fast resolutions

Dpdt contains a special resolution type named 'fast'. Its syntax is `cluster.GetFast(default(IMyInterface));`. In general this syntax is faster that generic resolutions, but it has one additional constraint: you need to resolve directly from cluster type, it is impossible to cast cluster to the one of its interface (like `ICluster` or `IResolution`) and do fast resolutions.

## Compile-time checks

Each safety checks are processed in the scope of concrete cluster. Dpdt cannot check for cross-cluster issues because clusters tree is built at runtime. But cross-cluster checks are performed in the cluster constructor at runtime.

### Did source generators are finished their job?

Dpdt adds a warning to compilation log with the information about how many clusters being processed and time taken. It's an useful bit of information for debugging purposes.

### Unknown constructor argument

Dpdt will break ongoing compilation if binding has useless `ConstructorArgument` clause (no constructor with this parameter exists).

### Singleton takes transient or custom (captive dependency)

Dpdt can detect cases of singleton binding takes a transient/custom binding as its dependency, and make signals to the programmer. It's not always a bug, but warning might be useful.

### Circular dependencies

Dpdt is available to determine circular dependencies in your dependency tree. In that cases it raise a compilation error. One additional point: if that circle contains a conditional binding, Dpdt can't determine if circular dependency will exists at runtime, so Dpdt raises a compile-time warning instead of error. This behaviour can be changed by appropriate setting.

### More than 1 unconditional child

If for some binding more than 1 unconditional child exists it renders parent unresolvable, so Dpdt will break the compilation is that case.

### Conventional bindings

Dpdt will write some info in Build log for every conventional binding produced. For regular binding - will not. It is useful for debugging conventional bindings results.

## Async resolutions

Dpdt is a constructor-based injector. Async resolutions are not supported because we have no an async constructors. Consider using a factory class with an async method `async Task CreateSomethingAsync(...)`.

## Settings

Settings are things that modify compile-time cluster code generation. THEY ARE NOT WORKING AT RUNTIME.

### Cross cluster resolutions

These settings relates with checking for child binding resolutions; they are useful for an additional safety. They are applied for each of child resolutions.

#### OnlyLocalCluster

Each dependency **must** exists in local cluster. If not - ongoing compilation will break. Note: binding conditions is out of scope, only existing matters. You can define a local binding with `When(rt => false)`, and this check will mute. So, this setting is not something that can protect you at 100%. This is a default behaiour.

#### AllowedCrossCluster

Any dependency may be in home cluster or parent cluster. If local dependecy found at runtime it is used, otherwise request to the parent cluster is performed. (this is default behaviour for old version of Dpdt)

#### MustBeCrossCluster

NO local dependency allowed, any dependency MUST be in the parent cluster. If local dependency found, ongoing compilation will break. Note: binding conditions is out of scope, only existing matters. You can define a local binding with `When(rt => false)`, and this check will fire. So, this setting is not something that can protect you at 100%.

### Wrapper producing

These settings relate with a producing of wrapped-resolutions, like `Func<>`; they are useful for minimizing the cluster size.

#### NoWrappers

No bindings for wrappers will be produced. It is a default value.

#### ProduceWrappers

**Every** type of wrappers will be produced for this binding.

### Circular checking

These settings relates with a circular checking; they are useful for removing unused noise from build log (for example in case of decorator, look at `ProxySimple0_Fixture` unit test).

#### PerformCircularCheck

Do circular checking. It is a default value.

#### SuppressCircularCheck

Do not circular checking. Use this for decorators bindings.

### Constructor choosing

These settings relates with a constructor choosing algorithm performed by Dpdt. These settings sets a constructor argument **types** filter.

#### AllAndOrderConstructorSetting

Dpdt will take the only constructor that have a parameters with the types selected in this setting and in the same order. For example `.Setup>()` means that only constructor `MyClass(int a, long b)` will choose (argument names does not matters).

#### SubsetAndOrderConstructorSetting

Dpdt will take the only constructors that have a parameters with the types selected in this setting and in the same order, and additional arguments may exists before or after the selected. For example `.Setup>()` will choose the following constructors `MyClass(..., int b, long c)` `MyClass(int a, long b)` `MyClass(int a, long b, ...)`.

#### SubsetNoOrderConstructorSetting

Dpdt will take the only constructors that have a parameters with the types selected in this setting and their order does not matters, any additional arguments may exists. For example `.Setup>()` will choose the following constructors `MyClass(long a, int b)` `MyClass(int a, long b)` `MyClass(..., int a, ... long b, ...)` `MyClass(..., long a, ..., int b, ...)`.

Please make note: `in` `readonly` and `ref` modifiers of the constructor arguments will not taken into account.

## Debugging your clusters and conditional clauses

Because of source generators are generating new code based on your code, it's impossible to direclty debug your cluster code, including its `When` predicates (because this code is not actually executed at runtime). It's a disadvantage of Dpdt design. For conditional clauses, you need to call another class to obtain an ability to catch a breakpoint:

return Debugger.Debug(rt);
})
;
}
}

public static class Debugger
{
public static bool Debug(IResolutionTarget rt)
{
//here debugger is working
return true;
}
}
```

## Artifact folder

As a regular source generator, Dpdt is able to store pregenerated C# code at the disk. The only thing you need is correctly setup your csproj. For example:

```xml
true


```

If your clusters are huge, you may face with slowdowns in your work in VS because VS runs Dpdt in the background. To overcome this please put the following into your csproj:

```xml

false

```
This is to turn off code beautification so Dpdt will produce cluster code a bit faster.

# Dpdt Visual Studio Extension

To make a dealing with Dpdt easier, a Visual Studio Extension has been developed. Make note: it only supports [Visual Studio 2019 16.8 (and later)](https://marketplace.visualstudio.com/items?itemName=lsoft.DpdtVisualStudioExtension) and [Visual Studio 2022](https://marketplace.visualstudio.com/items?itemName=lsoft.DpdtVisualStudioExtension2022).

Please make note: Dpdt Visual Studio extension should be the SAME version as your Dpdt.Injector package version. If it is not possible, please use the latest version of the both. I carefully try to publish compatible versions of the new nuget and new vsixes at the same time. Sometimes, a new version of vsix can be published without nuget, and the opposite. It means that the new version of vsix (or nuget) will be compatible with last existing version of the nuget (or vsix).

If you click on a project in Solution Explorer and there is no Dpdt nuget installed, you can install its latest version easily:


Also, you can create a new cluster class or add a new binding method to the existing cluster:


There is a tool window to look, search and go to any binding in your solution:


You can enter a text to search everywhere, or use the following predicates to set a search scope:

- `from:` to search only in bind from fields
- `to:` to search only in bind to field
- `ca:` to search only in constructor arguments field
- `other` to search only in the scope field
- `location` to search only in binding location field

Keep in mind: the searching is case sensitive (like C# too). Examples: `MyClass`, `ca:MyConstructorArgument`, `location:MyFile.cs` etc.

But the main function is to generate a binding clauses through the custom codelens. The following images makes the picture brighter:




Settings window:


`EnableWhitespaceNormalization` sets whitespace normalization when you create a new binding through Dpdt Visual Studio Extension.

A lot of thanks to bert2 and his amazing example `https://github.com/bert2/microscope`, without his `microscope` no Dpdt extension will appear because of lack of tutorials in the scope of VS extension development.

# Known problems

* Dpdt extension do not support few types (in different assemblies) with the same full name. I will investigate it further.

If any problem occurs with this extension or the generator itself, please let me know. I will need to see the following log files `C:\Users\\AppData\Local\Temp\dpdt_*.log`.

# Alternatives

You may be interesting in the following alternatives:

- [Strong Inject](https://github.com/YairHalberstadt/stronginject)

# Feedback

Any ideas for new features of Dpdt and Dpdt Visual Studio Extension are welcome.