dotnet/iot: the GPIO and device binding layer under .NET

Two packages, one hardware abstraction layer

The dotnet/iot repository publishes two NuGet packages. `System.Device.Gpio` is the low-level layer, an abstraction over GPIO pins with implementations for boards including the Raspberry Pi and the Hummingboard. `Iot.Device.Bindings` sits on top and is the growing set of device bindings for individual components, maintained largely by the community.

The repository is MIT licensed, written in C#, has around 2,400 stars and 630 forks, with `main` as the default branch and the last push on 2026-09-24. The README marks the whole thing as experimental and says all APIs are subject to change, which is a notable thing for a Microsoft-maintained library to still be saying.

Both packages cross-target .NET Standard 2.0, .NET Core 3.1 and .NET 6.0, so they can be consumed from any project targeting .NET Core 2.0 or higher, and also from .NET Framework or Mono. Sample projects target the latest stable .NET version instead.

Install from NuGet or track the nightly feed

The normal installation path is a package reference from Visual Studio, searching for `System.Device.Gpio` and `Iot.Device.Bindings`. The less normal path is the nightly feed, which publishes automatically from the latest commits to `main` and needs no authentication.

# Add the Azure DevOps nightly feed (no authentication required)
dotnet nuget add source --name dotnet-iot-nightly "https://pkgs.dev.azure.com/dotnet/IoT/_packaging/nightly_iot_builds/nuget/v3/index.json"

# Install packages
dotnet add package System.Device.Gpio --source dotnet-iot-nightly --prerelease
dotnet add package Iot.Device.Bindings --source dotnet-iot-nightly --prerelease
dotnet add package Iot.Device.Bindings.SkiaSharpAdapter --source dotnet-iot-nightly --prerelease

Three packages come from that feed, the third being the SkiaSharp adapter for drawing to displays. The feed can also be declared in `NuGet.config` instead, which is the better route for a repository where every developer should see the same sources.

<packageSources>
  <add key="dotnet-iot-nightly" value="https://pkgs.dev.azure.com/dotnet/IoT/_packaging/nightly_iot_builds/nuget/v3/index.json" />
</packageSources>

The README also carries an official build status badge pointing at Azure DevOps, so the CI state of `main` is visible from the README itself.

Hardware independence as a deliberate design goal

Most bindings target specific hardware: LCD character displays, DHT temperature sensors, single-board computers through `RaspberryPiBoard.cs`, and Arduino microcontrollers. The library itself tries to stay as hardware-independent as possible, and the README makes a point of the bindings that exist purely to show the interfaces working on a normal desktop.

The examples given are a keyboard GPIO driver and a CPU temperature sensor under HardwareMonitor. Both exist so you can read a pin or read a temperature without buying anything. An Arduino Uno is named as the cheap alternative if you want real hardware and do not want to spend much.

That framing answers the question people actually have, which is whether they can learn this without a parts bin. They can, and the sample list in the repository shows the shape of a normal first project: led-blink, led-blink-multiple, led-more-blinking-lights, led-animate, led-shift-register, led-matrix-weather, force-sensitive-resistor, serialport-arduino, an M5Stack remote display and a bmp280 sensor publishing to Azure IoT Hub. Every binding directory under `src/devices` carries its own `samples` folder.

Where this repository stops and nanoFramework begins

The single most useful line in the README for anyone choosing a stack is the one about microcontrollers. If you want MCU support, it says, look at .NET nanoFramework. That is a separate repository and a different execution model, and it is the honest boundary of this one.

Everything here assumes a Linux-capable single-board computer with a full .NET runtime available. GPIO access goes through the operating system, and the driver work visible in the release notes is OS driver work. Version 4.1.0 improved the TCA955x expander driver, added block GPIO access to it, made the address check optional so the driver could be used with other chips, and documented a problem with libgpiod versions at or below 1.0. That is the level at which the abstraction meets reality.

Version 4.2.0, published 2026-03-26, took LibGpiodV2 out of experimental, fixed the pullup and pulldown settings in that driver, fixed an uninitialised output cache in the TCA95xx driver, and added a binding for the Ina236 current and power monitor. A version bump to 4.2.0 also went hand in hand with ArduinoCsCompiler to 1.2.0 and a global LangVersion of 12.0, which tells you the Arduino path is a supported part of the tree rather than an afterthought.

Sensors, displays and a from-scratch web service tutorial

The bindings catalogue is organised by component type, and the README links straight into several of them. Character LCDs, DHT11 and DHT22 temperature sensors, the Raspberry Pi board class and the Arduino bindings all have their own paths under `src/devices`.

The samples directory is more interesting than a list of blink examples, because two of the projects go past hardware into services. One reads a bmp280 pressure and temperature sensor and publishes to Azure IoT Hub, which is the shape of a real deployment. The other is an M5Stack remote display, which suggests display output driven from C# rather than from a bundled tool. There is also a device binding template document, so writing a new driver starts from a scaffold rather than from nothing.

One complete third-party walkthrough is linked as well: a web service using SenseHat by Dawid Borycki, published in MSDN Magazine in August 2019. For a library whose bindings have grown organically through community contributions, one full outside tutorial is worth more than another internal example.

Documentation, contribution rules and the samples version trap

The README is a directory page with a rule attached to it. Official docs, API reference, Microsoft Learn modules, two video series, hardware documentation, samples and a roadmap are all linked in one block, and every binding directory has its own samples folder.

The rule is the important part. Make sure you use a tag that corresponds to your package version when browsing and reusing sample code, because the `main` branch is always the newest code and may not have been released to a package yet. If you are on the 1.2 package, select the 1.2 tag. An image in the documentation walks through picking the right branch.

Contributions are directed in four directions: improving drivers for supported boards, adding implementations for more boards, adding bindings for sensors, chips and displays, and filing an issue when a binding or protocol you need does not exist. Building the repository and adding a binding are covered in a separate Contributing document. The CI story has both an Azure pipeline and, since v4.1.0, a GitHub Actions workflow that publishes the nightly packages.

Editorial conclusion

This repository is the unglamorous layer that makes C# usable on a Raspberry Pi: a GPIO abstraction with libgpiod backing and a large catalogue of device bindings maintained largely by the community. What it does not do is run on a microcontroller. The README points anyone after MCU work at .NET nanoFramework instead, which is a different runtime with a different model, and that split is the first thing to understand before choosing a stack. On a single-board computer the library is a good fit, because the full .NET runtime is already there and the bindings cover exactly the sensors and displays people buy. Version 4.2.0 is the current line, LibGpiodV2 is out of experimental, and the nightly feed gives you a build from any commit on `main` if you want to try a driver fix before it ships.

Frequently asked questions

Official sources

1. dotnet/iot on GitHub
2. Issues
3. License: MIT
4. README
5. Releases