Resolved collection in order of dependency graph

[xandudex]

Hello! I've done a work that I think would be great to have at core level of the package but meybe that work should be done in another more efficient way.
I've created some custom Interface

public interface IGameInitializable
{
    bool Initialized => true;
    ValueTask<bool> InitializeAsync();
}
` ``

the idea is on my loading screen I'm waiting when all instances from DI that implements it will Initialize one by one.
```[cs]
private async UniTask InitializeServicesAsync()
{
    List<IGameInitializable> services = Container.Resolve<IEnumerable<IGameInitializable>>().ToList();
    foreach (IGameInitializable service in services)
        await service.InitializeAsync();
}

but some of them depends on each other, and they must be in order of their dependecies. VContainer by default resolves in the order of registration, and to somehow fix it, I've wrote a source generator to create a graph where all types that implements IGameInitializable will sorted at generation time, and I can simply sort services like so

services.Sort((a, b) =>
{
    for (int i = 0; i < GameInitializableGraph.OrderedGraph.Count; i++)
    {
        if (a.GetType() == GameInitializableGraph.OrderedGraph[i])
        {
            return -1;
        }

        if (b.GetType() == GameInitializableGraph.OrderedGraph[i])
        {
            return 1;
        }
    }

    return 0;
});

what do you think, is it possible to have resolved collections in order of Dependency Graph or it should be as is ?

[tigran-sargsyan-w]

Here, I’d keep IEnumerable<T> deterministic (registration order) rather than trying to “auto-toposort” it by the DI graph.

A container can know the construction graph for a single root, but ordering a collection by “dependencies” is ambiguous (different items can depend on different things, lifetimes/scopes change what’s available, some deps are optional/conditional, async init isn’t the same as construction, etc.). Doing it implicitly at core level would likely be surprising.

In VContainer the usual approach is:

• Express ordering via constructor injection (if A needs B, inject B into A) and let the container build the graph.
• Use entry point interfaces (IInitializable / IPostInitializable / IStartable / IAsyncStartable) and split init into phases when needed.
• If you truly need a strict sequence, make a single bootstrap/orchestrator entry point that awaits the specific services in the order you want (or add an explicit Priority/Order value).

Your source-generator graph works, but I’d treat it as an app-level policy rather than a core DI feature.