Version 2.0.0

[PereViader]

Version 2.0.0 is now up!

I believe the codebase is stable enough and that the documentation is good enough to merit releasing already.
There is still plenty that we want to improve so expect even more updates!

The API of the container has been overhauled and the container has been split in two variants

ManualDi.Main
|-> ManualDi.Sync
|-> ManualDi.Async

ManualDi.Sync is an almost direct replacement for the previous library ManualDi.Main.

If you are to choose one of the variants, I recommend going with the Async variant given it allows for a deeper integration with async loading and initialization workflows that are typical in games.

In order to update you will need to update the openupm package manager to point to the new repository https://openupm.com/packages/com.pereviader.manualdi.sync.unity3d/

If you want to move to the new async variant
https://openupm.com/packages/com.pereviader.manualdi.async.unity3d/

Here are the changes where ManualDi.Sync differs from ManualDi.Main

• Transient bindings were removed, bindings will now always be Single. Transient bindings prevent us from implementing the Async variant of the container and there was always little to no use for them. In case you need something similar, create a factory class that can create new instances when needed.

• Lazy bindings were removed. All bindings will now be NonLazy. Lazy binding functionality might be nice but came at the cost of unexpected complexity in spots where part of the object graph was not resolved. This also prevented us from implementing the Async variant of the container.

• Inject attribute was removed. The library promotes having completely clean types that don't reference the container. This pattern goes against the principle that we wanted to container to follow. Property injection is now not supported by the container source generation and all injection must go through the source generated Inject method.

• WithStartup renamed to QueueStartup

• Several changes in names to streamline the container.

A new variant of the library ManualDi.Async is now introduced. This new variant allows clients to create and initialize object asynchronously. This allows the introduction of new extension methods that to integrate ManualDi with async APIs. For example in Unity3d we can now do the following

public AssetReference ServiceMonoBehaviourAssetReference;
public AssetReference SceneMonoBehaviourAssetReference;

...

b.Bind<ServiceMonoBehaviour>().FromAddressablesLoadAssetAsyncGetComponent(ServiceMonoBehaviourAssetReference);
b.Bind<SceneMonoBehaviour>().FromAddressablesLoadSceneAsyncGetComponent(SceneMonoBehaviourAssetReference);

The snippet above will load the asset and scene, get the component from them and make sure that when the container is disposed and that the relevant assets are properly unloaded.

From an external API point of view, only the construction and disposal of the container changes. It now has an async API.

Before

using var container = new DiContainerBindings().Install(b => {
   //bindings as usual here
}).Build();

After

await using var container = await new DiContainerBindings().Install(b => {
   //bindings as usual here
}).Build(CancellationToken.None);

In order for the Async container to be able to resolve the dependencies in the proper order on async code paths, we had to update the resolution pipeline of the container. If you manually implement FromMethod, you will now need to call the DependsOn method on the binding with the relevant dependencies.

b.Bind<SomeClass>().FromMethod(c => new SomeClass(c.Resolve<OtherClass>()).DependsOn(d => d.ConstructorDependency<OtherClass>());

This will however only be necessary if you DONT use the source generated methods. In case you do use them, the api you should use will be the same

b.Bind<SomeClass>().Default().FromConstructor();

[Lowlet]

Hi! I've updated project to 2.0.0 and I'm now getting null container in MonoBehaviourSubordinateEntryPoint

Any ideas why?

[Lowlet]

Can you please check the actual exception that is happening during construction.

Is this it? I'm not too advanced in debugging...

[PereViader]

From the exception, I can see that the FromConstructor method of some TargetLockIndicatorViewModel class is calling Resolve for PlayerCharacterView, the container then fails when it can't find the instance.

There are a few reasons for this

• There is no binding for PlayerCharacterView

  • Can you provide both the bindings for PlayerCharacterView and TargetLockIndicatorViewModel

• The binding for PlayerCharacterView is on a subcontainer but is being resolved on a parent container that doesn't have access to it

  • Please check this is not the case, otherwise there is no way for it to see each other

• There is some circular dependency in your codebase of length X

  • For instance a circular dependency of length 3 would be A depends on B. B depends on C. C depends on A. There is no way to create all of them through constructors and so one of them will fail with a could not resolve. (I have plans to improve the error to let the user know it failed due to a circular dependency.
  • Check if this is the case. If so, you will need to break the circular dependency either by changing the code or by using Inject and CyclicDependency (check docs)

• There is some bug on the dependency order for ManualDi.Async

  • I am adding some functionality so that we can check if this is the case

[Lowlet]

Ok, thanks for helping, it was circular dependency. TargetLockIndicatorViewModel had dependency on PlayerCharacterView and PlayerCharacterView on TargetLockIndicatorViewModel. But how does it worked before on 1.9?

[PereViader]

I have published a new version that now properly displays the actual exception that happened during build time

Also added some debug functionality to see the order bindings will actually be called

Sample below generates

Apparent: System.Int32, Concrete: System.Int32, Id: 
Apparent: System.Object, Concrete: System.Object, Id: 

        try
        {
            await using var container = await new DiContainerBindings()
                .Install(b =>
                {
                    b.Bind<object>()
                        .DependsOn(x => x.ConstructorDependency<int>())
                        .FromMethod(x => throw new Exception());
                    b.Bind<int>();
                })
                .WithFailureDebugReport()  // enable the report
                .Build(CancellationToken.None);
        }
        catch (Exception e)
        {
            var report = (string)e.Data[DiContainer.FailureDebugReportKey]!; // get the report
            //use this report to check the order of dependencies 
            return;
        }

I am not completely sure why it would have worked before 🤔
It should have failed with a stack full exception

[Lowlet]

This was a bit confusing, I was thinking it's a bug with new version because everything worked perfectly before but it was my mistake. Good reminder that I need to refactor these classes, they were coded pretty badly because I wanted to make it work as fast as possible 😄. Anyway, thank you again for help!