Automating DOT Diagram Generation

[dunnodepends]

Problem Statement

It's really difficult to (:-P) use ingenious! package Autofac.Diagnostics.DotGraph. Namely, it is hand-heavy.

Desired Solution

See pull request.

Some of my steps have been automated (attempts to use asynchronous, parallel multi-threaded):

0. Receive DOT output-folder
1. CleanCodeAndImageFolders() <= cleans folders
2. WriteDOTCode(args.TraceContent) <= write DOT per documentation
3. GetImageFileFullPath(args.TraceContent) <= generate image filenames per DOT sources
4. WriteDOTDiagram() <= use the DOT file to write-out the image at generated-filename.

Alternatives You've Considered

Autofac Analysis but I could not get it to function within the time I had.

Additional Context

ToDo1: Parameterize output paths, filename template
ToDo2: Remove performance test
ToDo3: Write functional test
ToDo4: Use plantUML?
ToDo5: Option to filter-out or partition Microsoft assembly-rooted diagrams?

[tillig]

Perhaps it would be good to understand more about your pain points so we know what changes are good to make. The README shows some pretty simple usage that doesn't feel too heavy-handed. Some of the other changes noted here are... Maybe not things we want to support in this library.

For example, the notion of cleaning folders out. There's a lot to that if we want to offer it as part of a library. The output folder location has to be configurable. We need to handle issues with permissions, which includes issues with restricted environments that don't have rights to write files. We have to think about managing image file size and potentially stop the diagnostics from filling up the disk.

That's why we provide the ability to write these files but we don't include all the stuff to manage the folder and contents and all. We don't have the bandwidth to own, maintain, test, and support all those use cases.

You'll also notice in core Autofac that we will scan assemblies you've loaded and do registrations, but we don't own all the load contracts and the actual assembly loading ourselves. There are too many variables there to "package all that up" and maintain it at the levels our users will expect.

I am a bit interested in what we might be able to do to help with the async case, but if that's just forking a process or thread to do the image write behind the scenes... I'm not sure we want to own or orchestrate that at the library level, either.

If these are things you really want in a library, though, we do encourage the community to add their own extension libraries out there that they publish and support outside of Autofac. And if there's something we have that stops the extension from being written, like an API you need, that's definitely something we can look at enhancing.

Let me know what you think.

[dunnodepends]

I agree: looking back, I see I actually created an algorithm (I did not even allow passing paths by adding app-extension parameters), but I did not analyze if the same can be achieved any easier with API-changes, or can be packed-up as-is as a third-party extension. The current model always generates DOT code (even noise from how Microsoft classes are wired), which fills-up the folders - so this change was initially undertaken to each: (1) to automatically generate the diagrams from DOT code, which led to (2) clean the folders between runs, and the slowness to application startup led to (3) generate diagrams concurrently. Enjoy the holiday weekend!

[tillig]

Given there's been no traction on this for several months, I'm going to go ahead and close it. If it turns out folks are interested in reviving it, that's cool - but we need to get more information about the proposed API and potentially separate out some of the stuff consumers should handle from the stuff we can maintain here.