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).

Automatic firmware updates

Today we are proud to announce that our Visual Studio extension now supports automatic firmware updates! We hope you agree that this is a major, and much needed feature.

What do you have to do to have this working? Just update the Visual Studio extension to the latest version! Once that is done, just plug the board as usual and all will happen auto-magically when you next run a build. No kidding!

All this happens in the background, pretty much like Windows Update. As soon as a board is connected, its firmware version is checked against our database of compatible boards, and if there is a newer version, the update process is started before the program is deployed. No more tedious work of typing at the command line to keep your devices updated.

There are options to enable/disable the feature and to use preview or stable images. These are accessible in the setting dialog on Device Explorer.

The initial version of this new feature is able update the CLR images for STM32 targets. We will be adding support for ESP32 and TI targets soon.

It is worth noting that this feature requires firmware version 1.6.0-preview.54 or higher. If the target is running an older version, you’ll have to do it manually using nanoff one last time.

We hope you find this amazing new feature in nanoFramework Visual Studio extension makes your development experience that much easier.

You can check a video demoing this functionality on our YouTube channel here.

There is also an FAQ about this feature, in case you have questions about it.

Make sure to report any issues and provide your feedback and suggestions for improvements.

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!

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!