SerialPort Support on Windows

[shaggygi]

Just wondering if SerialPort namespace will be included at some point?

---

Execution plan

• 1. @JeremyKuhne to seed the sources in CoreFX (from full .NET Framework) - add source code (sanitized, with licenses), the source won't build
• 2. Make the code build
  • CC: @JeremyKuhne @karelz on PRs
  • Note: We will not take any functional changes to the implementation, architecture, or API surface at this point unless they are absolutely necessary to make the code compile on .NET Core. Please give heads up on this issue as soon as you discover cases like that.
• 3. Add tests - tracking progress in dotnet/corefx#15752
  • @JeremyKuhne to find out if we can leverage full .NET Framework tests
  • We need to design the test environment - we need ability to test the code in CI (ideally without heavy modification of CI machines)
  • We need to set goal for code coverage

If anyone is working on any step, please mention it & coordinate here to avoid duplicated effort. @karelz will co-assign the issue to you as well.

[Maxwe11]

👍 for supporting communication over serial line in corefx.
It could be existing SerialPort class however I'd prefer new more reliable api based directly on Stream.

[sawilde]

There are a few nuget packages that already provide this capability as there are such a small number of downloads it makes you wonder what the demand is.

[shaggygi]

@sawilde could you provide a link for those? I would like to try them out. Thx

[sawilde]

http://www.nuget.org/packages?q=serial

[shaggygi]

Thx

[ellismg]

My general feeling is that Serial Port is not a good long term fit when you think about foundational libraries of .NET Core, and hence we wouldn't include it in the CoreFX project. The current SerialPort class source is MIT licensed now, as part of the .NET Reference Source project, so folks are free to take it an run with it.

In general, I think we'd like CoreFX to be a set of libraries that are useful across the entire .NET ecosystem. That includes devices like Phones, Severs, Tablets where a serial port library is unlikely to be useful.

[Maxwe11]

Serial Port is not a good long term fit when you think about foundational libraries of .NET Core

.NET ecosystem. That includes devices like Phones, Severs, Tablets where a serial port library is unlikely to be useful.

What the problems to use SerialPort on server? It's a powerful "tool" like pipes or sockets.
.NET ecosystem now includes Linux and Mac, but Win32.Registry presented in corefx.

[ellismg]

@Maxwe11, I'm interested in understanding more about how serial pots would be used in server scenarios. I can see how both pipes and sockets are useful in general for IPC, what sorts of uses does serial port have?

You're right about CoreFX containing some Win32isms, However, we are doing our best to minimize the set of types that pull in Win32 concepts. The desire to be able to run stacks like ASP.NET vNext requires that we bring in some components that are windows centric and will be hard to support on Linux and Mac, but when possible we are trying to be explicit in the surface area we add to the core, to make sure it's suited for a wide range of platforms and devices.

[shaggygi]

@ellismg I can see your point of view on this topic as there were several discussions why serial port capability was not provided out-of-box for WinRT. However, this feature is needed all the time in some industries like building automation. In addition, if corefx is expected to be used with embedded devices, those type of applications use uarts quite a bit.

I would agree it might not need to be included as long as there is a package we can include and hopefully be cross plat as well. Thx

[shaggygi]

One other note... I've also seen cases where data cables were needed to connect between pc/tablet/phone via USB to devices for serial communications (232, 485). Having this feature would support these types of apps.

[Maxwe11]

I'm interested in understanding more about how serial pots would be used in server scenarios. I can see how both pipes and sockets are useful in general for IPC, what sorts of uses does serial port have?

As mentioned by @shaggygi: for communicating with embedded devices.

[shaggygi]

I don't recall adding anything about using with servers. If so, it must have been a typo.

[akoeplinger]

+1 for SerialPort, it is still widely used in industrial/embedded systems.

I'm not sure whether we need it in corefx though, having a separate package should be fine too (after all, better modularization is one of the benefits of the new model). Maybe it's time for dotnet/extendedfx 😄

[Tragetaschen]

I don't really care if it's from corefx or any other repository as long as it's coming from Microsoft. In the past, that always meant a certain level of quality.

[kangaroo]

I agree with @ellismg, this isn't a corefx problem. This is a problem, that begs for a community contribution of a fantastic nuget package!

[Maxwe11]

I don't really care if it's from corefx or any other repository as long as it's coming from Microsoft. In the past, that always meant a certain level of quality.

