Generate one puml file for a set of interfaces and classes related to each other by inheritance

[Stoffelche]

I think for bigger projects it would not be feasible to generate allInOne. On the other side to have one puml for each type, which then only includes its base types does not help either. One would have to manually copy those together. for which one would like to see a complete inheritance diagram.
Therefore I think it would make sense to have a type filter like the fully qualified name of a class or an interface as parameter, with the goal to obtain a diagram with all the classes and interfaces related by inheritance. Later this could be refined to generate for example only recursively inherited classes or base classes.
In order to achieve this, one needs two passes. First generate all the syntax tree objects with their relations. Then starting from the seed class or interface recursively run through the relations to obtain the set to be rendered in puml.
In order for this to work one would need a type dictionary for classes, interfaces, structs, ... where the key is the fully qualified type name.
And also two relations dictionaries, one base->inherited, one inherited->base, where the key is the fully qualified type name, and the value is a list of fully qualified type names. Or one could put both relation-directions in one dictionary.
Anyway, using these dictionaries, one can reduce the types to be rendered, and then in a second pass render only those which remain after the filtering.

[Stoffelche]

The problem here is to resolve the full qualified name of the types. As of now this tool here does not take into account the namespace of classes.
This can lead to unhandled typename conflicts, as two classes of different namespaces can have the same name.

While this can be remedied for the type itself by traversing the syntax node up through parent, there seems to be no solution for the base classes and interfaces of a type using the syntax tree only.
This is understandable, because on the syntax level this information is not yet available, as the namespace of the base type must be resolved by the compiler taking into account the using directives, Thust one has to resort to compilation and symbol layer in order to obtain this information.

But in order to correctly resolve inheritance relations between types, the fully qualified names of all types is needed.
Right now in my opinion the relationships built with this tools are correct only, when there are no duplicate type names across different namespaces.

For this reason I think that in consequence this tool needs to be enhanced to use compilation and symbol layer.

I will try to target one or more projects instead of a directory of files, and have it compiled by msbuild. Then traverse the symbols of this compilation (SymbolVisitor instead of CSharpSyntaxWalker). While the SymbolVisitor has a different logic, (for example methods and constructors go together ...) it should still be possible, to port the existing code to the symbol layer.

I am going to do this in a fork, which will have the primary goal to pick a set of types related by inheritance and plot them together in one single uml. As this is a different approach which requires different configuration, it won't be directly related to the classes and configuration of this project here, but I will heavily borrow from the plantuml-code generation of this project .

[Stoffelche]

I have done some rudimentary implementation of inheritance diagrams based on symbol tree instead of syntax tree.

https://github.com/Stoffelche/CSharpToPlantUml