If you're looking or in need of votes, you've got mine !!!

In my opinion, NETMF repo first has to build. If I pull it and it doesn't build right away, than I doubt it will ever become a true community project. Using outrageously expensive Keil compilers is not going to work — average Joes won't buy it. Using outrageously expensive Keil devboards is not going to work — average Joes won't buy them too. If it takes 7 days of reading manuals to simply build it, then it's too not going to work.

I'd like to contribute very much, but entering costs are just too high for me. At the moment, NETMF codebase is hugely overcomplicated and overpriced.

Until that changes, we're not going anywhere.

@Stabilitronas While you are right about Keil, you are not entirely fair: the majority (grin) of supported boards are affordable (Discovery and Nucleo) and they can be build with GCC using a single line command. (I personally know people who have spent a lot of their resources to make it happen :) )

True, the codebase is horrible, like any other project of comparable history. Hopefully, it is going to change dramatically in the upcoming vNext...

@cw2 I'm well aware of what you've done. But on a global scope, your GCC port still feels like some dude's side project. I'd like to see it going mainstream. Keil name should either go away completely (preferred by me), or at, at least, only maintained by those contributors, who want to save every bit of flash space, and not vice versa. I guess only business contributors, like GHI, would be interested in reducing image footprint, as that directly converts to $. For average NETMF Joe, it is totally irrelevant.

@Stabilitronas well, than go and assist/help and get that gcc port up, running and ready for a mainstream adventure. All the NetMf Joes, including myself, will thank you for that. Be constructive, address the week spots and/or missing parts.

@Stabilitronas Ok, touché.

Thanks to all for all the feedback here in this topic and in other discussions. It has all helped inform thinking about the future of NETMF (including that it should still have a future!).

There seams to be some confusion here on the nature of the project, @josesimoes says NETMF should become a true OSS, but then asks for Microsoft to, essentially treat it as a product. NOTE: I'm not trying to pick on @josesimoes here - this is a common point of conflict/confusion with many OSS projects from Microsoft. Hopefully I won't scare or offend anyone by being blunt on this in an attempt to establish clarity: .NET Micro Framework isn't really a Microsoft "product", and hasn't been one for many years now. It had a short life as a product in and of itself but, for a number of reasons, including a major world wide recession, that didn't continue. That said, Microsoft has in the past, and may in the future have projects that want to use .NET Micro Framework in them in some capacity and if that happens additional development effort and contributions from Microsoft will likely also occur. This is the same as with any other company that wants to use NETMF. The difficulty here is that even those of us who were once paid to work on NETMF and our users continue to think about it as a Microsoft "product". The troubles and frustrations that are observable now are, I believe, a result of everyone on all sides finally realizing that's not the case and having to deal with a change. Something we mere humans aren't particularly fond of 😉

In my observations, beyond just the recognition of change, a significant part of why we don't have a more broad "team" is that, historically, the bulk of community efforts have been focused on porting and adding additional .NET libraries rather than on the developing the core of the runtime. This is in part due to the fact that so far Microsoft has been the primary driver of the core and I'd say more significantly, is the fact that the core is so - how shall I say... "under documented" 😉

All of this feedback is the primary reason why the vNext branch is starting with nothing but docs. The documentation needs to layout how the core of the runtime works so that meaningful contributions can occur. For future capabilities everything will be written up as docs first so they can be discussed and reviewed before code is committed or PRs appear. We need to have clear guidelines on what sorts of changes are "in-scope" for the core product and those that aren't (i.e. changes to the runtime that effectively lock it to a particular SoC, or architecture would be a non-starter).

As the new branch begins to fill up we'll begin to establish new subject matter experts to fill up a team as @josesimoes requests. ( Side Note: the official GitHub team is much larger than the two people you currently see, however GitHub requires the individual to opt-in to visibility at the project level so they aren't all visible. They are also not all active so that will need to be addressed going forward as well ). I've been exploring some options on how we can manage some of this and when I have some more details I can share I will. (There are lots of legal weeny type issues to iron out) Ultimately, the reality is that I, as an individual, can't scale big enough and we will need additional subject matter experts to take on roles of reviewing and processing PRs, bugs and feature requests, etc... in various areas.

