In-field update [WIP]

New features and bug fixes are bread and butter in the software industry and embedded systems are no exception. These are made available in releases, which all need to be published and deployed. Quite often, the last step is the most challenging of all given that the capabilities and available resources of the device subjected to the update process decrease, the difficulty increases inversely.

To be fair, it is not usually a big deal when you have the device sitting on your desktop bench, connected to a cable and just need to type into a command line tool to get the new imaged flashed, or (even better!) using a GUI tool.

But what about when you have the device sitting in a hard to reach (remote) location? Or when there are a bunch of them spread geographically apart? Or devices that maybe using a spotty and/or intermittent network connection. Or even not connected at all because there is no network available or it is too expensive. And what happens if the update process hangs? Or if there is a power glitch? Or if the image gets corrupted? There are a thousand ways that can make remote updates on micro-controller scenarios head south…

Nevertheless, being able to remotely update a device deployed in the field is a feature that most likely will be high placed on the “must-have-feature-list” of a company evaluating an embedded system framework.

Currently .NET nanoFramework is missing this feature, but that is about to change!

The specification and design of the in-field update (that’s what we’ll be calling it because the update can reach the target device not only over the air, but though a wired connection or a storage device) is mature and closed, ready to be coded.

Despite being what could be easily classified as a premium feature, it will be (just like everything else in nanoFramework) made available to everyone for free, in full.

Being a high value and commercially relevant feature, it’s more than fair that especially commercial users, contribute monetarily to the development effort. For this purpose, a sponsoring campaign is being launched through GitHub Sponsors program here.

Feel free to jump into the conversation about this topic, ask questions, get updates, and provide feedback. All that will be happening in the #in-field-update channel at the .NET nanoFramework Discord community.

Custom attributes with constructor

Yes, you read that correctly!

nanoFramework just got support for these. You can now have custom attributes with a constructor and access the value on the constructor.

Let’s see some code to illustrate this.

Consider these two classes defining attributes.

public class AuthorAttribute : Attribute
    private readonly string _author;
    public string Author => _author;
    public AuthorAttribute(string author)
        _author = author;
public class MaxAttribute : Attribute
    private readonly uint _max;
    public uint Max  => _max;
    public MaxAttribute(uint m)
        _max = m;

Now a class using the above attributes on a given field.

public class MyClass1
    public void MyMethod1(int i)
    [Ignore("I'm ignoring you!")]
    public void MyMethodToIgnore()
    private readonly int _myField;
    [Ignore("I'm ignoring you!")]
    public int MyField => _myField;
    [Author("William Shakespeare")]
    public int MyPackedField;

And finally reaching those attributes.

var myClass = new MyClass1();

var myFieldAttributes = myClass.GetType().GetField("MyPackedField").GetCustomAttributes(true);
Debug.WriteLine($"\nThe custom attributes of field 'MyPackedField' are:");

MaxAttribute attMax = (MaxAttribute)myFieldAttributes[0];
Debug.WriteLine($"MaxAttribute value is: 0x{attMax.Max.ToString("X8")}");

AuthorAttribute attAuthor = (AuthorAttribute)myFieldAttributes[1];
Debug.WriteLine($"AuthorAttribute value is: '{attAuthor.Author}'");

The above code will output something like this:

The custom attributes of field 'MyPackedField' are:
MaxAttribute value is: 0xDEADBEEF
AuthorAttribute value is: 'William Shakespeare'

Looks pretty simple and trivial doesn’t it? And can be very useful too!
Get the full project on our samples repo here.

And what are you waiting for? Go write some code and have fun with nanoFramework! 🙂

PS: make sure you join our lively Discord community and follow us on Twitter.

nanoFramework ready hardware?

A quick blog post about a survey we are conducting about nanoFramework ready hardware.

We get it that there is already a bunch of hardware out there that one can choose to start with or develop an embedded systems project on top of. But we’ve been giving this some thought internally and we are inclined to believe that we can add something to this. Moreover, having readily available hardware that includes dedicated nanoFramework support and continuously up to date images ready to flash on the devices would be something positive for the project.

Right now we are just evaluating this. No promises. 🙂

It would be very helpful if you could spare 5 minutes of you time and let us know your thoughts about this.

You can find the survey here.


nanoFramework v1.0 is official!

Today we are proudly announcing the first official release of nanoFramework.

