# NodeNetwork: a WPF node editor control for .NET > NodeNetwork is an Apache-2.0 licensed C# library that gives a WPF desktop application a node graph editor, with pan, zoom, automatic layout and connection validation, built on reactive MVVM code. It suits Windows desktop tools such as shader or calculator editors, and it does not run anywhere WPF does not. **Wouterdek/NodeNetwork** — A C# library with a WPF node editor component based on ReactiveUI - Repository: https://github.com/Wouterdek/NodeNetwork - Stars: 965 · Forks: 167 - Language: C# - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/wouterdek-nodenetwork ## A node editor as a reusable WPF control NodeNetwork is a .NET C# library that provides a node editor component for WPF. The framing matters, because it is not an application you run and not a framework you build an application on top of. It is a control you host inside your own WPF window, alongside your own nodes, your own data model and your own evaluation logic. The README shows two demos to establish what that means in practice. One is a calculator example application, where each node is part of an arithmetic expression. The other is a shader editor example made using NodeNetwork, and the README calls a shader editor a more realistic use case for the library. The examples are downloadable from the releases page and their source is included in the repository, which makes them the fastest way to judge whether the control fits your own editor. Binary releases of the library itself are published on NuGet under the package name NodeNetwork, so consumption is through the normal package manager rather than by copying source. The intended audience is a Windows desktop developer whose product involves a graph the user manipulates directly. If you are building a workflow designer, a visual query builder or an audio routing tool, the work the library saves you is the canvas behaviour, and the work it leaves you is everything that makes the graph mean something. ## The feature list is mostly about canvas mechanics The features section is short, and it is worth reading closely because it tells you exactly where the library stops. Panning and zooming controls are listed as proper features rather than basics, which is a fair signal about how much fiddly work a graph view otherwise consumes. An automatic layout system is there, so nodes can be arranged by the library instead of by hand. The controls are described as highly customizable but easy to use by default, which is the usual way of saying that every visual element is overridable and the defaults are reasonable. The one that matters most for correctness is extensive network and connection validation support. In a node editor, the failure mode is a graph the user can build into a nonsensical state: a node connected in the wrong direction, a connection to an incompatible port, a cycle where one is forbidden. Validation that is part of the library, rather than something each application reinvents, is what makes the difference between a demo and a product. The list also claims unit test coverage, and the repository backs that up with a NodeNetworkTests/ project plus a separate CalculatorTests/ project, which suggests the behaviour that is tested is the behaviour that matters rather than only the drawing code. ## ReactiveUI and MVVM, with the graph living in the view model The library is built on ReactiveUI and the README describes the controls as built with modern reactive MVVM code. That combination is the architectural decision a user inherits. In a reactive MVVM design, the view is a thin projection of observable state, and the graph is state. Nodes are objects, connections are relationships between them, and the canvas is a rendering of that graph rather than the graph itself. When the user drags a node, the view model is updated, and the view re-renders from the change. That approach pays off in an editor, where every graph mutation has to be observable, serialisable and undoable, and where the same graph may be evaluated by a separate engine. It also has a cost, and anyone adopting the library should be clear about it. Reactive programming has a learning curve, and a team that writes view models in a plain property-change style will find the examples unfamiliar. The documentation exists to smooth that over, and the cookbook chapters are where the patterns are shown in practice rather than in the abstract. The README is explicit about the intended style, reactive MVVM code with modern reactive patterns, so the choice is documented rather than implicit. Whether your team can live with it is the real adoption question. ## What the repository actually contains The top level of the repository is a solution, NodeNetwork.sln, with the library and its supporting projects side by side, which is a good map of the project's scope. The core is the NodeNetwork/ directory. NodeNetworkToolkit/ sits alongside it and holds reusable higher level pieces that are not the control itself. NodeNetworkTests/ is the unit test project, and CalculatorTests/ is a separate test project tied to the calculator example. Three example applications are present: ExampleCalculatorApp/, ExampleShaderEditorApp/ and ExampleCodeGenApp/, the last being a code generation example rather than a visual editor. ExamplesPackaging/ handles packaging of the examples, and StressTest/ is a separate project for load testing. Two more entries describe how the documentation is produced. The Documentation/ directory holds the documentation sources, gen_docs.ps1 is a PowerShell script that generates them, and the published documentation lives on the gh-pages branch. Documentation changes are made by pulling request against that branch, so the docs follow the same review process as the code. There is also a NuGet/ directory, which is where the packaging project for the published library lives. For a reader, this layout answers the question the README does not: the library is one part of a repository that also carries three working applications, two test projects, a stress test and its own documentation pipeline. ## Getting started means NuGet and the cookbook, not a README tutorial There is no install command in the README, and there is a reason for that. The library ships on NuGet as NodeNetwork, and the README points you to a documentation site for setup information, cookbook chapters, examples and an API reference. The documentation structure is the actual getting started guide, and it is organised as a quickstart cookbook. That is a deliberate choice: a node editor has too many concepts to explain in a repository README, so the short chapters in the cookbook carry the worked examples and the API reference carries the details. The three example applications in the repository serve the same purpose from the other direction. The calculator example is the smallest complete editor, the shader editor is the realistic one, and both are downloadable as builds from the releases page. Running one of them is a faster evaluation than reading about an API, and the source is right there to copy from. Two practical notes about the platform and the version. The library targets .NET Framework 4.7.2 and .NET Core 3.1 or newer, so a current .NET application can consume it, and the Reactivity requirement means the ReactiveUI packages are part of what you take on. And the README states the licence is open and permissive, with the Apache 2.0 text copied into the repository under LICENSE. ## The example releases stopped in 2021 while the code kept moving The release history and the commit history tell two different stories, and both are relevant to an adopter. The published releases are tagged as example applications, with v5.1.2 on 2021-01-24, v5.2.0 on 2021-05-02 and v6.0.0 on 2021-08-07. So the newest downloadable example build is from 2021, and the version numbers on those tags refer to the example applications rather than to a stream of library releases. The source, on the other hand, has moved more recently. The last push to the default branch was on 2026-04-14, which is more than six months before now, so this is not a project you should describe as actively developed. It is a project whose master branch still receives changes without a steady release cadence attached to them. What that means practically is that the NuGet package you install and the master branch source can be different things. If you need a recent fix, you are looking at building from source or at a fork, not at waiting for a tag. If you need a stable reference implementation, the 2021 example applications still illustrate the API, with the caveat that the code has moved on since. The upgrade cost for consumers is therefore low in the licence sense, since Apache-2.0 allows modification and redistribution with attribution, and higher in the source sense, because the documentation is what will tell you how much has changed. ## Where NodeNetwork is the wrong tool The hard boundary is the platform. WPF is a Windows desktop framework, so a control built on it cannot run in a browser, on macOS or on Linux. If your product is a web application, the entire approach has to change, and the closest equivalent path is a canvas based editor built with web technologies, which means rewriting the node model, the interaction handling and the validation logic in a different stack. That is not a port, it is a second implementation, and the reusable part of NodeNetwork would be the design ideas rather than the code. The second boundary is scope. What is provided is a graph view with panning, zooming, layout, validation and customisable controls. What is not described is a complete editor application: undo and redo, copy and paste, multi selection, grouping, search, file format and import and export. Some of that may exist in the library, but the README does not claim it, so anyone whose product is a serious editing tool should verify it before assuming it is there. The third boundary is styling. The controls are customisable, which is the right call for a library, but customising a WPF control template is more work than restyling a DOM element, and the cost rises if you later need a cross platform look. The alternative approach for a team willing to write the canvas themselves is to use the ReactiveUI model, since the graph as observable state is the part of the design that transfers cleanly to any platform, and build the view from scratch against it. ## Conclusion Adopt NodeNetwork when you are building a Windows desktop tool whose core interaction is a node graph, and you would rather spend your effort on the nodes than on canvas mechanics. Skip it when your target is the browser, macOS or Linux, since the control is built on WPF and has no cross platform story, or when you need a full editor with undo, copy and paste already built in, since the library supplies the graph view rather than a complete editing application. Verify three things before you start: that the NuGet package still matches your target framework, given the library targets .NET Framework 4.7.2 and .NET Core 3.1 or newer, that the reactive MVVM patterns in the cookbook fit your own view model style, and what has changed since the last push on 2026-04-14, since the published example releases date from 2021. ## FAQ ### What is NodeNetwork? NodeNetwork is a .NET C# library that provides a node editor component for WPF, with panning, zooming, automatic layout and network and connection validation, built on ReactiveUI with reactive MVVM code. ### How do I install NodeNetwork? Binary releases of the library are published on NuGet under the package name NodeNetwork. The README does not give install commands and points instead to the documentation site, which covers setup, cookbook chapters, examples and an API reference. ### Which .NET versions does NodeNetwork target? The library is built for .NET Framework 4.7.2 and .NET Core 3.1 or newer. ### Does NodeNetwork work outside Windows? No. It is a WPF control, and WPF is a Windows desktop framework, so the library does not run in a browser or on macOS or Linux. Web based editors need a different implementation. ### What licence is NodeNetwork released under? The library is licensed under the Apache License 2.0, described in the README as open and permissive, with a copy of the licence included in the repository under LICENSE. ## Sources - [Issues](https://github.com/Wouterdek/NodeNetwork/issues) - [License: Apache-2.0](https://github.com/Wouterdek/NodeNetwork/blob/master/LICENSE) - [README](https://github.com/Wouterdek/NodeNetwork/blob/master/README.md) - [Releases](https://github.com/Wouterdek/NodeNetwork/releases) - [Wouterdek/NodeNetwork on GitHub](https://github.com/Wouterdek/NodeNetwork) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wouterdek-nodenetwork