@Stabilitronas Yes, the reference MCBSTM32F400 is an expensive board. It was, chosen deliberately because it had full support from ARM/Keil, because it had "everything including the kitchen sink", and probably most importantly at the time, our port to it wouldn't be seen as a competition with commercial partners and more of an aid as it used an SOC that was effectively a superset of the most commonly used SoC in NETMF commercial boards. The plethora of low cost micro controller dev boards has grown to a point where I'm no longer convinced that last point is relevant. I've got a couple of the M7 discovery boards on order for use as the first Cortex-M target for vNext. Based on the state of the industry I'd like to move away from having a single reference and move to where we have a set of them with at least one for each major architecture. Though this is an area worthy of some separate discussion.

When considering reference ports to place into the repository it is difficult to maintain the integrity of the tree and code base if we can't test and validate them all with every commit. (We had a problem with that recently where things building from GCC were busted). Something for us all to consider is how we organize that aspect of things. For example, do we continue putting them all into one tree and hope we don't mess things up? Do we require a "donation" of hardware to a central test lab before accepting new ports, and who pays for that lab? Maybe we need to split the ports to their own repos? lot's of things to consider there. If we can nail the Packaging part of vNext then the HAL level code could really be a separately maintained package. These are some of the issues we'll need to iron out going forward. One of my major design goals in vNext is to better isolate the NETMF core runtime from the underlying platform code so that getting NETMF up and running on new silicon is a lot easier for most users (For those bold enough to be using brand new or pre-release silicon it may still be a challenge as there might not be any existing low level code to run on top of but it won't be any more work than getting anything else to run under such circumstances)

There was some Gitter chatter about NETMF not being in the GitHub/dotnetmf org for .NET Foundation and speculations on broader political meanings of that. Let me set the record straight on that - The reasons are far more mundane than any grand politics or doom/gloom predictions:

The .NET Foundation was barely an infant when we set up the GitHub org with .NETMF ownership under MS OpenTech. As Microsoft, under Satya's leadership has, dare I say. Opened up to Open Source 😁 - MS OpenTech was no longer viewed as necessary and .NET Foundation was in full swing. However, NETMF had already created the NETMF org to host the interpreter and a few other projects. We needed an org to host NETMF, dotnetmf wasn't available and creating our own was the best option available at the time. It is possible to transfer but it isn't without disruptions for users (upstream repositories would all need to be manually reset, etc...) so we just stayed in this org. If that fact is consider important enough we can move but everyone with a local clone would need to make manual adjustments and any third party links from other online sources would have to be re-directed. So far I've considered that not worth the effort, I'm open to hear otherwise from the community.

@smaillet-ms Steve thanks for the great explanation of what is going on. I look forward to vNext.

@smaillet-ms inform us about the team / organisation behind it with a nice who we are wiki page(s) and we try to achieve etc. this will help in understanding and prevent from derailing.

I am willing to put my hand up to help in anyway i can so that NETMF gets more traction and has a bright future as it as an outstanding solution for many embedded projects.

As the people who have used NETMF in conjunction with VS already know of the massive benefits that the Eco System brings so it will be a crying shame if project stalls.

I have a few ideas that i will put in motion ASAP that will hopefully help generate more discussion and up the visibility of NETMF.

@piwi1263 A point I was trying to make, and apparently failed t do so, is that the GitHub Team isn't really indicative of a set of people governing or driving the project, the GitHub team is an access control feature nothing more. Ultimately from the definition of team people seem to be looking for here - I'm it at the moment.
This is why my focus right now is on documenting what we have and defining the "clean slate" approach to building up vNext. An additional advantage of the clean slate approach is it allows the entire community to participate as it builds up, hopefully bringing a broader sense of knowledge and community ownership to the project. From that, I hope will fall out some natural team players we can formalize into an official team.

@smaillet-ms thank for your detailed answer.

I think that everyone involved kind of figured it out that NETMF is not a Microsoft product for a long time. Nevertheless, your explanations are very welcomed. Probably should have been matter for a blog post or kind of an official announcement. But that is in the past now.

On the confusion about OSS vs product: asking Microsoft for institutional support and to make use of its powerful social and network channels to promote NETMF, is not the same as asking Microsoft to treat NETMF as a product. Is it? To be perfectly clear: I wasn’t asking for that.

Regarding the recent vNEXT branch of NETMF: that should be discussed under a different issue (see #493), so it won’t get mixed up with this one. (actually I’m not entirely convinced that a ‘GitHub Issue’ is the best ‘channel’ to carry these discussions)

@josesimoes GitHub issues are the best available forum we have for discussions. Gitter doesn't support proper threaded conversations. Figuring out who is replying to what in GIthub is tough enough and worse in Gitter.

Unless someone has the time to build and fund the ongoing maintenance of an online web forum we don't have anything else to go with. (I'm open to suggestions here as I'm not fond of the very limited issue tracking capabilities of GitHub in general, and even less fond of Gitter)

[I long for the day when VSTS would support public repositories... ]

Microsoft for institutional support and to make use of its powerful social and network channels to promote NETMF, is not the same as asking Microsoft to treat NETMF as a product. Is it?

Yes, that is part of the definition of treating it like an MS owned product. It hasn't really existed as such a thing since the move to CodePlex years ago. However, remnants of the various support have lingered (e.g. you can still find old docs on MSDN but they haven't been updated to the latest version as that takes some significant resources to develop and maintain) While it is sometimes possible to get marketing support when things align perfectly that takes a lot of effort and lobbying. To better understand that - pretend for a moment Microsoft doesn't exist - and instead we are talking about leveraging ARM, given how much NETMF usage is on ARM that seems like a great fit - But we'd have to spend a lot of time meeting with folks from ARM, showing value and products using NETMF on ARM, etc... all of which takes serious dedicated effort and time. It also requires that we have a viable story they want to hear and think their customers want to hear.

@josesimoes, @smaillet-ms Let's have a look at a few most popular projects at https://github.com/aspnet or https://github.com/dotnet and adopt what's suitable 😁

@josesimoes, @smaillet-ms

First, I want to echo the comment

NETMF is a truly awesome framework with an incredible potential for commercial, hobbyist and learning scenarios.

Second, from everything I've read on pretty much any of the forums, can be distilled down to there is only so much resources, and anything can be done (to steal a quote from GHI's forum), if we put enough coins in the slot.

