# WpfHexEditorIDE: a WPF and .NET 8 workbench for binary analysis and .NET projects

> WpfHexEditorIDE packages a hex editor, a format definition language, a Roslyn language client and a plugin SDK into one Windows desktop IDE. It is unusually ambitious for a tool that describes itself as a learning project, but its debug launch path is not finished yet.

**abbaye/WpfHexEditorIDE** — WpfHexEditor Studio is a IDE built on WPF and .NET 8, designed for advanced binary analysis and reverse engineering—combining a powerful hex editor, deep inspection tools, and native support for .NET projects and Visual Studio solutions in a single high-performance platform.

- Repository: https://github.com/abbaye/WpfHexEditorIDE
- Website: https://www.nuget.org/profiles/abbaye
- Stars: 940 · Forks: 145
- Language: C#
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/abbaye-wpfhexeditoride

## A Visual Studio style workbench for people who open binary files by hand

WpfHexEditor Studio is a Windows desktop IDE built with WPF on .NET 8, aimed at ROM hackers, firmware reverse engineers and .NET developers who need to look inside compiled or packed data. The project frames the idea plainly: "Think Visual Studio for binary files." That framing shows up in the mechanics rather than the marketing. The project system opens native `.whsln` and `.whproj` files as well as Visual Studio `.sln`, `.csproj` and `.vbproj` solutions, and builds them with MSBuild, including rebuild, clean, parallel project compilation and a live progress bar. Around that sit the editors a binary analyst expects: hex, code, image, audio, JSON and Markdown, with the choice of editor decided by data rather than by file extension guesswork. A Data Inspector reads the bytes under the caret as more than forty different types at once, including integers, floats, strings, GUIDs, dates, colours and IP addresses. The audience is a desktop engineer who wants one process and one workspace, not a library to embed in someone else's application.

## The .whfmt definition language decides what a file is and which editor opens it

The centrepiece is `.whfmt`, an in-house definition format the project calls schema v2.3, with more than 790 definitions shipped in the box. A definition declares how a binary format is laid out, using repeating blocks, unions, versioned structures, pointers, checksums, assertions, forensic alerts, variables and references. The same definitions drive format detection, where magic bytes are matched, multiple signatures can compete, a confidence score is assigned, and MIME types are considered. Because the editor set is selected by these declarations, the project claims that adding support for a new file type means writing a `.whfmt` definition and no C#. The same catalogue also ships as a separate cross-platform NuGet package named `whfmt.FileFormatCatalog`, under `Sources/Core/WpfHexEditor.Core.Definitions`. For readers who want to extend the format database, that package path is the more practical entry point, since it does not require the full IDE or its WPF dependency.

## The docking shell is written in house rather than borrowed from a library

Many editor shells lean on a third party docking framework, which pulls in a dependency and imposes someone else's layout model. This project builds its own. Panels float, dock, auto-hide and pin, tab strips are colour themed, and tab placement can be moved to the left, right or bottom of the workspace. There are sixteen built-in themes, including Dark, Light, VS2022Dark, DarkGlass, Dracula, Nord, Tokyo Night, Catppuccin Mocha and Latte, Gruvbox Dark, Forest, Matrix, Synthwave 84, Cyberpunk and a High Contrast variant. Layout changes go through undo and redo on `Ctrl+Shift+Z` and `Ctrl+Shift+Y`, workspace state is serialisable, and dropping a tab onto another produces a placement aware overlay that changes tab corner radii depending on where the tab lands. The trade off is real: this is a large surface maintained by one project, and the layout behaviour you get is the behaviour this project implements, not a documented standard.

## Roslyn runs inside the process for C# and VB.NET code

The Code Editor is backed by an in-process Roslyn host speaking the Language Server Protocol version 3.17, with thirteen provider types wired up: completion, hover, signature help, code actions, rename, inlay hints, code lens, semantic tokens, call hierarchy, type hierarchy, pull diagnostics, linked editing and a breadcrumb navigation bar. The `.whfmt` definitions also decide how source languages behave in that editor, covering syntax highlighting for more than fifty seven languages, folding, bracket pair matching, comment toggling, auto-close of brackets, indentation, end-of-block hints, breakpoint validation and whitespace rendering. On the binary side, an Assembly Explorer inspects .NET PE files and decompiles C# and VB.NET through ILSpy. The .NET side tooling extends to testing: the built-in runner detects xunit, nunit and mstest projects and parses TRX output, invoking the test platform with a single command.

## Plugins, terminals and a multi provider chat panel share one command registry

