Inspecting container contents at runtime

[yallie]

Hi Maksim,

MEF used to have a cool diagnostic library for browsing the container contents. The library fetched all registered parts (services), their exports/imports and their health status. It allowed to examine MEF composition container in runtime to diagnose resolution issues such as unsatisfied imports or single imports with matching multiple exports (cardinality mismatch). Plain vanilla MEF used to have a very poor diagnostic messages, so this library was a life saver. On top of this library was built a mefx command-line analysis tool, but I had my own UI built around it:

Unfortunately, the library was hosted on CodePlex and was abandoned (or merged into MEF and then abandoned, I'm not sure exactly), so the only thing left of it I could find online is this archived github repository, with no discussions, issues, etc. It has some documentation files: diagnostics.md.

So finally my question: is there a way to inspect a running DryIoc container to fetch all service registrations, examine their dependencies, etc., without actually creating them? I know we can start with container.GetServiceRegistrations() and try building expressions for each registered service, but expressions are not very easy to examine... Is there a way to find a collection of service dependencies, their expected cardinality (import single instance or import a collection), and health status (matching service is available or not)?

I've found a nice and handy container.Validate() method, but looks like it only reports resolution exceptions, such as missing or circular dependencies. Is there a way to build a service graph so I can visualize it? :)

[dadhi]

@yallie It may be a dumb idea, but what about the C# code? DryIoc may generateva valid C# code for the specified resolution roots. The runtime dependent resolutions (or holes in the graph) will be set to the appropriate Resolve calls.
Actually this feature is based on FastExpressionCompiler Expression.ToCSharpString method.
I may provide more details Tomorrow.

[yallie]

@dadhi, thanks for the idea!

C# code is definitely better than a visualized expression 👍

But it would probably fail to process services with problems in their dependencies, would it?

Folks keep asking from time to time to restore the visualizer tool since we migrated from MEF to DryIoc. Would be great if I find a way to examine service info and build a collection of imports similar to mefx diagnostics. Or is it essentially the same as duplicating DryIoc service resolution logic but generating different data instead of C# expressions? If it's so, then I'm afraid we'll have to postpone this idea indefinitely...

[dadhi]

But it would probably fail to process services with problems in their dependencies, would it?

It may insert the Resolve call for such dependency and there is an option for this already as I remember.
This works like a hole in the graph, indicating that something may be Registered later to fill this hole.