nanoframework/Home is the map you need before writing C# for a microcontroller

A landing repository with no library inside it

The first thing to understand about nanoframework/Home is what it is not. There is no package to install, no API to call and no assembly to reference. The README describes it as the starting point for developers who want to learn about .NET nanoFramework, contribute to it, or open issues, and says it contains links to the various GitHub repositories used by the project.

That makes it a map rather than a component, and it changes what you should expect from it. If you arrived searching for a driver class or a build script, this repository will not have one. The top-level entries confirm the shape: `.github/`, `.gitignore`, `CONTRIBUTORS.md`, `LICENSE.md`, `README.md`, `README.zh-cn.md`, `THIRD-PARTY-NOTICES.md`, `docs/`, `resources/` and `videos/`. There is no `src/` directory and no project file, because there is nothing to build.

There is a language detail worth noticing. Alongside the English README there is a Simplified Chinese one, and the README's language line points at both. The project is genuinely run by an international community, and a home repository that carries a translated README is a small signal of how actively that community is organised.

Six ways to contribute, from native drivers to unit tests

The README describes several developer profiles, and the list is more useful than it first appears because it maps directly onto the repositories this home page links to.

The deepest work is in C and C++, writing native drivers that operate on the micro-controller directly. The Platform Abstraction Layer and the Hardware Abstraction Layer sit at that level, as does the RTOS work and the development of the .NET CLR for nanoFramework. Below that sits managed C#, where the contributions are new classes and drivers, additional bindings and libraries.

A third group writes managed C# tooling: the Visual Studio Extensibility components, the debugger, and other applications that are mostly .NET Core or .NET 5 CLI programs. The remaining profiles are infrastructure and process: setting up Azure DevOps pipelines to automate as much as possible, writing and improving unit tests, answering other people's questions, and writing documentation, doing pull request reviews or helping with the overall project organisation.

That last group is the one that matters if you are not an embedded specialist. Documentation and test work on a project with this much low-level code is a real contribution, and the home repository is the place where that need is visible.

Reference board firmware: nanoBooter and nanoCLR images

The part of this repository you will actually download is firmware. Each ZIP file listed for a reference board contains the image files for nanoBooter and nanoCLR in several formats, HEX, BIN and DFU, and the README says they should be flashed to the target board using an appropriate software utility.

Two build variants are described, and the difference matters. The stable versions are continuous builds of the reference targets, which include the latest version of all features and bug corrections. They have managed debugging features enabled along with detailed error messages, but they exclude native debugging features and carry only minimal, or no, error messages.

If you need native debugging, the README points you at the nf-interpreter repository and tells you to build it locally. That is the practical boundary of this home repository: the images it publishes are for managed debugging, and the native debugging path requires a local build from a different repository.

The tables further down list the reference targets for which firmware images are published, but the README is explicit that the authoritative and always up to date list of supported targets lives in the nf-interpreter repository. If you are planning a product, that is the list to trust rather than a table in a README that changes when the repository changes.

Community boards are a separate repository with its own caveats

Beyond the reference targets, the README says you can find firmware images for community provided boards, and points at the Community Targets repo, nf-Community-Targets, for the available ones and their download links.

The distinction between a reference board and a community board is not cosmetic. Reference boards are maintained alongside the interpreter and are covered by the continuous stable builds. Community boards are contributed by people outside the core team, and the README does not describe what testing or maintenance guarantee applies to them. It lists the boards and the download links and stops there.

So for evaluation work the trade is clear. A reference target gives you a board the project builds continuously. A community target gives you hardware the project does not build, which is fine for a proof of concept and a different matter for something shipping to customers, where the flashing format and the driver set become your problem rather than the project's.

One more wrinkle for the hardware side: the ZIP files contain the images in HEX, BIN and DFU formats, and you need a matching software utility to flash them. The README does not name a specific flasher, so the utility depends on the board you are targeting.

Where the documentation, the community and the funding live

The home repository is also the entry point for everything around the project. Documentation is published at docs.nanoframework.net, and the contributing guidance, including the other ways to contribute beyond money, is at the contributing page under that site. The project itself is part of the .NET Foundation.

The community channel is a Discord server, and the repository carries badges for the OpenCollective backers and for the issue resolution and open issue counts. Sponsor logos and links are placed on the GitHub readme and on the project home page, which is the mechanism by which support is made visible.

Funding itself is described in detail, and the uses are specific: paying infrastructure costs, public relations work to get the project known, supporting maintainers and contributors who invest a lot of time in it, supporting the projects that .NET nanoFramework depends on, producing documentation and tutorials, and organizing demo events. The README also notes that much of the core work happens on people's free time, and that some core members work at companies that sponsor the project and offer their work hours to it.

Sponsors land on a Bronze tier with the others, and there is a separate acknowledgement section for people and organisations that contributed in other ways, including sponsoring the coding of a missing feature, paying an expense, or simply coding a feature. The ChibiOS and Eclo Solutions logos appear there among the acknowledged parties.

MIT licensed, no releases, and a repository that was pushed to a week ago

The licence field on the repository says MIT, and the top level carries both `LICENSE.md` and `THIRD-PARTY-NOTICES.md`. MIT is a permissive licence covering modification and redistribution, including inside commercial products, with the notice requirement being the part to keep intact. The third-party notices file exists because the firmware images bundle components from other projects. That is the reading of the identifiers rather than legal advice, and for a product that ships the firmware image, the notices file is the part to read carefully rather than skip.

There are no GitHub releases in this repository, which is consistent with its role. It is a landing page rather than a distributed artefact, so there is nothing to tag and publish. The last push was on 2026-10-12, so the links, the firmware tables and the contributing text are current.

The upgrade question for a nanoFramework user therefore lives in the component repositories, not here. When the firmware or the interpreter changes, you pull the new images from the tables in this README or build from nf-interpreter, and the version you are on is the version of the CLR image you flashed, not a version number of this repository.

Editorial conclusion

Start at nanoframework/Home if you are new to .NET nanoFramework, because it is where the reference board firmware images, the community target list and the repository map live, and where the contribution profiles make clear which kind of work fits you. Do not expect code or a package from it, since it holds no library, and do not use it as your dependency source, since each component is fetched from its own repository. Before flashing anything, download the stable firmware ZIP for your board from the tables in the README, confirm your board is a reference target, and read the licensing terms in LICENSE.md and THIRD-PARTY-NOTICES.md before shipping the image on a product.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nanoframework/Home on GitHub
4. Project website
5. README