What a journey we’ve made… for over two years now a lot of code has been written, tested, and rewritten. A lot of ideas were discussed, tested, reviewed, implemented and even scraped. We won’t bother you with statistics on the number of commits or code lines as these are in plain sight within the repos. All in all, we have a lot to be proud off, including:

  • Working and usable images for 14 targets (STM32 ARM Cortex-M and ESP32 SoC).
  • A Visual Studio extension providing device management, project system and debugging capabilities.
  • NuGet packages with the various class libraries making it very easy for developers to consume and update their projects.
  • A fully automated CI and CD pipeline for all of our repositories.
  • A modular approach to our GitHub organization with a collection of 30 repositories.
  • A set of software utilities that make developers life easier.
  • A working support system based on GitHub issues.
  • A fully fledged and ever improving amount of documentation available online.
  • A friendly and thriving Discord community where developers can ask for help, assist other fellow developers, make suggestions, chime in on discussions about future developments and interact with other developers.
  • A Website, YouTube channel and Twitter account.
  • A platform hub on to showcase projects.

What exactly does this official release mean? That we are done? Not even close. We are just getting started!!

This is more like a mandatory milestone that’s kind of expected by any project in order to move forward. So this is it!

There is still a lot to come and nanoFramework is poised to grow at the same rapid pace as we have always strived for.

We are expecting that more people get to know and embrace the framework. That companies start to look at us and seriously consider nanoFramework a viable option when they are choosing a framework for their next embedded project.

There is our roadmap, or should we say, to-do list organized in our GitHub organization projects.

What is expected in terms of releases? Our current plan is to follow a continuous integration and continuous delivery strategy, meaning that you’ll see frequent releases. Not so much bound to a certain cadence but rather to usefulness and opportunity. Whenever it’s a good time to release we’ll kick another one.

Wrapping it up: it’s been fun so far and it’s our belief that nanoFramework has fulfilled (most) of the initial plan and expectations.
It would be great to see more people contributing, not only by coding but posting projects, working on examples, writing documentation, and answering questions from other developers… all that would be expected to happen in a thriving and prosperous Open Source project as we are.

nanoFramework: live long and prosper!

Obfuscation? We have an app for that!

If you are in the .NET world for long enough, you’ve probably have come across with the term obfuscation at some point.

In a nutshell and paraphrasing Garry Trinder: “is the process of scrambling the symbols, code, and data of a program to prevent reverse engineering.”

As most of us are aware there are several tools available to decompile a .NET assembly and expose the code inside. nanoFramework assemblies, being .NET, are no exception.

Why is this a concern? Well, if you are a company and own IP that you don’t what to share publicly (for example a super-secret algorithm that took you years to fine tune) this could be of interest to you.

The main purpose of an obfuscator is precisely… obfuscating… the code so that it makes unreadable or at least very hard to understand. There are several techniques on how to accomplish this and some are more effective than others.
Just to name a few: symbols renaming, overloaded renaming, cross assembly renaming, inline value and array encryption, control flow obfuscation, resource encryption. But that’s enough as these details are beyond the subject of this blog post. Check the pictures bellow so you can have an idea on how this looks.

Before After
obfuscation_before obfuscation_after

We’ve worked together with the good folks of babelfor.NET to add support for nanoFramework on their .NET obfuscation product: Babel Obfuscator. Early this week v9.0 of this tool was released being the first (and only!) obfuscation tool supporting nanoFramework.

So, if you have a commercial interest in nanoFramework and sharing your IP was preventing you from moving forward, you don’t have an excuse any more!

We are moving our chat to Discord

After many discussions we’ve decided it is within the best interest of the project to move our chat platform from Slack to Discord.

Why are we doing this? Since initiating the project we’ve been using Slack, which has proved more than adequate for the task at hand. However, Slack uses a freemium model, which is fine but the free plan is limited to only the last 10k messages, 5 service integrations and an unmentioned limit on the number of users!

All these might not seem a big deal, especially for a small team or project, but they have started to affect us in a negative manner as our user base and message traffic has grown. For quite some time now we are losing critical knowledge every day that goes by as we have reached the 10k limit for a long time. Every time anyone sends a message (no matter how big or small) the 9.999th one gets lost in cyber space. At the time of writing there were 36k messages lost!

The search history is also limited by that number and it is not feasible to collect messages before they are lost and provide a search tool for such an archive.

Upgrading to a paid plan at a cost of 7.25 USD per user is simply not economically viable for this project, or for that matter, any Open Source project (but this is just my humble opinion).

Considering that we are keen to maintain a chat-like experience(*) for our community (which has proved a great option) we started looking at other similar platforms.

From all the alternatives that were considered (and presented to the community members for voicing their opinion) Discord seemed the best available alternative.