If I may, I would like to provide a few comments, based on the position of being an end user of embedded boards for Industry. Just to provide an understanding where these comments are coming from, I am neither a programmer, or hardware designer, although dabbled in both at the last company I worked at, and in starting my own company, I've had to do both. In general, I believe in learning enough to be able to do prototypes, and then have enough understanding to be able to find the expertise to hand off the cleanup to and avoid hiring those that just know a few buzzwords. I'm in the unique position, where I attempted to sell a product, based off of .Netmf to a really big company, and instead of buying working systems, they bought the entire company, as they are their own customer for the next 3 years.

I think that everyone involved kind of figured it out that NETMF is not a Microsoft product for a long time.

As we scale up and start doing production run's, trying to choose which platform to develop in, is definitely cause for concern. The whole reason behind choosing .Netmf at the start, was the belief that Microsoft was supporting it. To say Netmf & Llilum isn't a Microsoft product, goes completely against the grain of any of the source code that I open up, look at,, and the first line is "// Copyright (c) Microsoft Corporation. All rights reserved." As an average / new user, buying a board off the shelf, well,, maybe I didn't read the fine print.

Secondly, it is my understanding that .Netmf doesn't compile / debug, under any other compiler other than Visual Studio. Just as an example, I get that GHI has RLP ability, but again, as far as I understand Visual Studio doesn't support debugging of RLP code, which leads me back to my understanding that Microsoft needs to be in the picture. The point I'm trying to make,, is whether it's Llilium, RLP, NETMF, Microsoft seems to need to be part of the solution.

I am willing to put my hand up to help in anyway i can so that NETMF gets more traction and has a bright future as it as an outstanding solution for many embedded projects.

What I'm seeing from my part of the industry, is that Silicon is rapidly becoming so fast / cheap, that even if .Netmf isn't the fastest, or smallest, the time to market for leveraging off of the Visual Studio environment far outweighs the advantages of a smaller/faster compiler. Something as silly as just the amount of Example Code that exists for it already, is worth a significant amount of money.

I'd like to contribute very much, but entering costs are just too high for me.

I agree with both the above statements. I will use both the GIF bug, and the SSL bugs as real case examples that I've ran up against,, and I know many others using Netmf has ran up against. I spent 2 weeks trying to figure out how to get Netmf to open up a GIF as its the only format within Netmf that supports transparencies. A large part of that time was downloading the source code, trying to understand the directory structures and then trying to get it to compile. Admittedly I'd had very little experience with Netmf at that point,, so some of it was learning in general (ie what each bit means in a gif file), but managed to finally understand enough of it that I didn't fix the bug, but figured out a work around.