Agree with it, but for now SerialPort not supported even in PCL

[sawilde]

@shaggygi

And not a third-rate quality package

did you check out the nuget packages that are currently available? If not suitable - why not? Could you improve on them?

To create a 'quality' serial port library requires a certain level of knowledge I suspect - who has that knowledge... well those that need a serial port library. There are not many of you out there so rather than wait for someone to build a library, whilst making all the mistakes you would expect from someone learning the domain, perhaps it is something the 'serial port user' community should do - create a github repo and share your knowledge to create the .NET serial port package.

[shaggygi]

@sawilde I believe my post was out of context, so I removed it. I'm really content with the API provided in .NET and I'm sure the other packages will probably work. I was just hoping what is provided to work with corefx will be easy to use similar to what I've always used in the past.

[terrajobst]

As @ellismg said above, the source is available. I've marked this as up-for-grabs. If anybody wants to take a stab, let us know!

[n8allan]

I was hoping that .NET on Linux would potentially give me a solution to the problem I'm having with the rather poor implementation of System.IO.SerialPort in Mono. I would note to Sawilde that all of those NuGet packages related to serial communications are either something else or built on top of the SerialPort class. I know of no comprehensive replacement.
My +1 on this, either as part of the core or as an add-on. Whomever works on this, please do not repeat the poor error handling job done by Mono on their implementation. See this bug report for example.

[ruben0909]

+1

[ghost]

Besides mono implementation, node.js community is having similar discussion: nodejs/node#1546 as libuv's support is on its way: libuv/libuv#484 (which would work on Linux, Windows, OSX and FreeBSD).

Once that is implemented, and libuv is an OK dependency to carry (perhaps @KrzysztofCwalina can verify), we can consume it via https://github.com/txdv/LibuvSharp or https://github.com/dotnet/corefxlab/tree/master/src/System.Net.Libuv. Otherwise, we would need to implement the native shims for serial port.

[n8allan]

As I recall, Silverlight added serial port comms at one point. If so, shouldn't there already be a portable implementation of serial comms out there for the taking?

[ghost]

But Silverlight is not open sourced. Either we can wait for it to get in open or we implement shims to cover the serial port API implementation. I think latter is more actionable and aligns with DIY philosophy of GitHubbies. :)

[JammersHammer]

I see serial port communications as being important. We have an app that talks to serial based equipment at asphalt plants and other areas of our business. The developers of those devices are slowly (real slow) moving toward other means of communications such as across an Ethernet cable but for the time being, serial communications is still quite important. If there are other outside libraries (hopefully free or Open Source), then they may be worth looking into but up until now, we've worked quite well with the libraries are part of the current .NET. This newer .NET CORE may not be an option for us to go to due to this library possibly being omitted from it. This hurts (not helps) our business.

[n8allan]

I see serial port communications as being important.

Absolutely true @JammersHammer, and especially true in the embedded space where serial communications–whether over TTL, bluetooth, or whatever–are still a primary means of inter-device communication.

[patryk9200]

It's must have library for all IoT development. For example, I need SerialPort for communication with Z-Wave, ZigBee etc. & other IoT communication related stuff.

[abdullah2993]

+1 for serialport
My asp.net core app needs to communicate to a GSM modem over Serial

[darkurse]

+1

Some might not see this feature as useful or even too old fashion to be relevant. but like it or not many industries are still HEAVILY reliant on this old technology.
And yes, these industries should probably move to more modern ways of communicating for all the reasons you can think about. But from experience - they probably won't. The first reason being the financial effort they would need to provide in order to renew all their h/w ! Writing s/w that can run on 1000 devices is always gonna be cheaper than buying 1000 new devices.

Regarding available alternatives on github/nuget, no offense but between Microsoft quality grade library and unknown 3rd part libraries quality grade, I am NOT thinking twice about what choice I am going to make ;)

Anyway, that's my 2 cents.

[willdean]

I'd like to see people create new issues for more specific things and not just keep appending to this one - I don't think renaming this one is really appropriate as everything has already been discussed here. Is it possible to post some final message with the current state of progress and then lock this issue?

[danmoseley]

Im' going to be bold and close this one. Well done @willdean and collaborators for this achievement! I'll open one for Linux, @shaggygi feel free to open one for RPi.

[jefffhaynes]

I think it's a shame .NET Core went with SerialPort over SerialDevice. SerialPort feels dated whereas SerialDevice can mean UART a la Windows IoT.

