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!