CppSharp: Generating C# Bindings for C/C++ Libraries

The gap CppSharp fills between a native library and .NET

Calling a C library from C# by hand means writing a DllImport declaration per function, marshalling every pointer and string by hand, and rebuilding that surface whenever the native header changes. For a library with a few hundred declarations that work is tedious but tractable. For something like a game engine, a media codec, or a GUI toolkit, it is not. CppSharp targets that second case. The README describes it as a tool and set of libraries that consumes C/C++ header and library files and generates the glue code needed to surface the native API as a managed API. The intended audience is the maintainer of a native codebase who wants a .NET binding, or a .NET developer who needs to consume an existing native library without writing the interop layer by hand. The README lists QtSharp, MonoGame, LLDBSharp, Xamarin and several FFmpeg binding projects among its users, which tells you the scale it is built for: libraries with large, class-heavy C++ APIs rather than a handful of C entry points.

Clang AST in, C# or C++/CLI out

CppSharp is split into three libraries, and the split matters if you plan to extend it. The AST library mirrors Clang's C/C++ AST and type system as C# classes: declarations, statements and expressions, types, class object layout, plus declaration and type visitors. The Parser library turns C/C++ source into that syntax tree, and it also parses symbols out of library archives and shared libraries. The Generator library walks the syntax tree and emits binding code. The README states the parser is based on the Clang C++ parser, so header constructs that Clang accepts are what CppSharp can see. Output backends are C++/CLI and C# via P/Invoke. The Generator advertises multiple ABIs (Itanium, MS, ARM, iOS), Windows, macOS and Linux as target platforms, and both .NET and Mono as runtimes. On the semantic side it handles C++ virtual method overriding from managed code, multiple inheritance translated into C# interfaces, std::string, default parameter values, and Doxygen comments converted into C# comments. The extension point is user passes and type mapping, which is how you adjust generated semantics for a library whose conventions the defaults do not match.

Getting started with CppSharp: what the repository actually gives you

The README does not put install commands on the front page. It points to docs/GettingStarted.md for getting started, docs/UsersManual.md for the user's manual and docs/DevManual.md for developers, and the package is published on NuGet as CppSharp. The repository ships worked examples under examples/Parser/ and examples/SDL/, and those directories are the concrete reference for what a generator project looks like: which types you derive from, which callbacks you override, and how the driver is configured for a real library. There is no copy-pasteable generator skeleton in the README itself, so the honest first step is to read docs/GettingStarted.md and then open the example that matches your target, rather than guessing at an API surface. The README also notes that problems go to GitHub issues, and that commercial support is available by opening a discussion or issue. Expect the first working build to come from adapting an example, not from a documented one-liner.

Where the Clang dependency becomes your problem

Because parsing is Clang-based, CppSharp inherits Clang's limits. Headers that rely on compiler-specific extensions, on preprocessor state that only exists inside a particular build system, or on macros that expand differently under MSVC than under Clang will not parse the way your compiler sees them. The README does not claim MSVC parsing, and the v1.1 release note is titled "Add GCC11 and VS2022 support", which suggests toolchain support has arrived in discrete steps rather than being continuously broad. The practical failure mode is a header that compiles in your product but produces a wrong or incomplete syntax tree in CppSharp, and the fix is usually a wrapper header that hides the problematic construct. That is real work, and it sits outside the generator. The second constraint is that generated bindings are a build-time artifact. Every native API change means regenerating and rebuilding the managed side. If your native library ships on its own release cadence and you cannot pin the header revision you generate from, the binding will drift.

CppSharp against ClangSharp and SharpGenTools

The related searches around CppSharp include ClangSharp and SharpGenTools, and the three sit at different points on the same spectrum. ClangSharp exposes Clang's parsing to .NET, so you get the syntax tree and write the binding logic yourself. CppSharp wraps that parsing in a generator with opinions already baked in: multiple inheritance becomes interfaces, Doxygen becomes XML comments, virtual overrides are wired for you. SharpGenTools takes the other route, driving generation from a mapping configuration file rather than from a generator class you write in C#, which suits teams that want the binding surface declared as data. The trade-off is control against convention. CppSharp gives you a code-level extension point through user passes and type mapping, at the cost of a generator project you maintain. If your target library is small and stable, hand-written DllImport declarations remain a legitimate answer and none of these tools earn their build step.

Versioning, licence and what regeneration costs you

CppSharp is MIT licensed, which permits commercial use and modification; the LICENSE file at the repository root is the authoritative text and this is not legal advice. On maintenance: the last push to the default branch was on 2026-05-18, and the most recent release is v1.2 from 2025-11-19. The release before that, v1.1, is dated 2023-10-18, and v1.0.45.22293 from 2023-02-06. That spacing is worth reading before you adopt. A two-year gap between v1.1 and v1.2 means toolchain updates arrive in bursts rather than continuously, so a new compiler or a new .NET runtime may sit unsupported for a while. Upgrade cost is dominated by regeneration, not by the package itself: bumping CppSharp changes the generated output, and that diff lands in the same commit as any semantic changes in the generator's user passes. Budget for reviewing generated diffs on every version bump. The README offers commercial support through GitHub discussions or issues, and lists no support tiers or SLAs.

Editorial conclusion

Adopt CppSharp if you maintain a C or C++ library and want a managed API surface generated from its headers rather than hand-written DllImport declarations, and if you can commit to regenerating and rebuilding when the native headers move. Do not adopt it for a one-off call into a single exported function, or if you need the binding to work without a Clang-based build step on the machine doing the generation. Verify first that the target library's headers parse under the Clang version CppSharp ships against, and check the docs/GettingStarted.md path against your platform before writing any generator configuration.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mono/CppSharp on GitHub
4. README
5. Releases