SharpGL: an OpenGL binding for .NET that still targets .NET Framework

Five packages, and you only take the ones you need

SharpGL is made up of a number of packages, and the documentation is explicit that you install whichever ones you need. The package table in the README describes each one.

The SharpGL core package holds all OpenGL functions wrapped and ready to execute, as well as all the OpenGL extensions. The SharpGL.SceneGraph package is a full class library modelling key 3D entities. The SharpGL.Serialization package contains utilities to load data from Discreet, Wavefront and Caligari file formats. The SharpGL.WPF package includes the core plus OpenGL controls to drop into a WPF application, and the SharpGL.WinForms package does the same for WinForms.

The split is sensible because the cost is different in each case. The core is a thin binding layer and adds almost nothing to your output. The scene graph is a real object model with its own memory and its own update cost. The UI packages pull in a Windows desktop framework dependency, which is why they are separate assemblies rather than part of the core.

Installation is through NuGet, using the Package Explorer or the Package Manager tool, and the documented command is:

PM> Install-Package SharpGL

The project is MIT licensed, the primary language is C#, and the last push to the repository was on 2026-09-10 with the most recent tagged release being v3.1.2 from 2023-04-28.

The compatibility table is where the decision gets made

The compatibility section is the most useful part of the documentation, and it makes two separate statements about frameworks and platforms.

On the framework side, all components support .NET Framework 4.0 onwards, .NET Core 3.0 onwards and .NET Standard 2.1 onwards, with some components also supporting earlier versions. The per-component table refines that. The core, the scene graph and the serialization package are listed as .NET Framework 4.0+, .NET Core 2.0+ and .NET Standard 2.0+, while the WinForms and WPF packages are .NET Framework 4.0+, .NET Core 3.0+ and .NET Standard 2.1+. That difference is not cosmetic. A project targeting .NET Standard 2.0 can take the core and write its own rendering loop, but cannot take the UI packages.

On the platform side, compatibility is described as supported through framework specific components, and the table is short and blunt. WinForms on Microsoft Windows is supported via SharpGL.WinForms, and WPF on Microsoft Windows is supported via SharpGL.WPF. UWP on Microsoft Windows, Xamarin on Microsoft Windows, Xamarin on macOS and Xamarin on Linux are all marked as work in progress with a cross mark.

So this is a Windows desktop library, and the Xamarin rows being unfinished rather than absent is a statement about the past as much as the future. The project predates MAUI and has kept the Xamarin entries in the table as a record of intent.

The OpenGL surface has its own version statement. SharpGL has built-in bindings for OpenGL 4.0, and functions from later versions can be loaded at runtime as needed. That is a different model from a binding that stops at 4.0, and it is worth understanding before you write code against, say, a compute shader entry point.

The 2.x branch and what it is for

There is a legacy line and the documentation is clear about its status. The Visual Studio 2017 version of the codebase, which supports the .NET Framework only, is available on the release/2.x branch, and that branch will not be maintained going forwards. The current mainline still supports the .NET Framework.

That last clause is the one that surprises people. A project that has been on .NET Framework for a decade and is now moving to modern .NET has a choice to make, and the answer is that the mainline covers both. The core package targets .NET Standard 2.0 as well as .NET Framework 4.0, so a multi-targeted application can reference the same package on both.

The old branch is still there for a reason, which is usually a build environment that cannot be modernised. A Visual Studio 2017 toolchain, or a target framework that the current packages no longer support, is exactly the situation where the 2.x branch remains useful, and the fact that the documentation says it will not be maintained means you should plan a migration rather than settle in.

The sample projects follow the same structure. The README's table of contents lists WinForms samples covering drawing, extensions, hit testing, modern OpenGL, native textures, particle systems, polygon loading, radial rendering, render contexts, render triggers, the scene graph, textures, simple drawing, and a duck-themed sample, plus WPF samples for cel shading, drawing mechanisms, an object loading sample, a simple shader sample, a teapot sample, text rendering and two-dimensional rendering. There is also a FastGL WPF sample and a Visual Studio extensions package for project templates.

Building the source and the developer workflow

To build the code you clone the repository and open one of three solutions, and the split mirrors the package layout. The SharpGL solution is the core library, the Samples solution holds the sample applications, and the Tools solution is the utilities. The Extensions solution is separate, used for the Visual Studio Project Templates, and it requires additional components, with the wiki page on developing SharpGL as the reference.

There are also scripts to run the processes, listed in a table with notes for each. The config.ps1 script ensures the machine can run builds by installing necessary components such as nunit, and the documentation says it should only need to be run once. The build.ps1 script builds the code.

The project carries a continuous integration workflow badge on the main branch, a codecov badge, and a GuardRails badge for dependency analysis, which is a slightly unusual mix of signals for a graphics library. The GuardRails badge in particular suggests the dependency surface is being watched for known vulnerabilities, which matters for a package that sits in every WPF application that renders 3D.

The library is described as giving .NET applications access to the power of OpenGL, with helpful wrappers for advanced objects such as Vertex Buffer Arrays and shaders, plus the scene graph and utility library. The samples are the recommended way to learn it, and the wiki carries the samples collection.

Where SharpGL is the wrong choice

The first limitation is platform, and it is the one that decides the question for most teams today. A library that renders through WinForms or WPF controls is a Windows library, and the table marks UWP and all three Xamarin targets as work in progress. For a team that needs macOS or Linux, the options are a different binding, or a native interop layer, or a cross-platform engine, and none of those is what this package is.

The second is that OpenGL is not where the platform went. A Windows desktop application in 2026 that wants hardware accelerated graphics has Direct3D and the Direct3D interop path through the .NET graphics stack, and WPF has had a supported Direct3D route for years. Choosing an OpenGL binding means choosing a rendering API on a platform where the vendor path is the better supported one, and you inherit the driver quirks that come with that.

The third is the release cadence. The last tagged version is v3.1.2 from April 2023, before which came v2.4.5 in June 2020 and v2.4.4 in May 2020, so the 3.x line has had one patch release in more than three years while the repository itself was pushed to in September 2026. That combination usually means the code is stable and the author is not actively adding to it. For a library whose surface is essentially a binding of a fixed external API, that can be perfectly fine, and for anything expecting new OpenGL features to be wrapped, it is not.

The comparison to writing the interop yourself is the honest one. A binding layer for a C API is not conceptually hard, and the value SharpGL adds is the sheer size of the surface, the extension handling, the scene graph and the model loading. If you need a handful of calls, a small set of hand-written P/Invoke declarations may serve you better and carries no dependency. If you need the whole thing, this is a mature and well-documented option, and the samples make it approachable.

Editorial conclusion

SharpGL fits a Windows desktop developer on .NET Framework or WPF who needs OpenGL without writing P/Invoke declarations by hand, and who is willing to work against the OpenGL 4.0 surface with later entry points loaded at runtime. It does not fit a cross-platform project, since the documented platform support is Windows only with UWP and Xamarin marked as work in progress. Before adopting it, check which framework target you actually need against the compatibility table, since the WinForms and WPF packages differ from the core ones, and note that the last tagged release is v3.1.2 from April 2023, so the library is stable but not actively moving.

Frequently asked questions

Official sources

1. dwmkerr/sharpgl on GitHub
2. Issues
3. License: MIT
4. README
5. Releases