# MSAGL graph layout and viewing for .NET and web

> Microsoft Automatic Graph Layout, or MSAGL, provides C# layout libraries, Windows viewer controls, GraphMaps, and a TypeScript-based web implementation. Its main constraint is platform dependence: the documented native development workflow requires Visual Studio, UWP, and the Windows 10 SDK.

**microsoft/automatic-graph-layout** — A set of tools for graph layout and viewing

- Repository: https://github.com/microsoft/automatic-graph-layout
- Stars: 1,502 · Forks: 318
- Language: C#
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-automatic-graph-layout

## MSAGL separates layout computation from graph rendering

MSAGL addresses a specific engineering problem: turning a graph into positioned nodes and edges, then optionally displaying the result. The README positions it for developers who need layout in a .NET application and explains that there are several ways to combine those jobs. This separation matters because layout output and rendering are not necessarily owned by the same application layer.

The core component is `AutomaticGraphLayout.dll`, distributed through the `Msagl` NuGet package. According to the README, this is the appropriate module when an application only needs MSAGL to calculate a layout and will render the graph through a separate tool. The repository therefore supports headless use of the layout engine rather than requiring every consumer to adopt a Microsoft viewer control.

The `AutomaticGraphLayout.Drawing.dll` module, published as `Msagl.Drawing`, adds drawing attributes such as colors and line styles. It also defines node, edge, and graph classes. A developer can construct a graph with these types, assign visual attributes, and send that model to a viewer. This is more than a single algorithm wrapped behind one method: the project separates the computation engine from its graph and drawing model.

That architecture is useful for desktop applications that already have their own presentation system, because the README explicitly describes using only the core library and rendering separately. It also creates a decision point for adoption. MSAGL can be evaluated as a layout library, a model library, or a complete viewer stack. Those uses do not have identical dependency and platform expectations.

## WPF and Windows Forms controls provide the documented desktop viewer path

For desktop presentation, the repository publishes two viewer controls. `Microsoft.Msagl.WpfGraphControl.dll` is available through the `Msagl.WpfGraphControl` NuGet package for WPF applications. The Windows Forms control is `Microsoft.Msagl.GraphViewerGdi.dll`, published as `Msagl.GraphViewerGDI`. The README lists the same interaction categories for both controls: pan and zoom, forward and backward navigation, tooltips and highlighting for graph entities, and search that focuses matching entities.

The Windows Forms sample constructs a `Graph`, adds string-based edges, changes node colors and shapes, assigns the graph to `GViewer`, and places the viewer inside a `Form`. This gives a concrete first use without requiring an undocumented command or invented package setup. It also shows that visual attributes can be set after graph content has been added, including an edge color and individual node fill colors.

There is an API spelling detail worth preserving. The sample package and assembly identifier use `GDI` in uppercase, while the viewer namespace is `Microsoft.Msagl.GraphViewerGdi` with `Gdi` casing. C# package and namespace references are case-sensitive in their identifiers, so copying the README examples is safer than reconstructing those names from memory.

The viewer route is appropriate when a Windows application already uses WPF or Windows Forms and wants the features listed by MSAGL. It is not the most direct choice for an application requiring a documented, platform-neutral desktop viewer. The repository documentation does not describe Linux or macOS viewer controls, and its native solution build instructions are Windows-specific.

## Building GraphLayout.sln requires documented Windows components

The README does not present a package-manager installation or `dotnet` command for building the full native repository. Its documented path is to open `GraphLayout.sln` in Visual Studio, browse the `Samples` folder, and build the solution. That instruction comes with a specific prerequisite: Visual Studio must include the UWP development workload and the Windows 10 SDK. The README says Visual Studio can recommend installing missing components when the solution is opened, but they need to be present for a successful build.

A practical first use is therefore to install those Visual Studio components, open `GraphLayout.sln`, choose the Windows Forms viewer sample, and run it from Visual Studio. The repository does not name a menu path or a command-line build invocation for that operation, so the article cannot supply either without guessing. The expected visible result is the sample form containing three connected nodes, based on the documented sample code.

The small model construction portion of the README example is shown below. It creates the graph and adds the edges and visual attributes before the viewer is attached:

```csharp
Microsoft.Msagl.Drawing.Graph graph = new Microsoft.Msagl.Drawing.Graph("graph");
graph.AddEdge("A", "B");
graph.AddEdge("B", "C");
graph.AddEdge("A", "C").Attr.Color = Microsoft.Msagl.Drawing.Color.Green;
graph.FindNode("A").Attr.FillColor = Microsoft.Msagl.Drawing.Color.Magenta;
Microsoft.Msagl.Drawing.Node c = graph.FindNode("C");
c.Attr.Shape = Microsoft.Msagl.Drawing.Shape.Diamond;
```

This is a repository-source tutorial, not a NuGet installation tutorial. For a consumer application, the README links each desktop or core component to NuGet, but it does not provide exact `dotnet add package` commands. The install operation it actually documents is opening and building the solution in Visual Studio.

## GraphMaps targets zoom-dependent exploration of large graphs