The extension story is the most conventional part of the design. The plugin SDK sits at version 2.0.0 with a frozen API under semver, plugins are packaged as `.whxplugin` files, and a Plugin Manager UI installs them. Around that sit a typed EventBus with more than thirty nine domain events, a capability registry, extension points for menus, toolbar, titlebar, panels, status bar and terminal commands, a dependency graph, plugin signing with signature validation, and an out-of-process sandbox that still embeds the plugin window by handle. Twenty eight plugins ship with the IDE, and loading is lazy: a plugin stays unloaded until a matching file extension or command triggers it, while manifest-driven stubs keep it visible in menus. The Command Palette on `Ctrl+Shift+P` searches commands, files, symbols and line positions across roughly one hundred registered commands, and the multi-tab terminal carries more than thirty five built-in commands. An AI chat panel sits on top of this and talks to Anthropic, OpenAI, Google Gemini, Ollama and Claude Code CLI, with 25 MCP tools and `@file`, `@selection`, `@errors` and `@solution` mentions.

## Getting hold of it: the IDE from releases, the controls from NuGet

There is no installer script, package manager recipe or clone-and-build instruction in the project documentation, so there is nothing here to reproduce line by line. What the repository does say is where the pieces live. The IDE itself is distributed through the project's GitHub releases, which carry versioned builds such as v0.6.5.8, v0.6.4.75 and v0.6.3. The standalone pieces are published on NuGet under the `abbaye` profile, which the repository lists as the project homepage, and the same profile carries the family of UI control packages the README advertises as thirteen NuGet packages. The definition catalogue is a separate cross-platform package, `whfmt.FileFormatCatalog`, which is the sensible first download if your interest is parsing binary formats rather than running the full shell. Running the test suite, once a .NET 8 SDK is present and a solution has been cloned, goes through the standard .NET test platform, which the project wires to the `dotnet test` command and parses as TRX.

```bash
dotnet test
```

That single invocation is the runner interface: the IDE calls the .NET test platform, reads the TRX result file back into the test panel, and reports pass and fail counts for xunit, nunit or mstest projects without a separate runner setup.

## The debugger is a user interface without a working launch path

This is the most important caveat in the project. The Debug menu offers Start, Stop and Restart along with Step Over, Step Into and Step Out, there is a collapsible toolbar pod, the execution line is highlighted, and the breakpoint system is substantial: conditions, hit counts, an enable and disable toggle, solution-scoped persistence, a Breakpoint Explorer panel and a right-click gutter popup for editing breakpoints. All of that is labelled at roughly sixty percent complete, and the project states plainly that debug launch is not yet functional, with the user interface and breakpoint infrastructure ready but runtime attach still pending. That is an unusual amount of investment in an unfinished feature, and it means the natural question, whether the process under inspection will stop at your breakpoint, has no answer in the current build. Anyone choosing this tool for disassembly with live debugging rather than for hex editing and inspection will find the central workflow unfinished.

## Licence terms and the actual maintenance picture

The README badge states AGPL v3, while the licence field on the repository says that a custom licence is in use and that GitHub cannot classify it, so the LICENSE file in the repository root is the authoritative text rather than the badge. Read it before you plan to embed the control packages in a commercial product, and note that the catalogue package ships separately, so the two can carry different obligations. On activity, the repository is not archived and the last push was on 2026-06-29, with tagged releases v0.6.5.8 on 2026-05-12, v0.6.4.75 on 2026-04-16 and v0.6.3 on 2026-03-22, so the project is being worked on. The project also describes itself plainly as being made with Claude Code for learning LLM and as being for fun rather than perfect. That self description is worth taking seriously when you assess the upgrade cost of a tool whose shell, format catalogue and plugin API all move together.

## Conclusion

WpfHexEditorIDE fits a Windows engineer who works on binary formats and .NET solutions in the same session and wants to extend the shell with .whfmt definitions or plugins. It does not fit anyone who needs a working launch-and-attach debugging loop today, since the debugger is UI only at this stage, and the README also notes the project was produced with Claude Code for learning purposes. Before adopting it, check the release notes for the state of debug launch, read the LICENSE file to see which terms the custom licence actually grants, and confirm that the 790+ bundled definitions cover the formats you care about rather than relying on the count as a quality claim.

## FAQ

### Is WpfHexEditorIDE free and open source, and under what licence?

The repository is public and not archived, and the README badge states AGPL v3. The licence field on the repository says a custom licence is in use that GitHub cannot classify, so the LICENSE file at the repository root is the text that governs use.

### Does WpfHexEditorIDE let you debug a running .NET program?

Not yet. The Debug menu, stepping commands, execution highlighting and the breakpoint system are present, but the project states that debug launch is not yet functional and that runtime attach is pending, with the debugger described as roughly sixty percent complete.

### How do I add support for a binary file format that WpfHexEditorIDE does not know?

You write a `.whfmt` definition file rather than writing C# code. Definitions describe the binary layout and drive both format detection and parsing, and the catalogue is also published separately as the `whfmt.FileFormatCatalog` NuGet package.

## Sources

- [abbaye/WpfHexEditorIDE on GitHub](https://github.com/abbaye/WpfHexEditorIDE)
- [Issues](https://github.com/abbaye/WpfHexEditorIDE/issues)
- [Project website](https://www.nuget.org/profiles/abbaye)
- [README](https://github.com/abbaye/WpfHexEditorIDE/blob/master/README.md)
- [Releases](https://github.com/abbaye/WpfHexEditorIDE/releases)

---

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