Yes, that is the theory. In practice we have more than 10 top-level projects that reference hundreds of shared assemblies which register their dependencies by themself. If I follow the recommendations of Mark Seemann, we will have to duplicate shared project registrations in every top level module and that is something I want to avoid even if it is the wrong way to do it. In practice the developer working in shared project must make dozens of commits to each top level module to register its shared dependency. That leads to other problems with git access to those modules and etc. For me the practical issues outweighs, benefits. Additionally we already adopted that aproach with Unity. We followed the approach that Microsoft used in ASP.NET Core each module to register itself. My question again is, does Pure.DI allows me to do that. Thanks.

My research found that Pure.DI alternatives like StrongInject and Jab provide concept of Module imports, which allows to achieve what I asked here. Please consider this as an options for Pure.DI

Alternatively, you can configure DI in each project and use only public types in the settings in top-level components.

@ivan-prodanov Thank you for your interest in this project!

Pure.DI offers a different approach compared to traditional dependency injection containers. It is not a library, but a helper in writing code in the Pure.DI paradigm.

Imagine that you write all your code in the Pure.DI paradigm. You have no containers. A component called MyLib contains the IService interface and its MyService implementation. Another top-level component, such as the console application MyApp, contains a Consumer class uses IService in its logic, which is implemented to it via a constructor.

You have several options on how to do this, but in a pure DI paradigm, it is preferable to do it this way. Create an instance of the Consumer class with all the necessary dependencies in the MyApp component, like this:

var consumer = new Consumer(new MyService());
consumer.UseIt();

A very important point is that the dependency tree is defined at compile time and is completely static:

classDiagram
 Consumer --> IService

and the composition of objects advising it is also defined at the compilation stage and transformed into code that uses new operators. This code is checked by the compiler and all optimizations are performed.

If the MyLib component contained some source or binary code for setting up the dependency tree, then before the "main" compilation it would be necessary to perform some "preliminary" compilation, run this code, get the metadata for building the dependency tree and run the main compilation with the created object compositions.

flowchart TD
 Find[Find registration comonents]
 --> |set of projects or libs| PreCompile[Preliminary compilation]
 --> |assemblies| Run[Load assemblies and run registrations]
 --> |metadata| Generation[Create a dependency tree and generate code]
 --> |code of compositions| Compilation[Main compilation]

But this logic of "dynamic dependencies" can change the dependency tree, for example, depending on the environment parameters, as MS DI for ASP.NET Core depending on the application profile can use different endpoints or different loggers.

It is better to change your way of thinking here. And do not think of Pure.DI as a library of containers, but perceive it as a tool for generating source code of object compositions.

Or it can be used like this. MyLib contains a lot of interfaces and their implementations. MyApp depends on some very limited set of abstractions (1-10 interfaces for example). Pure.DI can help to write code to create instances of these abstractions with all their dependencies. They can already be registered in the ServiceCollection.

I believe he is not asking about dynamic dependency resolution. May be an example of an implementation for the discussed feature in another compile time DI container/source generator will bring come clarity on the topic.

More info about the module feature. By my humble understanding of compile time source generators, I believe there is no runtime dependency resolution here.

My understanding of this feature is that you can create multiple small parts of compile time registrations in each assembly and then 'glue' them together in the executing assembly. None of this involve runtime dependency resolution.

Yes it does. I ran some tests with StrongInject and it seems it does what I describe above. You can have AssemblyLibrary that have many internal classes. The AssemblyLibrary itself makes the compile time DI registrations to a IModule, mapping public interfaces to internal classes and then in the executable assembly merge this IModule to its registrations and was able to resolve types that are internal for AssemblyLibrary

There are three viable options for compile time DI in .net so far - StrongInject, Jab and Pure.DI. The other two libraries both support module feature. I already linked StrongInject module feature, here is Jab Modules. I would rather pick Pure.DI from the three but modules are must for us. It just not possible not to have this for big projects.

Correction - It seems the claims that StrongInject support internal class registrations are not true. I just tried what they said should work but it doesn't. Here it small sample what I am trying to achieve

I made an example solution that has both a library called Lib and an application that uses it App.

Now the App project references the Lib project as a dependency on the source code. In order for the source code dependency to work, the App project additionally contains a reference to the \Lib\Composition.cs file:

<ItemGroup>
 <ProjectReference Include="..\Lib\Lib.csproj"/>
 <Compile Include="..\Lib\Composition.cs"/>.
 <Link>Lib\Composition.cs</Link>
 </Compile>
</ItemGroup>

If the Lib library is used as a binary dependency from the NuGet package, everything will work too. If you build a Lib package, it looks like this:

image

The top part will add the Composition.cs file to the project as Lib/Composition.cs and it will participate in the compilation to provide bindings metadata. And the binary file Lib.dll will be used as a normal library, it contains abstractions and implementations.

I use this approach in my projects.

I plan to add a project template to make it faster to create such libraries from scratch, I will add documentation about it.

As promised I will investigate the possibility of implementing your proposed feature.

Added template v 2.0.1 with template-short-name dilib. It can be used to create libraries using Pure.DI:

dotnet new -i Pure.DI.Templates
dotnet new dilib