Unit Test Framework? Yes, we have that too.

Today, I am extremely excite to announce that we have just released the initial version of our Unit Test framework! Yes, Unit Test, like in… Unit Tests! Because it is powered by Visual Studio Test Platform, you’ll find the attributes that you’re used to decorate your test classes. Neat!

I believe you will find this familiar:

Such as this:

And, of course, this one too:

Knowing how important this can be for developers serious about Quality Assurance, this was high on our concern list from the beginning of the project. The initial effort on this, dates to October 2018. Back then, we were stopped in our tracks because of the lack of extensibility support of the VS Test platform. There was only VS2017 and we were told by the good folks in the VSTest team that what we were trying to accomplish would be possible with the coming VS 2019. So, we put this project on halt.

Time is always an issue, and this is no different! Up until now there was no one on the team or on the community that was up to it. A couple of weeks ago that changed: Laurent Ellerbach (who has been a great friend of the project) and has made several relevant code contributions, revisited this, and picked it up from where it was left.

Updating it from the old MS Test framework version was the first step. Then bring in VS 2019 and after that the real fun begun!

As with many other aspects in the .NET ecosystem, from NuGet to the VS Project system, we often bump into hard walls because .NET nanoFramework does not have a Target Framework Moniker, and there’s a limit to what we can “hijack” from the existing tools. Fortunately, enough the VS Test platform extensibility is extremely well designed and it’s usable for us.

That does not necessarily mean that this was a walk in the park! No sir. There was still A LOT of plumbing and workarounds that had to be implemented. But, in the end, we have made it and the Unit Test framework is real and ready to be used!

As usual, simplicity is the key here. To use this feature, one just has to reference the respective NuGet package:

Hit build and go to the Test Explorer window to see the magic happen (and let me assure you that seeing this in action does look like magic)!

The next steps are to add this to all our class libraries so we can improve another notch the project global quality.

Now that we have this freaking awesome tool, next on the queue for the Test framework are integration tests. Yes, you read it well, we will be able to plug into a real target, deploy something from the build pipeline, run unit tests and collect back the results.

We have prepared a sample project to demo this. You can find it are our sample repo here.

Feedback is welcome along with constructive comments and, of course, Pull Requests! (we love Pull Requests).

New preview feeds for nanoFramework!

Until now nanoFramework has been using MyGet as its NuGet feed provider to host preview and test packages.

MyGet is a decent provider but only offers 100MB storage on their free trier. Actually they offer 2GB to OSS projects (which is great) and for which we’ve applied, but it turns out that setting up the account for the OSS offer is an absolute pain! After more than two weeks and dozens of emails exchanged with their support we’ve decided to just move.

We already run most of our infrastructure on Azure DevOps and support for public feeds in Azure Artifacts were recently announced at Microsoft Build 2019. This has support for NuGet packages and the offer includes 2GB of storage. Considering all this, we’ve decided to move everything there.

How does this impact you as a C# developer consuming NuGet packages? Not much! It’s only a matter of editing the NuGet package source in visual studio to point to the new feed and you’re done.

The URL for the new feed is:


This impacts the VS extension preview versions too. We are now publishing those on the Open Vsix Gallery. Likewise, if you are eager to get the latest and greatest, and you’re already subscribed to the preview feed, you have to update the URL to:


For a detailed description on how to setup all this in Visual Studio, please read the earlier blog post here.

Have fun with nanoFramework!

nanoFirmawareFlasher is here!

The nanoFramework toolbox just got a new addition: nanoFramework Firmware Flasher.

This new tool is a CLI provided as a .NET Core Global Tool.

And why is this so special you may ask!

A .NET Core Global Tool is a special NuGet package that contains a console application. It gets installed on the developer’s machine in the default location and is made globally available in the command prompt.

The install is made with a simple call to the dotnet CLI and updates are provided through NuGet (just like any other NuGet package we are used to).

Check out how easy it is to install:

dotnet tool install -g nanoFirmwareFlasher

How cool is that! 😊

It supports targets for both ESP32 and STM32 platforms (the remaining ones will be added shortly).

Now, let’s drill down into the tool functionalities.