It’s free (really free it seems!); has no limits on users or message history; provides chat and voice messages; it’s hosted on secure servers; has a tremendous user base which proves their claims on responsiveness and robustness; allows integrations with our own bots and has a bunch of client apps for all the major platforms.

So here we go: farewell Slack, long live Discord! Join the community.

Important links:
Client apps all the major platforms
Windows 10 UWP apps (MobileDiscord and Quarrel seem to be the best ones)

(*) Being chat-like experience the opposed to a traditional forum-like experience that feels too static and slow to the modern standard.

Debugging a visual studio extension

Although it has got easier over the years, debugging Visual Studio extensions is generally thought of as a dark art, this blog post is aimed at those people who wish get started. Specifically it is aimed at debugging the nanoFramework Visual Studio extension which will help us (with the aid of all willing volunteers) to improve the reliability of it.


Step 1. Ensure the Visual Studio Extension Development workflow is installed in VS2017:

This can be checked by running the “Visual Studio Installer” clicking Modify and scrolling to “Other Toolsets”

VS Extension Workflow 1

If the box is not ticked, please tick it and then click the “Modify” button in the bottom right corner. Depending on the workflows already installed, this modification will install quite quickly.


Step 2. Make sure that the Visual Studio 2017 nuget package source includes the MyGet feed for nanoFramework preview releases:

Open Visual Studio 2017 and browse to [Tools -> Nuget Package Manager -> Package Management Settings]

VS Extension Workflow 2

Click on Package Sources and then add a new package source by clicking the [+] button in the top right. You will then want to give the source an appropriate name such as “myget-nanoframework” and add the source ““.

VS Extension Workflow 3

Finally click [Update] and then [OK]


Step 3. Clone the nf-Visual-Studio-extension Repo from GitHub:

Tip: if you wish to contribute and submit Pull Requests, it is more convenient to Fork the nf-Visual-Studio-extension Repo to your own GitHub account and Clone from there.

In your browser of choice, visit and perform a clone choosing the appropriate method. In this example we will use the Visual Studio workflow.

VS Extension Workflow 4

Note: if you have multiple versions of Visual Studio installed, you maybe asked which version to open. It is best to choose VS2017.

From the displayed Team Explorer window, change the install location (if required), and ensure the [Recursively Clone Submodules] option is checked

VS Extension Workflow 5

Then click clone.


Step 4. Open and Build the solution

From Team Explorer Home, open nanoFramework.Tools.VisualStudio.sln

VS Extension Workflow 6

Ensure [Debug] and [Any CPU] are selected and then click [Start]

VS Extension Workflow 7

This will first compile the source and then it will load an experimental instance of Visual Studio in addition to the one currently open.

Optimisation: to improve the performance of the debug session, it is now possible to run experimental instance from the command line which can improve performance. A guide to doing this can be found here


Step 5: Debugging the extension:

Note: you should now ensure you have switched to the Experimental Instance for the rest of the guide.

A window will now pop up warning you that a release version of a DLL is being used

VS Extension Workflow 8

This is expected because the project is referencing the debugger library provided by the Nuget package. Click the [Continue Debugging] on the window.

Note: if you need to step into the code of the debugger library, you will have to switch from the Nuget package to the local copy of the debugger project in the solution, to do this you can use Nuget Package Switcher.

If the Device Explorer tool window is not present on the left of Visual Studio, Browse to [View -> Other Windows -> Device Explorer]

VS Extension Workflow 10

You should now use Visual Studio and the nanoFramework extension as you would.

VS Extension Workflow 9

If you find any exceptions or lockups, please provide the debug info from the Visual Studio instance running in the background to our issues log.

And that’s it! Easy as pie, in fact the hardest part was probably the wait… So there are no excuses for saying that debugging a Visual Studio extension (including nanoFramework’s) is too difficult!

Build, build, build…

Here’s a quick overview on one of the key aspects of any software project: the build. nanoFramework is no different and we all know how critical this is, so we’ve put a lot of attention and care on this matter.

The goal was to make it highly configurable (because there are a lot of features and components that a developer may want to include or leave out of a particular image) and, of course, being very easy to setup.

The choice was to use CMake a well-known and proven build system (available for Windows, Linux and MAC).

Another reason for it is that are a couple of nice extensions that make it very easy to work with CMake on VS Code. Why is this relevant? Well, because we’ve been using VS Code as the official IDE for developing the native side of nanoFramework.

The only pre-requisites for running a build are the GNU ARM Embedded Toolchain and CMake.

There is a document in our GitHub repo detailing all this: how to setup it up and how to start the build.

