I think sending the screen buffer of a TinyCLR device to be viewed on a phone/tablet/computer is useful to many. Virtual Network Computing - Wikipedia
You could even create a headless device with a remote screen on a phone!
Any thoughts? Was this done on netmf before?
I would think for most remote visual access applications a web server would be a more versatile solution.
The idea is you can use the built in graphics to generate images that show on a remote screen. But I guess you can build a webpage showing a bitmap, which is the screen capture. But how to keep it updating? A page paying a āvideoā?
And what about keyword and mouse events?
Who is going to port this?
There are no releases, so itās not really portable yet.
Then who wants to code it from scratch? 
I understand VNC.
What are the use cases being addressed?
Would an open source RDP server be an alternative solution.
Does implementing VNC or RDP raise any security issues?
I donāt know the detail but I think VNC might be somewhat a simpler protocol than RDP? I am just guessing based on where I see VNC used vs RDP. I have seen VNC implemented with other graphics libraries for C/C++ development on embedded devices that use graphics displays. (emWin from Segger for example.)
For me, VNC allows easier remote support. A current device we sell is based on Windows CE 6.0. They are almost always on a closed network but a customer can set up their laptop with a cellular connection and allow me access to their desktop. They connect to the closed network via ethernet cable and I can access the devices through VNC remotely on their laptop.
Security is an issue especially if the device is on a network connected to the internet. I donāt have enough knowledge to know exactly how to mitigate the security issues but they are the same you would face with a PC using a VNC server. Our approach is a closed network with no outside connections and only enabling the VNC server on the device when it is needed.
There are lot of VNC viewers in the wild. Compatibility will be a support issue.
RDP has fewer viewers, with Microsoft Desktop being the primary.
Something about putting a āgeneralā remote GUI interface into a dedicated embedded device is bothering me. Must be my security paranoia.
But, I do have several systems running with RDP or VNC interfaces, but none are embedded. I access them remotely via SSH tunneling. Actually, any remote access is always done via tunneling.
IMO, such should be low on priority list.!?
However, my opinion comes form the remote IoT world, where bytes cost more.
I would see the the webserver as @Mike suggested would be a good use of resources.!
We implemented such functionality via OTA connection, where TeraTerm is the client.
Essentially an OTA terminal environment. This environment is only used when there is some āDeepā rooted problem, where such problem is totally unknown. Requires continuous connection.
Otherwise, normally, we OTA commands to remote device (hand-rolled webserver) to gather debug dataā¦based on what are previously known possible problems. Requires a NOT continuous connection.
I have recently wrote a configuration interface over a UDP socket.
This works rather well for all my devices in the field, especially since I added a implementation to update the software over this same socket. 
@Mike letās say we have a large machine with a SITCore controlling and measuring things. There may or may not be a screen by the machine to monitor what it is doing. Now, say I want to monitor things from an office that is few feet away from the machine. I can build a website to do what I need, but wouldnāt it be easier to just run VNC on my desktop and remotely see the same screen from the machine?
Easier yes.
But what would be the performance impact of continually sending screen updates with VNC?
@Gus, seriously though, buy the time I get to the point where my system needs VNC, Iād have been running a pocket beagle (or rpi) with their integrated vnc systems.
Does SITCore even have an MJPEG compression engine?
Running something similar on Android for remote access was slow over GPRS during some testing I did earlier this year and I ended up abandoning the whole idea. I now have auto capture of the LOGCAT and upload this to a server for investigation.
I think the web interface idea is a better solution but it does require that the IP address is visible to the Internet which opens up another can of worms with security and also not possible with GPRS connections in the first place. Teamviewer or similar is my go-to solution for PC desktop systems.
I assume a generic VPN client in TinyCLR is probably not possible.
I think there is a Reverse VNC connection that the VNC Server can initiate an outgoing connection to a listening VNC Viewer. Since this is an outgoing connection it would get around any cellular or routers that forbid connections from the outside.
Les that doing it on a web page I think.
Each system has its advantages. We are comparing apples to oranges.
And for comparison, in fact yes we do but it is not exposed yet 
This is a different issue related to firewalls and applies to everything. There is no TinyCLR limitation here.