The specific point I'm trying to get at, is with the difficulty in getting it to compile, it wasn't worth actually fixing it in the code for the benefit of all because I got it to work. Secondly, given my coding skills, while I get things to work, I wouldn't feel comfortable with it being a final solution as I understand what I don't know, but there is not really any method to be able submit rough working corrections, and have someone clean them up to fit with all the existing standards.

The next bug being SSL, we spent approximately 10k on trying to fix that one, because we didn't know just how deep the waters were, although to be fair an outstanding issue like that is an itch that I just can't help but scratch. As a short term work around, we ended up establishing SSL tunnels from cellular modems back to the server, Long term, that isn't a final solution. So my options are bite the bullet & hire a full time programmer to dig into the issue, move to a different base such as Unix, or pay someone to do it. Given the in depth nature of that bug, my preferred solution would be to pay someone from Microsoft, or potentially GHI, that already has the skills to address it.

Instead of simply complaining, I'd like to throw out a few suggestions to address some of what I've brought up.

1. I know there aren't a lot of programmers out there, that are at the level of maintaining the code base to a rigid structure, so echo that there should be a core team of programmers dedicated to it. Easy to say, but nobody wants to work for free. There are several issues that I know as a company I need to get solved, and I am not against paying towards getting them solved, although if the community as a whole benefits, then why should a couple of companies foot the bill, (including Microsoft, in reference to additional features if Microsoft wants to use Netmf for its own use.) I propose setting up a Kickstarter project, with items added in, a cost assigned to them, and as they are funded they get knocked off,,, the more coins,,, the more it gets done. Unfortunately,,, I believe Microsoft would need to take a lead role in this, simply because they would have the understanding of what realistic costs would be. I know the first three items I'd be willing to help fund is the SSL bug, A single downloadable solution, that compiles out of the box for one of the off the shelf boards that you can get from mouser, and a rush on increased documentation.
2. Another thought that echos comments made above is to raise awareness of Netmf. If I could get a couple more volunteers to chime in, I would have absolutely no problem to dedicating 10-20 hours a month in this pursuit. I'm just throwing this out there to get some feedback, so please feel free to offer modifications or suggestions but the important thing is I think I can justify where the coins come from. Assemble some sort of robotic kit,,, something that would be 'cool' to I don't know,,, a 14'ish year old child. Maybe something that could be controlled from a smart phone,,, but in basic parts, so that out of the box, 1hr work,, its functioning and have them hooked. But,, also leave it open enough, that more things can easily be added, customized,,, (sound like me ripping off the birth of Gadgeteer anyone?) I'd be willing to spend my time to both, a) Contact schools around the country, and get submissions from the schools that wanted kits,, free of monetary charge. The only cost would be they have to submit, online, a video / write up of what they accomplished., especially as they request more sensors ect. That way, its minimized the amount of hardware that would never get used. b) As I've been in the agricultural community for about 10ish years,,, and have a lot of contacts inside it. I'm pretty sure,, that I could go to them, soliciting them for donations, to provide educational tools to children that otherwise would never have. I'd then go to Microsoft,, ask them to match the donations,,, and probably Arrow / Future / Digikey / Arm manufacturer's, ect to donate the materials. I'm actually thinking that if you picked the top,, i don't know,, 10 most creative uses,,, it would make a pretty interesting competition.

This isn't something that I could do all on my own,,, but I am definitely willing to volunteer my time on fundraising,, building support at the educational level,,, and even offering to donate some time if a child has demonstrated that they have taken the project to a serious level, providing mentoring for a child in the creation of a custom board / sensor,, ect,,

I can get a commitment from Microsoft to help support it,,,
A few people to assist with putting the kit together,, someone to help with the marketing,
A commitment from GHI (or other vendor?) to manufacture the materials,,, at or close to cost? As a side benefit, some of those neat Gadgeteer modules might come back..

Its just a thought,,, but given that Gadgeteer was born out of schools, gets kids involved in programming, and would build support for NETMF,,, thought I'd put it out there...

