# GtkSharp is a C# wrapper for GTK 3 that outgrew its Mono ancestor > GtkSharp binds GTK and its satellite libraries, glib, gio, gdk, atk, pango and cairo, to .NET, and it is a fork of the Mono project that took a different path: .NET Standard 2.0 instead of .NET Framework 4.5, and GTK 3.22 instead of GTK 2. The build is a Cake script over a code generator, and the packaging is one NuGet package per wrapped library. **GtkSharp/GtkSharp** — .NET wrapper for Gtk and other related libraries - Repository: https://github.com/GtkSharp/GtkSharp - Stars: 986 · Forks: 116 - Language: C# - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/gtksharp-gtksharp ## The fork chose a different target framework and a different GTK The most useful thing in the documentation is the comparison table, because it explains in one line why this project exists separately from the Mono one. GtkSharp targets .NET Standard 2.0 and GTK 3.22, and the note in the extra notes column is that it does not need glue libraries. The Mono project it was forked from targeted .NET Framework 4.5 and GTK 2, with a note that it could also handle GTK 3.0 but that version was never officially released. Read together, those two rows describe a fork that took a different path rather than a copy that tracks the original. The component list is the standard GTK stack: glib, gio, cairo, pango, atk and gdk, and the project states that it is maintained completely separately from the Mono repository it came from. The default branch is `develop`, which tells you the work happens on a development line rather than on a release branch. ## The library and the samples carry different licences The licence section splits the repository in two, and the reason is the usual one: the code you link into your application is under a copyleft licence, and the code you copy out of it is not. GtkSharp and its related components are licensed under the LGPL v2.0, with the text in the `LICENSE` file at the root, while the samples in `Source/Samples` are licensed under The Unlicense, with their own licence file inside that folder. So a sample application can be taken and used without conditions, while the wrapper assemblies themselves carry the LGPL terms, which is the arrangement you would expect and is worth checking if you plan to ship a closed source application that uses them. The repository also carries an `AUTHORS` file, and the tree is organised into a `Source/` directory, a `CakeScripts/` directory, a `build.cake` script and a `cake.config`, which is the shape of a project with a real build pipeline rather than a set of project files you open in an IDE. ## Building is a Cake script driving a code generator The build instructions assume.NET 6 is installed and then give four commands: ```bash git clone https://github.com/GtkSharp/GtkSharp.git cd GtkSharp dotnet tool restore dotnet cake build.cake ``` The `dotnet tool restore` step matters, because it is what makes the Cake script available, and the Cake script is the build. The documentation then explains how the source is laid out, and the layout is the interesting part for anyone who wants to change the bindings. The tools needed to generate wrapper code sit in the `Source/Tools` folder, the generated wrapper code itself is in `Source/Libs`, and the templates used to produce it are in `Source/Templates`. The build script is split between `build.cake` at the root and the `CakeScripts` folder. So the wrappers are not hand written objects that you are meant to edit in place; they are produced from templates by tools, and the place to make a change is a template or a tool, not the output. ## One NuGet package per wrapped library The packages published to NuGet are split along the same seams as the underlying C libraries, which is what lets an application take only the parts it needs. The list is GtkSharp, GdkSharp, GioSharp, GLibSharp, AtkSharp, PangoSharp, CairoSharp and GtkSourceSharp. In practice that means a project that only needs a window and a drawing surface does not have to drag in the accessibility layer, and one that works with a text editor buffer can depend on GtkSourceSharp without installing the rest. This is a deliberate difference from the single assembly approach, and it mirrors how the C libraries themselves are packaged. The wrapper set also corresponds directly to the component list in the introduction, glib, gio, cairo, pango, atk and gdk, with GtkSourceSharp added for the source view component and the templates, the tools and the samples living in the repository rather than on NuGet. ## A dotnet new template for starting an application For people who want to create a project rather than reference a library, the project ships a template for the dotnet new engine, and the three commands are the whole interface. Installing it is: ```bash dotnet new --install GtkSharp.Template.CSharp ``` Creating a project is a second command: ```bash dotnet new gtkapp ``` And the template is removed again with `dotnet new --uninstall GtkSharp.Template.CSharp`. The choice to publish this as a dotnet new template rather than as a sample in the repository is a small but telling detail, because it means a new application starts with the correct references to the right set of packages instead of the developer guessing which of the eight NuGet packages a GTK program needs. It also means the template has to be kept in step with the package versions, which is a maintenance obligation that sits with whoever maintains the repository rather than with the person using it. ## macOS still means installing GTK by hand The platform note is short and is a reminder that this is a binding to a native toolkit rather than a self contained UI framework. On macOS you need to install GTK manually, and the documentation points to a wiki page, Installing Gtk on Mac, for the details. There is no equivalent note for Linux, which is the platform where GTK is packaged by the distribution and where a .NET desktop application built on this binding is most likely to end up. The same note explains why the wrapper set includes the platform independent parts of the stack: GTK itself is the native layer, and everything above it in the list, glib, gio, cairo, pango, atk and gdk, is a C library that has to be present on the machine at run time, whatever language the application is written in. ## Version numbers, release dates and what they tell you The version numbers carry the GTK version with a build number attached, and the recent release list shows the same pattern: 3.24.24.34 and 3.24.24.32 on the same day in April 2021, and 3.24.24.4 in March 2021. So the 3.24 part tracks the GTK release the bindings were generated against, and the trailing numbers are builds of that generation. The published releases stop there, in 2021, which is a fact about the release feed rather than about the code, because the last push to the repository was on 2026-09-30 and the default branch is `develop`. In other words, work is still landing on the development branch while the tagged packages have not moved, which is the situation to plan around: if you need a package from NuGet, you are working with a 2021 generation, and if you want the current state you would build from source, which is why the build instructions are given with that prominence. ## Conclusion GtkSharp suits a .NET team that needs a native GTK interface on Linux or macOS and wants to target a current .NET rather than the Mono stack, and it suits a maintainer who wants the generator and the templates in the same tree so that the bindings can be regenerated when GTK moves. It is a poor fit for a Windows only shop, since GTK is a cross platform toolkit but this binding is a port of it rather than a Windows native stack, and it is a poor fit for a team that needs a stable package cadence, since the published versions stop in 2021. Before you adopt it, check three things: that your target framework can consume .NET Standard 2.0, that GTK itself is installed on the machines that will run your application, since the macOS instructions still tell you to install it by hand, and the licence split, where the library is under LGPL v2.0 while the samples under `Source/Samples` are released under The Unlicense. ## FAQ ### How do I build GtkSharp from source? With .NET 6 installed, clone the repository, then run `dotnet tool restore` and `dotnet cake build.cake`. The build script drives code generation, with the generator tools in `Source/Tools`, the templates in `Source/Templates` and the generated wrappers in `Source/Libs`. ### Which GTK version and .NET version does GtkSharp target? The comparison table in the documentation gives .NET Standard 2.0 and GTK 3.22 for GtkSharp, with a note that it does not need glue libraries, against .NET Framework 4.5 and GTK 2 for the Mono project it was forked from. ### Which NuGet packages does GtkSharp publish? One package per wrapped library: GtkSharp, GdkSharp, GioSharp, GLibSharp, AtkSharp, PangoSharp, CairoSharp and GtkSourceSharp. That lets an application take only the components it actually uses. ### How do I create a new GtkSharp project? Install the template with `dotnet new --install GtkSharp.Template.CSharp`, then create a project with `dotnet new gtkapp`. The template can be removed again with `dotnet new --uninstall GtkSharp.Template.CSharp`. ### What licence applies to GtkSharp and to its samples? GtkSharp and its related components are under the LGPL v2.0, with the text in the LICENSE file at the root of the repository, while the samples under `Source/Samples` are under The Unlicense with their own licence file in that folder. ## Sources - [GtkSharp/GtkSharp on GitHub](https://github.com/GtkSharp/GtkSharp) - [Issues](https://github.com/GtkSharp/GtkSharp/issues) - [README](https://github.com/GtkSharp/GtkSharp/blob/develop/README.md) - [Releases](https://github.com/GtkSharp/GtkSharp/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gtksharp-gtksharp