I'm facing a problem like a lot of others during the last few years and
Microsoft doesn't seem to care about it :-(
The problem (one of them) is with the Microsoft bluetooth stack that saves
the virtual com ports without the 0 terminating char in the registry. That
causes the SerialPort.GetPortNames() to return garbage strings for the
bluetooth ports.

Well, Googling around the Net didn't help much - I'm simply not able to
find a workaround solution, so I'll pop the question here: Anyone found a
solution?

Thanks for all your help,
Ole

"Ole" <(E-Mail Removed)> wrote in message
news:%23$%(E-Mail Removed)...
> I'm facing a problem like a lot of others during the last few years and
> Microsoft doesn't seem to care about it :-(
> The problem (one of them) is with the Microsoft bluetooth stack that saves
> the virtual com ports without the 0 terminating char in the registry. That
> causes the SerialPort.GetPortNames() to return garbage strings for the
> bluetooth ports.
>
> Well, Googling around the Net didn't help much - I'm simply not able to
> find a workaround solution, so I'll pop the question here: Anyone found a
> solution?

My method works with all virtual com ports, although it'd be a bit of work
for you.

Basically, use SetupDi* to enumerate ports from device manager (and
RegisterDeviceNotification if you want to detect hotplug events, like
inserting of a USB bluetooth dongle) and CreateFile to open the device
instance path. If the .NET SerialPort class didn't require all ports to
start with "COM" then you could use it after enumerating yourself, but as it
stands you need a whole new I/O layer.

I highly recommend C++/CLI for the I/O layer, creating an interface usable
from C#.

>
> Thanks for all your help,
> Ole
>