In general the downside of MF has always been the effort required to port to hardware. However the plus side of the ease of application development/debugging has always managed to cancel this ( just!). This situation improved considerable with the 'donation' of the STM Cortex M port code from Oberon ( Mountaineer Group). With the range of processors from STM, and especially some of their more recent offerings, it has been possible to select a processor with the capabilities required for a specific custom hardware project, and in general maintain a SOC approach ( the only exceptions to that, are when we are doing graphics related designs, where we have to have external SDRam). The current STM based M4 port base code makes it a relatively painless process to generate a new port.
On the issue of MDK or GCC - on our commercial work, yes it is crucial to be able to save a few bytes of flash, especially on TinyBooter. If you blow the 48K limit, then you lose the next 16K sector to maintain the config section - which actually means config has to go in the next 64K sector - as the aim is for a SOC product, the normal 1M of flash memory mapping becomes crucial. But this is easier with the advent of the 2M flash parts. So the cost of the MDK tools is acceptable for commercial work , and it does seem to make sense to use an ARM ( the company) based set of tools for an ARM core - especially as MDK has been using the RVDS compiler for a while now. As was mentioned by some one in this thread, the community can contribute GCC ports, but for commercial work we need the added consistency or MDK.
The real difficulty with writing a new port or modifying a reference port is really the lack of documentation on how the framework works.
So as @smaillet-ms has already pointed out, V5Next is the ideal opportunity to take the pain and sort all these problems out. The approach of putting the priority on the documentation first is absolutely the correct way to go. Moving to a simpler build system than msbuild will also help considerably - so the outline Steve has made on the approach to V5Next gets our vote.
@smaillet-ms - As I have mentioned documentation ( lack of) many times in the past, I am more than willing to offer time to help generate sections of documentation for V5Next - just assign me some areas to cover, with a brief out line of what's required.

I have to agree that the fact that GCC is enough for community might be a bit of illusion.

I guess only business contributors, like GHI, would be interested in reducing image footprint, as that directly converts to $. For average NETMF Joe, it is totally irrelevant.

It means average Joe can save money too. GCC vs MDK is a difference whether MF fits on the smaller boards or not, which translates into there are MF boards or there are not. I have had a chance to use both GCC and MDK compiled firmware on the same board and the speed difference at runtime was tremendous. If you want to have MF boards available on the market, you definitely need commercial toolchains.

There is no doubt that support of GCC, as well as free editions of Visual Studio, is a vital part of the project being open source and accessible to everybody. But how many MF boards were ever there shipped with GCC compiled firmware?

These conversations have certainly trigger a lot of interesting feedback and in the interest of openness I'll try to add some additional thinking here. Please note this is not a confirmed plan or actual reality yet as there are a number of factors to cover. I hesitated to discuss this before as it's not solid yet and there may yet be obstacles I'm unaware of that prevent it:

The general idea I'm looking at is to follow the same pattern that the F# team has done. In particular to create an official legal non-profit entity that can operate as the governing body for NETMF and Llilum and to provide a way to accept funds that can go towards basic operational costs (e.g. maintaining commercial tool lic. and a build/test lab with physical hardware that can be tested against every PR). Furthermore it can fund marketing efforts and work with the education sector, etc...)

@Michaelb-NGC The entirety of NETMF was released under the Apache lic on Codeplex back in 2008. If there are any file remaining with any copyright notices that don't reference the apache lic. then that is a bug that should be filed so it can be corrected. However, the entire NETMF IS covered by the Apache lic. Though some of the libraries we include and use (such as LWIP and OpenSSL retain their own lic., which is a significant reason for the componentized plan for vNEXT with packages - a goal there is to eliminate all other projects from the tree to help avoid confusion and keep NETMF focused on the core run-time.

@miloush

I have had a chance to use both GCC and MDK compiled firmware on the same board and the speed difference at runtime was tremendous

I am curious what GCC toolchain was used? I know certain toolchains that were used in the early days of NETMF GCC support generated much bigger code, mainly because [their free versions] used C/C++ runtime libraries not optimized for embedded systems (e.g. Code Sourcery). But, the situation has changed dramatically since https://launchpad.net/gcc-arm-embedded appeared, with a direct ARM contributions (optimizations, newlib-nano).

Edit: The MDK license does not allow "disclosing information about its performance efficacy, reliability or quality ... without the express written permission of ARM", so I deleted this paragraph.

Please note I am not trying to disprove your results, neither to defend GCC at all costs (I am not affiliated in any way). I just think that 'GCC code is big and slow' is no longer true and modern GCC-based toolchains can be used for commercial development of NETMF firmware.

I second @cw2 on this.
The days of bulky code and inefficiencies with GCC for embedded system are gone with ARM stepping in, the availability of newlib-nano and the general improvements in the gcc arm toolchain on Launchpad.