[willdean]

@jefffhaynes Do you just mean the name of the class?

[jefffhaynes]

Well I like the (UWP) SerialDevice API as well but yeah, I mostly mean that the name suggests a COM port vs something more generic.

…

--------------- I much prefer the sharpest criticism of a single intelligent man to the thoughtless approval of the masses - Johannes Kepler

________________________________ From: Will Dean <notifications@github.com> Sent: Tuesday, May 9, 2017 3:40:19 PM To: dotnet/corefx Cc: Jeff Haynes; Mention Subject: Re: [dotnet/corefx] SerialPort Support on Windows (#984) @jefffhaynes<https://github.com/jefffhaynes> Do you just mean the name of the class? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://github.com/dotnet/corefx/issues/984#issuecomment-300278749>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJSKR05O5x0tkYXTdUVs7anl0POl8HDwks5r4MEjgaJpZM4Dj7O4>.

[willdean]

@jefffhaynes The merit in migrating the existing SerialPort class is compatibility with existing apps - I don't think anyone thinks it's the best possible interface (though personally I think it takes a lot of blame for stuff which is actually broken elsewhere). If you value backwards compatibility, then a mere name change might just feel like gratuitous breakage.

It's not like it's called ComPort after all :-)

[jefffhaynes]

Yeah, fair point. I think I keep forgetting that part of this is maintaining the lineage. Sure would be nice to shed some debt...

…

--------------- I much prefer the sharpest criticism of a single intelligent man to the thoughtless approval of the masses - Johannes Kepler

________________________________ From: Will Dean <notifications@github.com> Sent: Tuesday, May 9, 2017 3:54:33 PM To: dotnet/corefx Cc: Jeff Haynes; Mention Subject: Re: [dotnet/corefx] SerialPort Support on Windows (#984) @jefffhaynes<https://github.com/jefffhaynes> The merit in migrating the existing SerialPort class is compatibility with existing apps - I don't think anyone thinks it's the best possible interface (though personally I think it takes a lot of blame for stuff which is actually broken elsewhere). If you value backwards compatibility, then a mere name change might just feel like gratuitous breakage. It's not like it's called ComPort after all :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://github.com/dotnet/corefx/issues/984#issuecomment-300282546>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJSKRy7CtMV6Ic6xpnsVhEeDEhSNbWD6ks5r4MR5gaJpZM4Dj7O4>.

[shaggygi]

I'm trying out VS 2017.3 preview and don't see System.IO.Ports. Is this not out-of-box now or is there something I need to reference? Using both .NET Core and .NET Standard Class Library projects.

[karelz]

@JeremyKuhne @weshaggard do you know where to find the preview package for System.IO.Ports?

[shaggygi]

I checked the pre-release box in NuGet Manager and there is a 4.4.0-preview1-25305-02. Is this the version we should be trying? Was released on 5/9/2017.

[weshaggard]

Yes that is the preview1 package.

[tyskink]

what about the Windows.​Devices.​Serial​Communication Namespace?

[shaggygi]

@tyskink Not sure if I understand the question. I believe this API is for UWP and not a good idea to use in CoreFx as the name implies Windows... which wouldn't be cross-plat.

[karelz]

Correct, that namespace is WinRT OS APIs. It is consumable from all languages - C#, C++, JScript, etc. It is not implemented in managed code, it is part of the OS.

[JeremyKuhne]

what about the Windows.​Devices.​Serial​Communication Namespace?

For the Windows UAP implementation we might be forced to use some WinRT APIs. We can't use them universally on Windows as we need to support back to Windows 7.

[philcarbone]

+1 Serial Port Support. We have several USB projects in the pipeline. Most of them need to be multi-platform too. IoT, it's a thing. :)

[danmoseley]

@philcarbone just to be clear, you are asking for Unix support? Windows is already done.

[p5ych08illy]

@danmosemsft, maybe @philcarbone is asking for dotnet/corefx#18023, the Windows IoT support. Do you know anything about the W IoT support?

[philcarbone]

Hi @danmosemsft and @Psychobilly87. I was asking for both Unix and Windows. I'm super excited to hear that Windows is done. Sorry, I hadn't finished reading through this entire thread yet. Thanks for the info! I am going to start using the Windows support in the next 2 weeks. Windows IoT is something we will use, but isn't time sensitive for us.