After the release of v1.0 we turned a page and that is true on what concerns our GitHub repositories history. Release means tagging a point in the repository commit history. And suddenly after that all hell breaks loose on our versioning system! Continuous deployment and continuous delivery are great, but we must make sure that … Continue reading All systems green! (again)
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 … Continue reading nanoFramework v1.0 is official!
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 … Continue reading Obfuscation? We have an app for that!
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 … Continue reading Network capabilities in nanoFramework: check!!
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 … Continue reading We are moving our chat to Discord
Have you ever faced the situation of needing to add support for a specific hardware? Or to perform some computing intensive task that would be more efficiently executed in C/C++ rather than with managed C# code?
This is possible with the support that .NET nanoFramework has to plug “code extensions”. It’s called Interop.
What exactly does this? Allows you to add C/C++ code (any code, really!) along with the correspondent C# API.
The C/C++ code of the Interop library is added to an nanoFramework image along with the rest of the nanoCLR.
As for the C# API: that one is compiled into a nice .NET nanoFramework library that you can reference in Visual Studio, just like you usually do.
The fact that this is treated as an extension of the core is intended and, in fact, very positive and convenient. A couple of reasons:
- Doesn’t require any changes in the main…
View original post 3,071 more words
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 … Continue reading One small ‘step’ for a debugger, one giant leap for the embedded world!!