With it, one can update the firmware image right from the official Bintray repositories. This is valid for all development, stable and community targets. The fw version can be specified, or the latest available package can be used. Just like this:

nanoff --update --platform esp32 --serialport COM31

Along with the firmware package that includes both the nanoCLR and nanoBooter (except for ESP32 targets that have their own bootloader) it can also include a deployment package (C# program). This means that the full programming of a device can be easily be accomplished for example in a production environment. Because this is a CLI tool, the full process can be completely automated!

It also allows the backing up the deployment area for ESP32 targets (support for other platforms will be added).

Restoring a deployment image is also possible for all targets.

Specifically for STM32 targets, it works with both JTAG and DFU connected devices. One can even list the connected devices on any of these options. Again, this can be handy for production environments.

As usual let us know if you find any glitches and what features you’re missing.

If you haven’t done so, make sure you join our Discord community and follow us on Twitter.

Have fun with nanoFramework!

PS: we are “hiring”! If you like to develop for embedded systems join our team.

NuGet, assembly and native versions

nanoFramework C# class libraries are distributed as NuGet packages to be consumed by projects. This has been like this since day one. NuGet packages are practical, easy to distribute, easy to consume, easy to update.

But they had a …minor… problem. Actually, make that two… 😉

One was that the dependency between the managed assembly version and the corresponding version of the native end. The initial approach on this (inherited from .NETMF) was that the native version numbering had to follow the managed version. The main reason being that, at deployment time, there is the need to check if the device has support for what is about to be deployed to it. Nothing against this check that is perfectly reasonable. But – and this is a big but – this check is too strict. A detailed explanation on this has already been provided in this other blog post. Basically, what happened was this: even if the native code hadn’t any change whatsoever, it was forced to “change” just because the version had to bump in order to follow the managed one. This led to a consequence that is kind of severe in our context: forces to update the firmware on the target devices, which is something to be avoided at all costs!

This was improved a few weeks ago with the addition of the AssemblyNativeVersion attribute to our class libraries. This attribute is there to decouple the version numbers in the managed assembly and the native implementation. With it, the check on the required version on the target device at deployment time is possible and, by decoupling it from the managed version, made it possible to keep improving and changing the manged assembly as needed without forcing the native one to follow. Only when there is a real need to change the native part it’s version will have to be bumped

The second problem was that, because of that strict versioning dependency, whenever the version of an assembly changed all the dependent ones had to follow. The consequence is that this required massive and cascading updates that are time consuming and force everyone and everything to follow upon. If the version of mscorlib changed, guess what? All other class libs had to change along just to follow it!!

This too has been improved. Because of all the above, there is no need for this strict dependency anymore. The native versions have been bumped to a high number to make it clear to developers that the versions do not need to be matched. So, please, no more attempts to match these, OK?

Along with this, the NuGets have been updated too and the dependencies are not strict versions anymore. Check bellow what is showing in Visual Studio package manager for a NuGet package before and after.

Another improvement in the NuGets is that the required native version is now showing on the NuGet description. Making this visible removes the obscurity behind it and this can be checked visually and programmatically.

This native version is what the target device has to have support for. The native version available can be checked in the Device Explorer in Visual Studio. Bellow you can see the device capabilities of a target that has support for the above NuGet.

Every class library is now free from this slave dependency and, from now on, will have its version bumped only when there is a real need to.

The outcome of all this is that now we can start dealing with nanoFramework NuGets like we usually do with any other NuGet package: consume as needed and update when needed, not because we are forced to.

Trust all this will make everyone’s life easier and remove a lot of the friction that was around nanoFramework NuGets.

Have fun! 🙂

To deploy, or not to deploy, that’s the question…

nanoFramework class libraries are composed of a managed part (written in C#) and the respective counterpart (written in C/C++) that is part of the firmware image that runs on the target.

As part of the usual development cycle there are improvements, bug fixes and changes. Some of those touch only the managed part, others only the native and others both. If the interface between them is not in sync: bad things happen.

In an effort to improve code quality and make developer’s life easier, two mechanisms have been implemented along the way. One was to have version numbers on both parts (that have to match) and the another was an improvement introduced on the deployment workflow that checks if the versions of the assemblies being deployed match the ones available in the target device. Pretty simple and straightforward, right?

Despite the simplicity of the mechanism, it has some draw backs. Occasionally it gets confusing because of apparent version mismatches caused by the fact that the develop branch is being constantly updated and the versions are bumped. Also, because the preview versions of the NuGet packages are always available in nanoFramework MyGet feed and not always on NuGet.

The other aspect that is not that positive is the need to have the versions in sync, which means that whenever the class library assembly version changes the native version must be bumped too. And that requires flashing the target device again. Most of the time without any real reason except that a version number was changed.

This is changing for better!

As of today, the native version number is independent of its managed counterpart. Meaning that it will change when it makes sense and not just because it has to mirror the managed version. Some of you are probably thinking right now that this will be a step back and has the potential to cause trouble with obscure version mismatches and deployment hell. This won’t happen because of something else that we are introducing on all class libraries (and base class), an Egg of Columbus, actually. There is new assembly attribute on all of those that declares which native version is required. Simple but effective.

This is will be used from now on by the deployment provider to validate if the target has all the required assemblies and versions to safely deploy the application.

Because these introduce several breaking changes, make sure you update the VS extension (2017 and 2019 versions available) and the NuGet packages on the Solutions you’re working for a smooth transition.

Happy coding with nanoFramework!

Welcome Json.NetMF

If you come from the .NETMF age and at some point worked with json, you’re probably familiar with Matt Weimer‘s library: Json.NetMF.

Making a bit of history: that library started as a modification of Mike Jones’s JSON Serialization and Deserialization library. It was available as NuGet for .NETMF v4.2 and v4.3. It was never brought up to date with v4.4. Now it is.

Despite doing what was expected from it, the library never got any improvements and has been stalled for years.

Well, this is bound to change! Matt has decided to transfer the library to under the nanoFramework’s umbrella and since last week, that’s where it now is .

The plan is to keep the .NETMF NuGet package available and also provide an additional one for nanoFramework. The work to make this happen has been completed then nanoFramewotk version is available here.

It seems unfair to leave this nice tool inaccessible to other C# embedded developers so, at some point in the future, we could be seeing a NuGet for TinyCLR and another one for Meadow. Who knows?…

As for improvements: lets’ hear from the community, tackle the open issues and see where all this takes us. Of course, being open source, everyone is welcome to contribute!

Thank you Matt for your work on this. Rest assured it’s in good hands and we’ll be taking good care of it.


Network capabilities in nanoFramework: check!!

As they say: better late than never! This post is a belated announcement of networking capabilities being added to nanoFramework. Some of you may already have noticed that during last week networking capabilities were officially added to our development branch.

With this, nanoFramework has – definitely – reached a major milestone. I’m sure we are all in agreement that providing network connectivity is a must have for any decent framework out there that aims to compete in the IoT space.

A lot has already been accomplished and know that we are just getting started! 🙂
Let me guide you on a tour of what’s available today.

Managed class libraries

The Nuget packages nanoFramework.System.Net, nanoFramework.Networking.Sntp and Windows.Devices.WiFi include already a ton of methods that allow developers to accomplish a lot. Without trying to be exhaustive, one can find there: interface management, DNS services, SNTP service, Sockets, Secure Sockets, Cryptography and Wi-Fi network management (this one for ESP32 targets only).


This is probably one of the paramount features that are requested when embedded developers ask about networking. Yes, we’ve made it 😎 (and we are very proud of it)!
Support for SSL v3.0, TLS 1.0, 1.1 and 1.2 is available right now!

Supported targets

We provide ready to burn images including network support for the following reference targets: ST NUCLEO144 F746ZG, ST STM32F769I DISCOVERY and (of course!) ESP32 DevKit C.

Sample projects

Some work has been done here too. There are available samples showing how to connect to a SSL server; using a client certificate and validating the server certificate; resolve an address by querying a DNS service; adjust the RTC from an SNTP server; scan Wi-Fi networks in range and a couple of others.

Last but, by far, not the least we are working closely with the AMQPNetLite project to add support for nanoFramework and, very soon, an official Nuget package with this library will be published. Feel free to give it a try now, just go ahead and fork our fork.
A PR is also imminent to Paolo Patierno MQTT library. Same goes with this one: feel free to give it a try and do so by forking our fork.


How cool is all this? And we are just getting started!! HTTP client and server, web sockets and others are queued up to add more network capabilities to nanoFramework.

What are you waiting for? Go get all this, connect your device and start coding your next networked project! 😉

Setup Visual Studio to access preview versions feed

(updated on 2019-08-21)

If you are one of those developers that like to have access to the shiny and newer versions of the components you use, this post is for you.

It also applies if you are testing a PR for one of the class libraries or one of the experimental develop branches.

A bit of background information first to put you in context.

All the official (or labelled stable) releases of our Nuget packages are distributed through Nuget. The same goes for the Visual Studio extension. It’s distributed through the Visual Studio Marketplace.

All the above works just fine with the default Visual Studio configuration and settings. So nothing particularly thrilling so far…

Now, if you’re after the good stuff you’ll want to setup your Visual Studio to access nanoFramework’s developer feed. This feed hosted in Azure Artifacts from our Azure DevOps account.

Actually, there are two different feeds: one for the Nuget packages and another one for the Visual Studio extension.

Azure ARTIFACTS Nuget feed

If you want to add this feed to your Visual Studio, just follow the following steps.

1.       Open Visual Studio Options window (available in Tools menu).

2.       On the Options window navigate on the left-hand toolbar to Nuget Package Manager – Package Sources.


3.       Click on the add button (the big green plus sign on the top right) and enter a name for the package source along with the following URL:


4.       Click on the Update button otherwise your changes won’t’ be effective.

5.       That’s all. From now on this feed will be included on the searches and update checks on the Nuget Package manager.

Note 1: Make sure that you have this new source selected in the Package Source filter in the Package Manager (top left corner), otherwise it won’t be included in the search.

Note 2: in case you are looking for a Nuget package of a PR you are testing, for example, you’ll find those with the alpha suffix. If there is more than one, check the release date for disambiguation.

Open VSIX Gallery

1.       Open Visual Studio Options window (available in Tools menu)

2.       On the Options window navigate on the left-hand toolbar to Environment – Extensions and Updates.


3.       Click on the Add button at the right and enter a name for the gallery source along with the following URL:


4.       Click on the Apply button otherwise your changes won’t’ be effective.

5.       That’s all. From now this gallery will be included on the searches and update checks for your Visual Studio Extensions and Updates.

And that’s all folks! Now you can easily access the fresh new packages as they get out of our Azure Pipelines builds.

One small ‘step’ for a debugger, one giant leap for the embedded world!!

Today the nanoFramework project hit a major milestone: we’ve released a new version of our Visual Studio extension. What’s so special about that I hear you ask… Well it is the first one with the capability of debugging managed code!


Many will think that this is not a big feat, but it is. It has taken a year of hard work during which a lot of code was rewritten, cleaned-up and brought up to modern coding standards. There are still some rough edges to improve, but it’s very usable now.

The way nanoFramework interacts with Visual Studio when compared with the original .NETMF has changed quite substantially. Here’s a brief summary.

1. The project system was completely rewritten and it’s now based in the new Visual Studio Project System Extensibility.


2. There is no SDK to install. Everything is packaged inside the Visual Studio extension. That’s all a developer needs to start coding and debugging with nanoFramework.

3. All libraries are distributed as Nuget packages. This make it so much easier to consume, distribute, update and manage dependencies and versioning.


4. The Wire Protocol component, used to communicate with target devices, was completely rewritten and is now using modern WinRT APIs. The current version supports USB but it can be easily expanded to support legacy UART COM ports and also networked connected devices. This communication component is also responsible for a huge performance improvement making all the operations lightning fast. For example, the deployment of a managed project takes just a few seconds.

5. There is no MFDeploy anymore. A developer can perform all the required interactions with connected devices without leaving the comfort of Visual Studio using the Device Explorer Window.


6. The debug engine and the Wire Protocol components are now available as Nuget packages making them very easy to reuse in third party applications, production automation and other uses.

Now there is one less excuse to start delving into nanoFramework, please pull the repos and contribute with some PRs. 😉


Happy holidays and happy coding with nanoFramework!