Renewing our commitment to NETMF!

NETMF has always been a great way to bring the power of .NET and Visual Studio to embedded devices. It allows businesses and makers to use their existing developers and skills to quickly bring their embedded idea to life. This was a technology with many big names and partners involved. The future looked bright.

Now, though, NETMF’s future does not seem as bright as it once was. Most involved in the project before have moved on. Issues remain unfixed, progress is slow to non-existent, the difference between modern .NET and Visual Studio grows every day, and there is no clear and official messaging about the future of the project. For a long time, our hands were tied. We only maintained ports to our hardware and added key features for our customers. The important .NET and Visual Studio bits were in the part of the stack maintained by other parties. With no clear messaging about where the project was going and who was supporting it, we were unsure about what we could do or where we could help, so we waited to see what would happen.

This long period of confusion and waiting has hurt what is most important to us: our customers. Now we have decided that we will no longer wait on others. We want to make sure that we deliver a great end user experience. We are taking responsibility to ensure that the entire NETMF experience from install to development and deployment is Fast-and-Easy (FEZ) for our customers. Nothing is off limits and everything is on the table. We want to hear what you think needs to happen to make our new NETMF a compelling and popular platform.

We have our own ideas on what we want to see in our new NETMF too: modern and complete Visual Studio support; consistent and clear versioning and updates; networking, graphics, and native programming that work right; a development workflow that is familiar to modern .NET developers; support for modern .NET constructs like generics, async, and nuget; compelling features and support for embedded targets; and much more. Of course, while we can’t promise anything specific today, we do plan to actively engage our corporate customers and the community as we go along.

It’s just not NETMF either. The recent changes to the community in the Task Tracker, Codeshare, and forums are part of this too. They’re the beginning of improvements coming to the catalog, website, support, documentation, and more. It’s still very early and we’re hard at work laying the groundwork for what is to come, so stay tuned for more updates and details. We’re going to bring the FEZ back into GHI Electronics.

19 Likes

I think NETMF is still an important Platform. At least for me it is.
Important points of improvement (in that order):
[ol]Stability (specially in networking)
Performance
Multiple FW Versions on one development machine to support “last”, “current” and “next” version projects.
Generics and even more identical Code for NETMF and full .NET (I have several libraries I need on both platforms)[/ol]

1 Like

Same for me but in different order:
[ol]Stability (specially in networking)
Performance
Generics and even more identical Code for NETMF and full .NET (I have several libraries I need on both platforms)
Multiple FW Versions on one development machine to support “last”, “current” and “next” version projects.[/ol]
Actually the #4 is nice to have but not important.

In the past we were tied to the OpenSSL version that was part of the build process. Going forward we will have greater flexibilty in how we build NETMF which would allow us to use a different version of OpenSSL or whatever stack we want to use.

1 Like

Gary, you said the same one year ago about Gadgeteer, and I don’t see any reason it will be different in a few months for NetMF.
Giving just a 4 month notice for loeaving Gadgeteer was at best unfair for all the people who invested on that technology. If you are unable to support Gadgeteer, how do you expect to support NetMF?

I think for gadgeteer GHI was refering to the commitment of MS to make it purly open source, which then did not fully happen.
What I understand for NETMF now, is that GHI makes their own fork of it, where they then make changes and fixes to the NEMF core by them self.

1 Like

With Gadgeteer there was expectation of some external support and changes. We were waiting just like you all were and not much happened. It was not completely GHI’s plan. Also, Gadgeteer requires a lot of resources, over 100 boards that need drivers and updates regularly. We are now focused one NETMF core and the our core products, https://www.ghielectronics.com/catalog/netmf What is different now with NETMF is that we are not waiting on anyone. We will steer the ship the way it fits best to our customers.

About the 4 months, we understand and we are ready to do whatever necessary to help you with this transition. Removing Gadgeteer off the catalog doesn’t mean we do not have boards in stock, or can’t make them. This is an important step towards having a clean and clear product line.

@ Reinhard Ostermeier - You are right. A lot of folks at MS did their best to help out and we appreciate what they did but it is time we can freely make any changes needed to take our products to the next level, which may not even be called NETMF!!

2 Likes

One of the reasons we decided to no longer support Gadgeteer was so that we could focus on NETMF. I also believe that with the four month notice we asked customers to contact us with their needs and we would try to help support those needs. And keep in mind our investment into the Gadgeteer ecosystem was extremely high as well.

I have one more Point:
RLP is also important, as long as the performance of the C#/managed code is not increased drastically, and hard interruts and timers are available there too.

1 Like

(There is so much work left to be done. Sigh.)

1 Like

@ Gary - I applaud your renewed commitment to NETMF. More power to you guys.

3 Likes

This is in the newspost

NETMF has be a critically important technology in the Oceanographic research platforms I build on a day in and day out basis. I find the whole Visual Studio and GHI electronics ecosystem unique in it’s ability to provide an effective embedded development environment that doesn’t require a fleet of programmers. Even with the irritating idiosyncrasies we’ve all had to deal with. I’m overjoyed that GHI is taking the bull by the horns and committing to improve the whole NETMF experience. Thanks GHI!

7 Likes

This is a good decision. Thx

We started with full force already and can’t wait to share the results whenever they are available.

Thanks. These positive notes will make our team work even harder.

If you’ve already started then how about sharing the current roadmap while Gary is trying to figure out the next one?

@ SouthernStars - Gadgeteer is actually a very complex system, which is why so many of us loved it in that it handled a lot of things for us. Unfortunately things like the designer in Visual Studio are huge beasts that needed Microsoft to work on as they are too much for GHI to handle, plus there are parts of VS that GHI doesn’t have access to, so bye bye Gadgeteer. Still a very bad decision on Microsoft’s part given they don’t have anything equal or suitable to replace it with. NetMF could be supported by GHI and the community as its a simpler environment to work in and on, plus all the bits are available unlike Gadgeteer where some parts never escaped the evil grasps of the stuffed suit lawyers who should be busy as testers for the latest generation of WSYP devices.

1 Like

I guess the current product lineup (G30 … G400) will get this new firmware then?