To prove that this is really easy (and that it works!) know that even a machine can do it. Yes, that’s true! 😉

As part of our QA and DevOps each pull request commit and merge commit into the master branch goes through an automated process that builds the image for each of the reference target boards. Only after an “all green” condition the commit is merged or accepted. We are using Travis CI for running these automated builds (a big “thank you” for the folks at Travis CI for providing free accounts for Open Source projects).

To make my point here (about how easy it to setup and run the build) let’s take a brief look on what happens on each of those builds:

  1. Travis CI spins up a virtual machine with a clean image of Ubuntu
  2. GNU ARM Embedded Toolchain is installed
  3. CMake package is installed
  4. nanoFramework sources are pulled from GitHub
  5. ChibiOS sources are pulled from GitHub
  6. A build starts for each of the reference target boards

See? If a machine can do it so can a human. 🙂

The same can be done “manually” right from VS Code. We’ve tried to make that very easy by providing templates for the configuration files required by the CMake Tools extension.

So, after this (and if you haven’t done it already) what are waiting? Go and setup your machine to run a nanoFramework build. Next, who knows, you’ll be making your way into the code and submit some pull requests…

I’m Framework, nanoFramework

You’re probably thinking: “what the heck is nanoFramework?”

Our vision for it is to be a platform that enables the writing of managed code applications for constrained embedded devices. Developers can harness a familiar IDE such as Visual Studio and their .NET (C#) knowledge to quickly write applications without having to worry about the low level hardware intricacies of a microcontroller.

Now you are probably thinking: “hum… this sounds familiar… isn’t there already a framework like this?”
Well, you are correct! There is one: the .NET Micro Framework (NETMF).

Your next – probably – obvious question would be: “if there is already one, why are you doing this? Don’t you have better things to do with your time?”

On this, we beg to differ… 🙂

NETMF was a great move from Microsoft to bring the ease and simplicity of managed .NET coding (C#) to the embedded world. The potential of this concept was (and still is) incredible and immensely powerful!
It started as a closed source, licensed product and later it moved to an open source model with a CodePlex repository.
Along it’s journey NETMF began to receive less and less love from Microsoft until it reached the point of being completely abandoned. The community around it was never what we would call a strong and thriving one. Along the way several attempts were made to revive the project and put it under the community management. Unfortunately without success…

Given this, nanoFramework emerges from the combination of several aspects:

  • The frustration of seeing the incredible potential of NETMF misunderstood.
  • Contemplating the waste of work and effort over many years by letting NETMF stay abandoned.
  • The firm belief in the concept and how it can fulfil such a vast amount of use case/scenarios such as: a learning platform, rapid prototyping system or even a fully fledged framework capable of powering a commercial product.

A group of like minded people gathered around these ideas and decided to take the matter into their own hands. We started by shaping our vision for it should look like and what would be the ideal experience for working with and developing using it. We Identified what the short-comings of NETMF were and what aspects were worth keeping or should be improved. We then drafted a plan of action before rolling up our sleeves and started testing ideas and validating proof of concepts.

Without trying to be exhaustive here’s our initial “whish list” for nanoFramework:

  • a decent and working build system
  • improved PAL (Platform Abstraction Layer)
  • easy porting process
  • ability to go through the full development cycle for native code
  • leveraging an existing RTOS for embedded systems
  • core code hardware agnostic and to ease port
  • easy process for developing a nanoFramework board (NETMF Solution)
  • architected to make it easy to add new features
  • provide enough documentation to allow newcomers and veterans to understand the code and the design decisions behind it

We are currently making all this to happen by:

  • working on a revised CLR (Common Language Runtime) and interpreter
  • working on a build system based on CMake (proof of concept already validated)
  • working on a reference implementation based in ChibiOS (proof of concept already validated)
  • providing a full development cycle experience (coding to debug, including build) without leaving VS Code (freely available)

The goal is to have a minimal working nanoFramework in the coming weeks. This will allow to accomplish two objectives:

  1. To show a working example that fully validates the approach.
  2. To reach a point were any willing person can start contributing code and other work.

We would very much like to be able to create a thriving community around this project! There are a lot of ways that one can contribute to the project and coding is not the only one. Writing documentation, reporting issues and bugs, testing features, making suggestions, working on the web site and many others are just as valuable to us. Even just mentioning/promoting nanoFramework on social networks/forums can help towards improving the visibility of the project, so please, spread the word!

Feel free to take a look at our GitHub repo and/or join the Slack community here.

Welcome to nanoFramework and looking forward to your contributions!