# PlantUmlClassDiagramGenerator: C# source to PlantUML class diagrams > PlantUmlClassDiagramGenerator turns C# source into PlantUML class diagram syntax, and it ships three ways to run it, a Roslyn source generator that emits the diagram as part of the build, a Visual Studio Code extension, and a dotnet global tool. The conversion rules are documented as explicit tables, from type keywords through accessibility modifiers to property accessors. **pierre3/PlantUmlClassDiagramGenerator** — This is a generator to create a class-diagram of PlantUML from the C# source code. - Repository: https://github.com/pierre3/PlantUmlClassDiagramGenerator - Stars: 771 · Forks: 140 - Language: C# - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/pierre3-plantumlclassdiagramgenerator ## What the tool generates and from what PlantUmlClassDiagramGenerator is a generator that creates a class diagram in PlantUML from C# source code. That is the whole of it, and the simplicity is the point: it reads types and members and writes the PlantUML text that a PlantUML renderer turns into a picture. The output is text rather than an image, which is what makes the tool composable. The generated puml files can be committed, diffed, reviewed and rendered by a PlantUML server as part of a documentation build, and the -allInOne switch exists specifically to gather the output of all diagrams into a single include.puml file for that purpose. Three ways to run it are documented. The primary one is a Roslyn source generator, which is a separate project in the repository, and the class diagram is then produced automatically as part of the compilation rather than by a separate command. The second is a Visual Studio Code extension called C# to PlantUML, published in the marketplace. The third is a .NET Core global tool, published to the NuGet gallery as PlantUmlClassDiagramGenerator, with the command named puml-gen. The repository is a Visual Studio solution, PlantUmlClassDiagramGenerator.sln, with the source under src/, a test/ directory, a tools/ directory and a uml/ directory holding the example images that the documentation refers to. The primary language is C#, and the licence field on the repository says MIT. The one release tag in the history is v0.5.0.0-beta from 2016-12-15, and the last push was on 2026-08-14, so the project is still being touched even though it has not been cut as a version in a long time. ## Installing the global tool and the command reference The tool path requires the .NET 8.0 SDK or newer, installed from Microsoft's download page, and then a single install command. ```bat dotnet tool install --global PlantUmlClassDiagramGenerator ``` The command itself is puml-gen, and its argument reference is given in full in the documentation. ```bat puml-gen InputPath [OutputPath] [-dir] [-addPackageTags] [-public | -ignore IgnoreAccessibilities] [-excludePaths ExcludePathList] [-createAssociation] ``` The flags are worth reading one at a time, because the single-file and directory modes differ in ways that are easy to get wrong. InputPath is required and sets the source file or directory. OutputPath is optional, and if you leave it out the puml files are written to the same directory as the input files, which is convenient for a quick look and unhelpful for a project where you want the diagrams somewhere specific. The -dir switch says that both paths are directories. -addPackageTags applies only in directory mode, and then the program adds package tags and puts all the relations at the end of include.puml. -public restricts the output to public members, and -ignore takes a comma separated list of accessibilities to leave out, which is the more flexible of the two. -excludePaths takes a comma separated list of paths relative to the InputPath, and there is a wildcard form: to exclude several paths that contain a specific folder name, precede the name with a double star, for example `**/bin`. -createAssociation creates object associations from references of fields and properties, which turns the diagram from a list of types into a picture of the relationships between them. -allInOne applies only in directory mode and copies the output of every diagram into include.puml, which is what lets a PlantUML server render one combined image. -attributeRequired limits the output to types that carry the PlantUmlDiagramAttribute in their declaration, which is the switch to reach for when you want to diagram one part of a solution. And -excludeUmlBeginEndTags omits the @startuml and @enduml lines from the generated file, for the case where the diagram is being included inside another one. ## The conversion rules, from type keywords to accessors The most useful part of the documentation is the pair of tables that define exactly how C# maps onto PlantUML, and the reasoning is consistent throughout. For type keywords, class, struct, interface and enum map to the same keywords in PlantUML, and a C# record becomes a class with the <> stereotype, because PlantUML has no record concept. For type modifiers, abstract becomes the abstract keyword while static, partial and sealed become stereotypes, since PlantUML has no direct equivalent for those. The accessibility table is the one that matters most for reading a generated diagram. public becomes a plus sign, private becomes a minus sign, protected becomes a hash, internal becomes an <> stereotype, and protected internal becomes the hash sign followed by the same stereotype. The member modifiers follow the same pattern, with abstract, static, virtual, override, new, readonly and event each mapping to a stereotype or a field annotation. The property accessor rules are the most detailed part, because a C# property carries more than a type. A property with a getter and a setter becomes the type followed by <> and <>, a get-only property becomes a single , and a property with a private setter becomes <><>. An expression-bodied property, written as an arrow with a constant, is treated as get-only. The generic type handling is the one detail that is genuinely fiddly, because PlantUML has no notion of a generic arity. A single parameter generic becomes a class named with a backtick and the count, quoted, followed by the type parameters in angle brackets. ``` class "GenericsType`1"{ } class "GenericsType`2"{ } ``` That is the CLR convention leaking through, and it is a reasonable choice given that PlantUML is being asked to render a .NET type. ## The source generator route and what it changes The Roslyn source generator is the most interesting of the three delivery routes, because it moves the diagram into the build. A source generator runs inside the compiler, so the diagram is produced as an artefact of compiling the project rather than as a separate step that someone has to remember to run. For a project where the diagram is meant to be regenerated on every change, that is the difference between a diagram that is current and a diagram that is stale, and it is why the documentation points at the source generator project as the primary mechanism and links to its own directory for details. The downside is the same as for any source generator. It participates in compilation, so it inherits the compiler's performance characteristics, and a generator that misbehaves produces build errors rather than a bad diagram. There is also a question about where the generated file goes, and whether it should be committed or ignored, and the documentation here does not settle it. The middle route, the Visual Studio Code extension, is the one a developer would use interactively while working on a file, and the command line tool is the one for a build script or a documentation pipeline. The three routes share the same conversion rules, so a diagram generated in the editor and a diagram generated in the pipeline should agree, which is the main thing you want from a tool that offers three ways to run it. ## Where PlantUmlClassDiagramGenerator is the wrong choice The first limitation is that it is C# only. The tool is a C# source generator plus a C# command line utility, and there is no path from Java, TypeScript, Python or Go into this particular generator, so a polyglot repository gets diagrams for one language only unless you use a different tool for the rest. The second is that the diagram reflects declared types rather than runtime behaviour. A dependency injection container, a reflection-based framework or a plugin loaded at runtime will not appear, and neither will the relationships that exist only in configuration. For a design document that has to match how the system actually behaves, the generated diagram is a starting point rather than an answer. The third is the accessibility default. The examples show -public being used to restrict output, and -ignore taking a list of accessibilities to omit, which suggests the default includes more than you might want in a diagram shared outside the team. A diagram that shows internal members of every type is noisy, and a diagram that shows none of them hides the design decisions that usually matter in a review. The fourth is the age of the tool. The single release tag is a beta from 2016, and while the last push shows the source is still being maintained, there is no version history to consult for the recent changes and no release notes beyond the README's own table of README revisions. The fifth is that the project is one person's work with a narrow remit, and the documentation is written in two languages with a revision table for the README itself, which is the kind of arrangement that works well while one person is maintaining it. ## How it compares with Visual Studio class diagrams and with a general documentation generator The comparison with the class designer built into Visual Studio is the first one, and the difference in approach is the output format. The Visual Studio designer produces a diagram in a proprietary form that only Visual Studio can render, and it is a designer you interact with rather than a generator that produces text. PlantUML produces text in a syntax with a large ecosystem of renderers, a server mode, and integrations with documentation pipelines, and it can be committed and diffed. For a diagram that is reviewed in a pull request, the text form is the one that works, because a reviewer sees a diff of the puml file rather than a screenshot of a picture. The second comparison is with a general documentation generator such as one of the .NET documentation tools that produce API reference pages. The difference in scope is that a documentation generator works from the public API surface and produces reference material for readers, while this produces a picture of the design for the people who wrote it. The audiences barely overlap. The third comparison is with a diagram from a modelling tool such as a UML tool with reverse engineering. Those tools can reverse engineer a codebase into a model that includes more than the language's type declarations, including sequence information and inferred relationships, and they give you a diagram you can edit. The difference in approach is that the generated artefact is authoritative, because it comes from the code rather than from a model that can drift, and it cannot be hand-edited into something the code does not support. The fourth is the cost. A source generator that produces a diagram at build time is close to free once set up, while a modelling tool that reverse engineers the same codebase is a project in itself. ## Licence, project state and what to check before you wire it into a build The licence field on the repository says MIT, with a LICENSE file at the root, which is a permissive licence that lets you use the tool in a commercial build without any obligation beyond keeping the notice. The project is not archived and the last push was on 2026-08-14, so the source is being maintained, and the only tagged release is v0.5.0.0-beta from 2016-12-15. The repository has a .github/ directory, a .vscode/ directory for editor settings, the solution file, and a README in both English and Simplified Chinese with a link between them. Four things to check before you add it to a build. Whether the source generator or the command line tool suits the pipeline. The generator keeps the diagram in step with compilation, and the tool is easier to control from a script and easier to exclude from a pull request. What the accessibility flags should be for your audience, since the default is not documented and the examples lean towards the restricted end. Whether -createAssociation produces a diagram you want to look at. Adding associations from field and property references produces richer diagrams, and richer diagrams are also noisier ones, and the choice is a per-invocation flag rather than a global setting. And where the generated file goes, and whether it is committed. The directory mode writes include.puml with the relations at the end, which is the file a PlantUML server would render, and whether that file belongs in the repository is a decision your team has to make. ## Conclusion PlantUmlClassDiagramGenerator suits a .NET team that wants its class diagrams regenerated from the source rather than maintained by hand, and that has settled on PlantUML as its diagram syntax. It is the wrong tool for a codebase that is not C#, and the wrong choice if you need the diagram to reflect runtime behaviour rather than declared types. Before you rely on it, check the accessibility rules in the conversion tables, since a diagram that hides internal members by default can understate a design, and read the flag reference rather than the examples, because the behaviour of the directory mode differs from the single-file mode in ways the examples do not make obvious. ## FAQ ### What does PlantUmlClassDiagramGenerator do? It generates a class diagram in PlantUML syntax from C# source code. The output is text rather than an image, so it can be committed, diffed in review and rendered by a PlantUML server as part of a documentation build. ### How do I install PlantUmlClassDiagramGenerator? Install the .NET 8.0 SDK or newer and run `dotnet tool install --global PlantUmlClassDiagramGenerator`. The command is then available as puml-gen, and the same conversion is also available through a Roslyn source generator and a Visual Studio Code extension. ### What are the main puml-gen options? InputPath is required and OutputPath is optional, with -dir marking both as directories. -public restricts output to public members, -ignore omits a comma separated list of accessibilities, -excludePaths excludes relative paths with a wildcard form such as `**/bin`, -createAssociation builds object associations from field and property references, -allInOne gathers the directory output into include.puml, and -attributeRequired outputs only types marked with the PlantUmlDiagramAttribute. ### How does the tool map C# accessibility to PlantUML? public becomes a plus sign, private a minus sign and protected a hash sign, while internal becomes an <> stereotype and protected internal becomes the hash sign with that stereotype. The member modifiers abstract, static, virtual, override, new, readonly and event each map to a stereotype or a field annotation. ### What licence does PlantUmlClassDiagramGenerator use? MIT, with the terms in the LICENSE file at the root of the repository, so the tool can be used in a commercial build without further obligation. ## Sources - [Issues](https://github.com/pierre3/PlantUmlClassDiagramGenerator/issues) - [License: MIT](https://github.com/pierre3/PlantUmlClassDiagramGenerator/blob/master/LICENSE) - [pierre3/PlantUmlClassDiagramGenerator on GitHub](https://github.com/pierre3/PlantUmlClassDiagramGenerator) - [README](https://github.com/pierre3/PlantUmlClassDiagramGenerator/blob/master/README.md) - [Releases](https://github.com/pierre3/PlantUmlClassDiagramGenerator/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pierre3-plantumlclassdiagramgenerator