views:

168

answers:

3

I am wondering why the .NET framework does not provide any managed methods for working with USB drivers. From everything I have read you still have to call into Windows API's and use marshalling and PInvoke and all that crap that none of us .NET programmers want to have to do. Why does .NET provide methods for communicating with serial ports but not USB ports? USB has become much more widely used that serial ports now, isn't it time they incorporated it into the Framework?

+8  A: 

Like all other features in the .Net framework it comes down to cost vs. reward. With every release of .Net the owners have to make very painful cut decisions for features. There are simply too many requests / wants to satsify them all. The ones that are chosen need to provide clear value at a reasonable cost.

My guess is that Serial Ports, while probably less popular than USB, are simply easier to implement in managed code. Hence even though the use may not be as high, the relative easy of implementing them put them over the top.

JaredPar
Another factor is that many USB devices expect the interaction to come through their driver and not the USB interface directly. Then there are situations where serial is a more practical choice (ie: timing critical operations, data acquisition, legacy hardware, etc). USB may be more popular in a consumer world but serial is still alive and kicking.
Cory Charlton
A: 

If you're looking to interface with an HID compatible USB device you might take a look at CC.USBHID. It's old and nasty but might get you going in the right direction. There might be more mature projects available.

Cory Charlton
+2  A: 

USB is just a bus. The way you communicate to the device depends on the chip at the other side of bus. There isn't a standardized way to talk to all devices.

If a USB device provider want to expose the device to a standard way (most of them do conform to standards to save costs on develop, document, and educate clients about their APIs), their driver programmers can write drivers that make the device available to various Windows APIs (massive storage, WIA, DirectShow, virtual serial port, bluetooth, Human Interface Device, etc). Again, since standardized drivers are already exposed to Windows API, there is no need for .Net to talk to hardware directly.

Sheng Jiang 蒋晟
+1 for good info.
Si