I think you lack a clear understanding of what .NETMF is and isn’t.
NETMF is not an operating system.
These devices have a native firmware image installed on them that makes them appear as a NETMF debuggable interface. Users (you) write a C# managed app that gets installed on the device over USB.
.NETMF doesn’t run separate “apps” though. It’s an embedded environment that runs a single software routine. Think of it as a device that runs a single .NET app.
Certainly, you could write a .NET app that “feels” like an operating system; i.e., you could write a .NET app that has buttons to start up different routines – perhaps a button to start up a “calculator” interface, and another to start a “calendar” interface. But that entire environment – the “OS” and the “apps” – would still live in a single .NET deployment. In other words, it would have no ability to run anything that wasn’t built-in to it. If you wanted to add, say, a Contacts app, you’d have to open up the “OS” project, add another window, add more buttons, and recompile everything.
You could write a plug-in infrastructure so “apps” could be written for it, but those apps would have to be copied into the source tree of the operating system.
This has been done before, but the results are pretty pathetic. There’s significant overhead in this, and these devices are really slow to begin with.
.NETMF is not some hardware hacker version of a .NET Compact Framework device like a Windows 8 phone. These devices are significantly slower.
If, however, this is what you’re interested in doing, why not simply load the same app on two different boards?
You could use UART/I2C/SPI/etc to transfer the app state between devices.
Now, if you’re talking about providing an interface to allow one .NETMF app to be transfered to another device, you’re now talking about modifying the underlying firmware. We can get you going in the right direction over in the native forum – but, honestly, that’s going to be a huge undertaking, and I’m not really sure what you’d get out of it. It just sounds like a lot of tedious work that no one would benefit from.
You’re obviously used to writing software for desktop computers – where you can focus on form and functionality, without thinking about performance. Not so here.
The takeaway: these are highly resource-constrained devices. They’re designed to run a single task. Most people use them for the same sorts of stuff you’d program an 8-bit microcontroller to do. Don’t let the LCD touch screen fool you. These things make a Roku Soundbridge look like a Cray mainframe.