I use an IP enabled serial port to debug NETMF with, it works some of the time. I have not captured a trace of the discovery process where the debugger attaches.
Question is does GHI Electronics or Microsoft maintain this functionality? I would like to file a bug / feature request.
@ PHITEK - I would start a separate issue to look into the problem you may be having.
@ John - Ok that would be great, let me get together some trace logs, of the serial port traffic and further details.
Is this likely to be released before Christmas?
It would make a good present for me? 
I have 2 projects stalled just now waiting on the PPP to use the SIM5320E and I just received the US 3G version of the module and my client is jumping up and down to get a unit from me.
One thing I found an issue with and that is with GLIDE when the keyboard is present.
I have a screen where I update the display with data in the main display thread and if a user clicks on a button to edit one of the other fields, the screen still updates because I have no way to know if the keyboard is present.
I downloaded the GLIDE source and built my own version which sets a flag when the keyboard is visible on the screen and I can then test for this and stop any updates. I added a function called:
/// <summary>
/// Returns true if keyboard is visible
/// </summary>
public static bool isVisible()
{
return (keyboardVisible);
}
The bool keyboardVisible gets set when the keyboard is shown and cleared when it closes.
Can you add something like this?
@ John - My serial port debugging issue, seems to be an issue with my IP enabled serial port. I have used the device for over three years, so it was kind of unexpected for it to fail right as I decided to use it for some USB development work.
Thanks for your attention on this matter.
Virtual serial ports will not work because of the delays that, by design, come with visual ports. Visual studio will internally timeout due to these delays.
@ Gus - I donāt consider these āvirtual serial portsā, they are actual serial ports connected to a microcontroller that happens uses the network, instead of a physical connection to the PC bus, ie: PCIe or PCI to pass the serial port traffic.
Once I change the to another IP enable serial port unit, it seems to be working fine. That was my initial concern as well about timing of the Visual Studio and / or the debugger within NETMF to tolerate the extra delays the network may introduce.
Right now I am testing on my local network but next week I will test from my work place, to handle the extra firewalls at each end. I have a lot of USB devices using the custom interface to get working, so having the serial port debugging rock solid will be important to me.
I could provide a link to the actual product, but did not want this to be considered an āadā, they are popular to connect cash registers to corporate office, surveillance cameras positioning systems, on the factory floor to connect printers and displays to a controller, and for me I want to have the debugger connected to a system controlling a centrifuge, running in the lab from my desk.
Thanks for you input, will post back here on my testing next week.
It isnāt easy to get a system which has non-virtual serial ports these days, they are almost always USB based virtual ports, which bring with them various handshaking and timing problems. Back in the 80s I wrote a serial protocol for use in industry, single master multiple slave polled with timeouts on missing slaves, for use over RS232 and RS485 networks. Started out directly connected to VAX serial ports, then remotely using LAT servers, then Unix with LAT, USB virtual, and now mainly remote virtual serial ports via IP devices like you are using. Timing is always an issue, but we generally manage to keep things going.
First make sure you have the basics set up correctly, ie 8-bit data, no XON or other SW handshake, hardware handshake either disabled or set up correctly on the ports.
The devices usually like to buffer as many serial characters as possible before bundling them into a network packet, and this is the most likely cause of delays. They can be set to trigger a send on a specific character or characters, such as a line-feed. This isnāt helpful for binary traffic and should be disabled. Next there is generally a timer and possibly a character count, so that you can say send the packet if no characters are received within 200mS from the last one. To minimize the effect of timing delays you are probably best to set this fairly low for a start, maybe 5mS or less, so characters are sent as soon as received, and to send on a single character. You may need to tune this once you have things working, the packet overheads are way higher than the payload and especially once you are off your local subnet you can actually cause more delays this way through network congestion. The device may give you an option to set the packet ToS to give you routing priority. Not really a concern for an unloaded local net, but could help for long-distance remotes.
Apologies if you already have all of this under control!
@ Gus - Sorry Gus, my mistake these can be consider virtual serial ports. I was thinking a serial port access from inside a hypervisor.
@ C-born thanks for the info.
As C-born noted, a USB serial port is very common now days, may very likely be needed when debugging from Visual Studio, so my hope is that virtual serial ports can work reliably with Visual Studio and NETMF.
Latency on usb is a lot shorter than on networks.
@ GUS
Any idea about release date 2015 R2?
I understand GHI likes to limit the number of releases. Though I preferred the days with more and faster beta releases.
I am stuck now for weeks with my project due to a fatal bug in the CANbus driver (crash) on CerbII. The bug is solved (thx for fine GHI support on that) BUT NOT RELEASED.
It is done and we are doing some testing.
I nice Christmas present perhaps?
Pretty please Mr Gus 
@ John. If it is not too late to add anything else, you might want to add the issue with SMS sending that I mention in this thread.
https://www.ghielectronics.com/community/forum/topic?id=22334&page=1#msg208282
@ Dave McLaughlin - Unfortunately it is too late for this coming release, but we will take a look after it.