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

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.

.NET nanoFramework has joined the .NET Foundation!

We have some great news to share: .NET nanoFramework has reached an important milestone by joining the .NET Foundation!

This is kind of a “return home” for the project. Despite being, undoubtedly, connected to .NET because of its roots, the programming language, and the tools it uses, it was not exactly part of the family. Now it is.

The .NET ecosystem has grown a lot. From desktop to cloud, AI, IoT, and smaller devices, it is now virtually everywhere. Even though there are “official” solutions for embedded systems (from Azure Sphere to, more recently, Azure RTOS and friends) those are somewhat “out of ecosystem” in the sense that developers have to keep using the traditional C/C++ in order to code for such devices. If one wants to code in C#, the smallest you can aim to reach out to is a Raspberry PI.
.NET nanoFramework extends .NET’s ability use to really small and constrained devices. Yes, there are a couple of similar offers out there, but none are Open Source. And none of those allows coding for Expressif ESP32; or ST Microelectronics STM32F0/L0/F4 (to name just a few); or Texas Instruments CC3220 and CC1352; or NXP MIMXRT1060 EVK; or any other new target device that can easily be added.

It is our expectation that this will boost the project in many ways. Such has:

  • Visibility. This is one is kind of obvious, right? Considering that this is one of the goals of the .NET Foundation, more developers will become aware of the project, will start to use it and, hopefully, in the good spirit of Open Source, will give back to the project, ultimately allowing us to move faster and increase the overall quality.
  • Easier access to the .NET teams that we depend most upon, or that have impact on the project. These are Visual Studio, VS extensibility, .NET project system and such. Every now and then we bump into bugs/changes that break stuff and being able to report and discuss things quicker and easily is invaluable. Being able to pass along our suggestions and “needs” can only be positive for the continuous grow and overall quality of the project.
  • Tighter integration with the .NET ecosystem. As it is now, .NET nanoFramework is perfectly usable and integrated in the key aspects and tools including Visual Studio, libraries available through NuGet etc. But we, admittedly, have some pain points that could easily go away providing that such integration can happen. Starting with the Project System, having a dedicated target framework identifier would make our life so much easier. Extend Unit Testing framework so that we can have it on our projects and finally unifying APIs. We have already started walking down this path with conversations with the .NET Core IoT team, so the first visible changes are due shortly.

A thank you note is due to all the people that paved the way and made this possible. When .NET Micro Framework was launched a long time ago and showed that writing C# code for microcontrollers was possible. And, of course, open sourced it! .NET nanoFramework sure is a lot different from what was .NETMF back then, but we are standing on the shoulders of giants and we owe a lot to those very smart and talented people.

All in all, it is a positive event that can only bring good things for the project. We are very happy that it is happening, and it sure feels like a recognition for all the immense effort that a handful of people have poured into .NET nanoFramework for the last 4 years.

A lot of great achievements are ahead of us for sure. Let’s make that happen!

PS: We hate to see wasted talent and positive energy! Join our Discord community. Fork our samples repo. Grab open issues. Fix bugs. Contribute with new features. Write a project for Hackster.io. Have fun with .NET nanoFramework!

Changing licensing to MIT

As some of you may have noticed: we have changed the licensing terms of some of our repositories.

Until yesterday, there were two licenses across our repos: Apache 2.0 and MIT. The oldest ones were under Apache 2.0 and newest ones under MIT.

Being both the “permissive ones” and, in practice, without much difference between them we thought on making it simpler for everyone (both hobbyists/personal users and companies/commercial users) and unify them.

We have decided to go with the MIT one because of its simplicity and openness, which is in the spirit of what has been done since the .NET nanoFramework project started.

No big deal, most will say, but we hope that this is another step on consolidating the project’s organization and openness.

Have fun!