GraphMaps is the repository’s large-graph viewing example rather than merely another graph control. The README says it can display large graphs such as online maps and reveal more detail as the user zooms. A linked paper explains its design and mathematics, while the repository supplies sample data under `GraphLayout/graphs`.

The documented workflow is source-based: open `GraphLayout.sln`, build it, and run `TestGraphMaps`. For large graphs, the configuration must be `Release/x64`. The README gives two input paths in `GraphLayout/graphs/composers.zip`: load `composers.msagl` to avoid preprocessing, or load `composers.dot` to generate `composers.msagl` and the `composers.msagl_tiles` directory.

That distinction makes GraphMaps a preprocessing-and-viewing workflow, not just a file-format conversion. The `.msagl` input appears to represent a prepared layout and tile set, while loading the `.dot` file invokes regeneration. The documentation does not describe cancellation, incremental preprocessing, failure recovery, or behavior for malformed graph files. It also does not quantify how large a graph must be before tiled detail becomes necessary.

GraphMaps is therefore a poor fit if the application requires a small graph with an ordinary pan-and-zoom viewer, or if pre-generated graph and tile files cannot be produced. Its clearest use is a Windows sample or desktop application built around large-graph exploration, with `Release/x64` selected and the input format chosen deliberately.

## WebMSAGL moves layout computation into a browser worker

WebMSAGL is a separate path for browser-oriented use. The README states that MSAGL was transcompiled to JavaScript with SharpKit and wrapped in TypeScript. This version includes a rendering and interaction layer, accepts graphs created programmatically or from JSON, performs layout, and can render to either HTML Canvas or an SVG block.

Its data flow is explicit. Application code supplies a graph, the web version lays it out, and the rendering layer draws the result in Canvas or SVG. The README also states that layout operations execute in a web worker. That design keeps layout computation away from the browser’s main application thread so the application can remain responsive while computation is taking place. Limited interactivity is supported, but the README does not enumerate its full range.

The documented setup remains repository-based rather than package-based: open `WebMsagl.sln`, build the solution, select an `index.html` from a sample folder as the starting page, and run `WebMsagl`. No exact npm package name, installation command, browser compatibility list, or deployment configuration appears in the documentation. As a result, WebMSAGL should be assessed as source from this repository rather than assumed to be a general-purpose browser package with a conventional install flow.

Compared with a server-side .NET layout call followed by a separate web renderer, WebMSAGL brings layout into the browser worker and includes Canvas or SVG output. That can fit interactive web clients, but the limited interactivity and undocumented deployment surface are material constraints.

## Licensing and release history require direct review

The repository declares a custom license that GitHub cannot classify. The README and repository metadata do not summarize its permissions, restrictions, redistribution terms, or obligations, so an engineering team must read the `LICENSE` file before incorporating code or binaries. This is not a case where a conventional open source identifier such as MIT or Apache-2.0 can be assumed from the repository’s public location.

The repository is not archived, and its last push was on 2026-10-08. That establishes current repository activity in the stated metadata, but it does not by itself describe the release lifecycle. The listed releases include `v1.1` on 2022-01-28, `v1.0.0` on 2022-01-15, and `release_2` on 2022-01-15. The gap between the available releases and the recent push means that source changes and published package versions should not be treated as equivalent without checking tags and package contents.

There is also an upgrade distinction between components. The README lists NuGet packages for the core engine, Drawing module, WPF control, and Windows Forms control, while the repository includes `GraphLayout.sln` and `WebMsagl.sln` as source workflows. A team must decide whether it consumes a package, integrates repository source, or builds GraphMaps itself. Those choices can produce different upgrade and verification work, and the documentation does not define a version compatibility matrix.

## Conclusion

Adopt MSAGL when the application specifically needs Microsoft’s graph layout components and can accept its documented platform constraints or use its NuGet modules independently. Do not select it as a platform-neutral, installation-free graph renderer, or as a polished end-user viewer without first evaluating the Windows build requirements, custom license, release cadence, and integration surface.

## FAQ

### Which MSAGL package should a C# application use for layout only?

Use the `Msagl` NuGet package for `AutomaticGraphLayout.dll`. The README specifically recommends the core layout engine when rendering and visualization will be handled by another tool.

### What is required to build Microsoft Automatic Graph Layout from source?

The documented setup is Visual Studio with the UWP development workload and the Windows 10 SDK. Open `GraphLayout.sln` and build it from there.

### Does MSAGL support graph layout in a web application?

The repository includes WebMSAGL, a TypeScript-based version that accepts programmatic graphs or JSON, runs layout in a web worker, and renders to HTML Canvas or SVG. Its documented setup uses `WebMsagl.sln` and a sample `index.html`.

## Sources

- [Issues](https://github.com/microsoft/automatic-graph-layout/issues)
- [microsoft/automatic-graph-layout on GitHub](https://github.com/microsoft/automatic-graph-layout)
- [README](https://github.com/microsoft/automatic-graph-layout/blob/master/README.md)
- [Releases](https://github.com/microsoft/automatic-graph-layout/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-automatic-graph-layout