We have commercial devices deployed with NETMF images compiled with gcc. In fact that's what we use for these projects.
If NETMF can have support for both that's fine. We needed to be careful here so we don't end up on a situation of one flavour preventing the other from making progresses because of some unsupported or too cumbersome to implement detail.

I totally agree with both @cw2 and @josesimoes on this.

From my point of view, I can not effort an MDK or get some funding for it, so I'm pretty much left with one choice. Well, not really of a choice, is it. And I think others will be bound to GCC as well, would be d... pitty if it would be dropped. For me, it means it's over for building netmf ... wouldn't like it when it happened. Can't do much about it, but still definitely would like it.

@miloush

It means average Joe can save money too.

Does he/she? Let's take a look at the prices of Nucleo boards (I think everyone agrees that those are very hobbyist-friendly: they're cheap and they're easy to get):
http://eu.mouser.com/Search/Refine.aspx?Keyword=nucleo

It is hard to observe any immediate correlation between board capabilities and price, but it feels like it's 9€ for a small board, 12€ for medium board, and then 22€ for the monster M7. Discovery boards follow similar pattern. So basically it's either 9€ or 12€. Not much of a difference, I would say, especially having in mind hobbyists usually do not buy them in batches. And if they start doing so, and price saving come into play, hobbyist becomes a business and different game rules kick in.

I think this is more like of "Open source NETMF" identity question. Sad to say, but NETMF is very marginal, pretty much non-existent, in hobbyist world, compared to Arduino and mbed. Those two get all the attention. Those are very cheap and very easy to get your hands on. Even Windows Iot core now gets a lot more fuss than NETMF.

However, I have a feeling that in business world situation is radically different. NETMF has it's use there, but since that it business world, nobody really goes public about it. Based on my very subjective observations, I dare to say that NETMF is way more popular in business market than in hobbyist one. Which makes choosing the main compiler more difficult: if NETMF is mainly used by business, then choosing MDK/RVDS makes sense as that leads to possible savings on MCU, but this in turn dramatically punishes "openess" of NETMF, because only select individuals/businesses will be able to contribute.

Using GCC might (as it seems GCC is no longer that bad at compiling things) punish businesses, but they are making money out of NETMF, so maybe they could throw some money into it as well, by maintaining MDK branch?..

Ideally, code should be universal so any compiler could be used. But I somewhat doubt there enough people (yet, at least) attracted to NETMF to make this viable...

So, to sum it up: using GCC may or may not attract more hobbyist contributors. Using MDK/RVDS will certainly not, IMO.

Well maybe it is time for MDK/RVDS to conduct a cloud compile service than ....

@cw2 @josesimoes Glad to hear that! My experience is from 2013, perhaps something around 4.2.1 and might indeed very well have been Code Sourcery.

@piwi1263 No one is suggesting to drop GCC support, at least not me. I cannot afford MDK either.

@Stabilitronas I don't think there should be a "main" compiler, but I agree that obviously for supporting a given compiler you need to have it. That said, I don't think there has been a shortage from business contributors supporting a commercial compiler in the history of MF, it has always been GCC that was behind when it was. So if there are people willing to keep the GCC support up-to-date and living, which it seems there are, that sounds like a win-win to me!

JMHO...
Target some cheap easily accessable hardware boards like the NanoPi Neo, Raspberry Pi or Beagle Bone Black.

Hm, Nucleo board STM32F411RE is avail for about 14 USD.

And it runs NetMf 4.4

When I saw netmf in action for the first time, it was used with Alljoyn (i think i was i was video form WinHec) and i was amazed. Working with alljoyn using Visual Studio tools like GHI SDK when you hit only "Debug" and evrything runs. If you are trying to use Alljoyn now, first go to alljoyn tutorial, and then.... gave up, there is so much work to do, and for newbie it is really hard to simple getting started with this framework (which is awsome if you are using it with Win10 IoT). 2+ years after this was annouced nothing happend in this area, and the IoT bussiness is growing. I think netmf has a great potential with Alljoyn.

@tomek14 - I agree totally. Unfortunately, Microsoft never developed AllJoyn within NETMF beyond getting enough to work for that demo. In case you haven't noticed, there is a branch in the project called "AllJoyn". If you're adventurous, you should be able to build it and duplicate their demo and perhaps make improvements. I haven't done this yet and can't say more than that it's there.

Why you targets to ARM? I think it's ideal for IoT like ESP8266/ESP32. They use Python and Lua, why not C#?