# ImGui.NET: a .NET wrapper that stops short of being a UI library

> The C# binding for Dear ImGui gives you the immediate mode API and none of the widgets, renderers or layout engine, which is the point when you are building a tool rather than an application.

**ImGuiNET/ImGui.NET** — An ImGui wrapper for .NET.

- Repository: https://github.com/ImGuiNET/ImGui.NET
- Stars: 2,271 · Forks: 357
- Language: C#
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/imguinet-imgui-net

## A wrapper over cimgui, not a port of Dear ImGui

ImGui.NET is a .NET Standard library that exposes Dear ImGui to C#. The layering is worth stating first because it explains everything else. Dear ImGui is a C++ library that emits textured triangles and deliberately knows nothing about how you draw them. cimgui wraps that C++ library in a plain C API. ImGui.NET sits on top of cimgui and hands you managed bindings.

So the wrapper does not reimplement any part of Dear ImGui. There is no managed port to drift out of sync with upstream, and no managed rendering backend. The README describes what you get as a raw wrapper around the native ImGui API plus a very thin safe managed API for convenience, and says the result is currently very much like using the native library directly: simple, flexible and low in ceremony.

The repository reflects that shape. The tree is short: a `src/` directory, a `deps/` directory, `Directory.Build.props` for shared MSBuild settings, a `LICENSE`, and two scripts, `download-native-deps.sh` and `download-native-deps.ps1`, whose names say plainly what they do. There is no separate renderer project, no widget collection and no layout package in the tree. Topics are just games, graphics, imgui and netcore.

For learning the API, the README points you at the C++ headers, `imgui.h` and `imgui.cpp`, and at the exported functions in `cimgui.h`. That is an honest instruction rather than a gap: because the binding is a direct translation, Dear ImGui's own documentation is the reference for ImGui.NET.

## Rendering is your problem, and the sample shows one answer

Because Dear ImGui outputs vertex buffers rather than drawing commands, a .NET application has to supply a renderer. The repository's sample does this with Veldrid, a portable graphics library for .NET. The README also notes that example renderers exist for MonoGame and OpenTK for OpenGL.

The practical consequence is that adopting ImGui.NET means evaluating a graphics stack as well. The README is explicit that Dear ImGui by itself does not care what technology you use for rendering, which is the mechanism of the portability but also the reason a renderer choice cannot be deferred. Veldrid is a reasonable default because it abstracts several graphics APIs, but it is a second dependency to keep current alongside the binding.

Dear ImGui's own positioning, quoted in the README's See Also section, is that it is designed for content creation tools and visualization or debugging tools rather than user-facing application interfaces. It favours simplicity and iteration speed and, in the project's words, lacks certain features normally found in more high-level libraries. The same section points at Dear ImGui being particularly suited to game engine tooling, real-time 3D applications, fullscreen applications and embedded or console environments where operating system conventions do not apply.

So the honest framing is that ImGui.NET targets developer tools and debug overlays. If you are building an ordinary business application with data grids, date pickers and accessibility expectations, this library is the wrong category of thing, and no amount of wrapper quality changes that.

## Native binaries ship for the three main platforms

The NuGet package bundles a prebuilt native library on Windows, macOS and mainline Linux distributions. On any other operating system you have to build cimgui yourself, following the instructions in the cimgui repository. That is the single most important operational fact about this project: it is not a pure managed dependency, and the portability story has a gap in it.

The two download scripts in the repository root are how the native side gets fetched during a build on Windows or elsewhere. For a debugging session the process is documented separately, and it is genuinely awkward. By default the packaged native code is optimized, which makes debugging hard. The README's four steps are to clone the ImGui.NET-nativebuild repository at the tag matching your ImGui.NET version, run `build.cmd debug` or `build.sh debug`, copy the produced cimgui.dll, libcimgui.so or libcimgui.dylib into your application, and then run under a native debugger or enable mixed-mode debugging in Visual Studio.

That workflow tells you something about the project. Debugging ImGui.NET means debugging native code through a managed surface, with a version-matched native build as a prerequisite. Nobody has tried to hide this, and the README calls debugging native code a documented section rather than an afterthought.

For building the wrapper itself, Visual Studio 2017 is the minimum supported version, the .NET Core SDK is needed for command line builds, and the library targets .NET Standard so it runs on the major .NET runtimes and operating systems.

## A maintenance handover that the README states plainly

