To reference code in Init(args) from your own code you need to create assembly definition assets in the roots of your script folders and add references to the assemblies containing the scripts you want to use.

Init(args) is split into four different assemblies:

1. InitArgs – The main assembly that contains most classes including MonoBehaviour<T>.
2. InitArgs.Interfaces – Assembly containing all interfaces such as IInitializable<T>.
3. InitArgs.Services – This contains only two attributes: ServiceAttribute and the EditorServiceAttribute. The reason that these attributes have been isolated to their own assembly is for performance reasons (you can read more about that here).
4. InitArgs.Editor – Editor-only assembly containing classes related to unit testing as well as custom editors and property drawers for the Inspector.

Recommended Assembly Setup

In most cases you will only need to use classes found in the InitArgs and in some cases the InitArgs.Interface assemblies, so add references to those to your assembly definition assets as needed. The assembly where you will have all your components that inherit from MonoBehaviour<T…> will need to reference at least the InitArgs assembly.

The InitArgs.Editor assembly you should only reference from your own editor-only assemblies. This might be useful when writing edit mode unit tests, if you want to make use of the Testable class to invoke non-public Unity event functions or the EditorCoroutine class to run coroutines.

For optimal performance it is recommended, if possible, to isolate all your service classes to their own assembly. If you manage to pull this off, then this assembly will be the only one that needs to reference the InitArgs.Services assembly. During initialization Init(args) uses reflection to scan all classes in assemblies that reference InitArgs.Services assembly, so the less classes there are to examine the faster this will be.

Since two-way references between assembly definition assets are not allowed, this will likely mean in practice that you can not directly references any classes contained in the assembly that houses your services. While this might seem like an insurmountable obstacle at first, it can also be a blessing in disguise, since it effectively forces you to decouple all your services from their actual implementations. You can pull this off by adding all your interfaces into their own assembly, having all your services  implement one of these interfaces, and then interact with your services through these interfaces instead of referencing the classes directly.

You can take a look at the Demo project as an example of how to organize your scripts in the recommended manner.

Sisus.Init Namespace

To reference code in Init(args) you also need to add the following using directive to your classes:

using Sisus.Init;