This project has an unusual piece of information in its README that is worth reading before anything else. In a note dated February 2023, the original author states that they are no longer able to publicly share updates to ImGui.NET and related libraries, credits another contributor with continuing to actively maintain the library and keep it current with new versions of native Dear ImGui, and directs readers to a Discord server for the current status of development.

The release history supports that description rather than contradicting it. The most recent versions were all cut by the second contributor: v1.90.9.1 in July 2024 upgraded to ImGui 1.90.9 and added Dependabot to auto-upgrade GitHub Actions, v1.91.0.1 in August 2024 updated the renderer and moved to .NET 8 while dropping .NET 6 support, and v1.91.6.1 in January 2025 upgraded to 1.91.6.

Two things stand out in that sequence. The .NET 8 move with .NET 6 dropped is a real compatibility event: an application still targeting .NET 6 needs an older package. And the version numbering tracks the native Dear ImGui release, so there is a predictable way to tell how current the binding is.

The repository has 2,271 stars, 357 forks and 174 open issues, and the last push was on 2026-07-21. The repository is not archived. Version numbers following the upstream project mean you should pick a package version deliberately rather than floating to latest, and the README's advice to ask on Discord is there because the versioning alone does not tell you what is supported.

## Where a reader should actually start

The README is short, which fits a project whose job is thin. It covers what the wrapper is, the sample and its use of Veldrid, the build requirements, how the API maps to the native one, the native debugging procedure, and links back to Dear ImGui and cimgui.

What it deliberately does not carry is a tutorial. There is no getting started guide, no rendering walkthrough and no list of supported widgets, because the wrapper does not supply widgets. The effective answer to how do I use this is the sequence the README implies: read Dear ImGui's own documentation to learn the immediate mode API, read cimgui's headers to understand what is exposed, then look at the sample under `src/` for how a .NET application drives a frame and hands triangles to a renderer.

That is a workable path for someone who already knows Dear ImGui, and an unfriendly one for someone arriving from Windows Forms or WPF. The tradeoff is inherent rather than a documentation oversight. A direct binding has no room for opinionated helpers, which is what keeps it tracking upstream so closely, and it also means every convenience you would expect from a .NET UI library has to be built in your application.

The 174 open issues are consistent with a binding project: most of the surface area is either upstream behaviour questions or platform packaging, neither of which the wrapper author controls.

## Conclusion

ImGui.NET works when you already know Dear ImGui and need it inside a .NET process, because it gets you a working binding quickly and then stays out of the way. It stops being the right answer when you need a self-contained control library, a designer-friendly layout system, or a build that needs no native binaries at all. The maintenance arrangement is the part to plan around: the original author stepped back in February 2023 and another contributor has been shipping native version bumps since, with v1.91.6.1 in January 2025 and a last push on 2026-07-21. Pin the package version and check the Discord for current status before committing to it, since the README itself points there rather than making a version support statement.

## FAQ

### What are the downsides of using ImGui?

Dear ImGui's own documentation says it lacks certain features normally found in more high-level libraries, and it is aimed at content creation and debugging tools rather than end-user interfaces. In practice the costs are that you write your own renderer, there is no widget or layout system to inherit, and wrappers such as ImGui.NET add a native binary that has to be built for platforms outside Windows, macOS and mainline Linux.

### What is Dear ImGui used for?

Content creation tools and visualization or debugging tools, where rapid iteration matters more than a polished widget set. The project also calls out game engine tooling, real-time 3D applications, fullscreen applications and embedded or console environments where operating system conventions do not apply. It emits optimized vertex buffers that you render in your own pipeline.

### Is ImGui C or C++?

Dear ImGui is C++. Because other languages cannot bind to it directly, cimgui wraps it in a plain C API, and ImGui.NET builds managed bindings on top of that C layer. That three-tier arrangement is why a .NET user gets native binaries rather than a managed port.

### Is ImGui free for commercial use?

The MIT license permits commercial use, and the ImGui.NET repository carries an MIT license at its root. Two things are worth checking separately though: the license of the native library you bundle for a platform ImGui.NET does not ship prebuilt binaries for, and whether the version of Dear ImGui you pin matches what your renderer expects.

## Sources

- [ImGuiNET/ImGui.NET on GitHub](https://github.com/ImGuiNET/ImGui.NET)
- [Issues](https://github.com/ImGuiNET/ImGui.NET/issues)
- [License: MIT](https://github.com/ImGuiNET/ImGui.NET/blob/master/LICENSE)
- [README](https://github.com/ImGuiNET/ImGui.NET/blob/master/README.md)
- [Releases](https://github.com/ImGuiNET/ImGui.NET/releases)

---

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