.net core

[davidbitton]

Has this been tested against core? I would like to be able to use it for both Mac and Windows. Thanks!

[jcurl]

No it has not been tested against core. I don't know enough about Core to know what needs to be done, but if you're willing to try, we might be able to determine together if it can be supported.

[davidbitton]

Will do.

[jcurl]

To get the software working on the Mac will require a little more work. I expect some code changes here. You'll need to compile the native library in dll using a compatible compiler to gcc and cmake. I use Mono on ubuntu, but I try and avoid the dllmap configuration, instead relying on the explicit name of the so. In principle I expect not much work to get it going, but I don't expect the Mac to work out of the box. Using core on Windows should be much better, but I'm not familiar with any restrictions - can one still use p/invoke? I might have serialization somewhere that might not be supported.

[davidbitton]

I'm looking into the cross platform serial lib. I was able to compile it on my Mac.

[tspeckert]

I made a very rough proof-of-concept here: https://github.com/tspeckert/SerialPortStream/tree/netcore_prototype

You can see the changes I made to your code on this commit (there are some accidental "cosmetic" code-style changes.. ignore those): tspeckert/SerialPortStream@50234e3f75703a4b5331edd8cb87bc1ec387866e

Changes:

• For simplicity's sake, I removed the GetPortNames() and GetPortDescriptions functions
• Begin/End Read/Write were replaced by Read/Write Async (using Tasks)
• To save time, I simplified the Unix "ThrowException()" method since the Mono.Unix.Native namespace is not available
• Replaced ApplicationException with InvalidOperationException
• some other minor stuff

I did a rough hardware test using a couple of USB-serial devices, and it seems to work on both Linux (Ubuntu 16.04) and Windows (7), Mac support was not attempted.

[jcurl]

Great! How do you feel about making it a branch, instead of copying all the code so it's easier to see the diffs? At the end, I would look at how I can build it using the build.bat but with a /p:DefineConstants via the command line.

[jaime-olivares]

This will be a great library for .net Core, you should focus on delivering a nuget package for it. I think you will have more downloads for this platform than any other.

[VitoDeCarlo]

Agreed! I'd love to see this working for .Net Core!

[jaime-olivares]

I have tried @tspeckert 's code in dotnetcore and works well so far in Windows. Also tried with netstandard and worked for 1.6 but not for 1.3, as Assembly.Location was not supported.

[jcurl]

The software is not particularly difficult, although there are a couple of things the community can help by providing their input. I personally don't use .NET core and understand its specialties which I'd like to investigate first (and unfortunately, other projects also have an important impact on my time)

1) Packaging: NuGet is the packaging platform used with the 'dotnet' tool. Should the package be part of the existing NuGet package (and then what should the subdirectory be?); or does the .NET core community prefer a new separate package? Once a package is defined, who's willing to test it before it goes public? I want to avoid going the "JSON" route for packaging can .NET core still cope with building NuGet packages using the XML format?

2) What is the best way to test the packages against a small test program say, both on Windows (I use Windows 10, but it should work on Windows 7), as well as Linux (preferred platform Ubuntu 16.04.1).

Looking forward to your replies.

[jaime-olivares]

I am not a nuget guru but I think a .net-standard-1.6 package will fit all modern .net platforms including core.

[tspeckert]

@jcurl Sounds like a good idea - I should have some time in the coming weeks to do this!

[VitoDeCarlo]

I'm not sure what happened, but as of this last Windows security update, I'm receiving an Unauthorized Access Denied on my COM3 port.

Here's the update that came in: https://support.microsoft.com/en-us/kb/3200970

Is anyone else experiencing this issue? Is there a quick fix on my end that would allow me to continue developing against this for now? Even if it's a setting on my computer to give me rights.

[VitoDeCarlo]

Hmmm... I thought I was having DCOM issues, and although I'm still receiving the error, I'm actually able to use the COM port.

It's failing at the File.Create command, at lines 763 of of WinNativeSerial.Open() command.

By the way, In my crazy hours of programming, I had forgotten when I wrote this. I actually had reinstalled Windows, due to issues I had using the new Visual Studio 2017. So something I had set a while back is most likely reverted to normal. If you know what it could be, let me know. :)

[jcurl]

It's likely that COM3 is being used by another process.

[maitredede]

Hi, I am interested to get a port of this lib for dotnet core.

Porting to dotnet core will not be easy if you start using native code in your libraries.

For Windows x86 or x86_64, you can p/invoke the dll, it is easy. For Linux, you said that you use a native lib. You have to consider that this lib can be used on x86, x86_64, ARM, or ARM64. I don't know for Windows ARM or Mac.

Even the corefx team has not decided where to start : see https://github.com/dotnet/corefx/issues/984.

[jcurl]

It was a tough design decision to use a part of native code was difficult. In the end, I decided it was more portable for POSIX systems to use a helper library that is compiled against C. The values for baudrate, the termios structure are probably all different across different OSes, but would share just a single C source bsae. A system integrator can prepare the DLL's for their system accordingly and package it with their installer (assuming they have CMake and a compiler that works).

The biggest blocker I have to creating a .NET library is not the code changes, but figuring out the best way to deploy it. I'd want one code base for all, but should I have one NuGet with three binaries, or have a separate NuGet only for .NET Core? And I would prefer to build everything just using VS2015 tools on one platform. I admit I haven't found very much to help me make this decision.

[maitredede]

Hi @jcurl , I understand your "best way to deploy" questions.

As an example, I think SQLite for EFCore is the nearest of what you need. The SQLite provider for EFCore has a realy easy deploy solution : one package to reference. The interesting package in your case is the https://www.nuget.org/packages/sqlite/ that contains native libraries. I use Nuget Package Explorer to see its contents, and there is one native dll (or .so or .dylib) per runtime. I will search for the toolchain and sources to build this package, since I am also interested in how to build cross-plateform packages that use native code.

[maitredede]

In the docs of UWP packages, there is info about native multiplateform packaging.

[jaime-olivares]

There is no reason for having separated nuget packages for different plaforms. All them can coexist in a single nuget package.

[maitredede]

Hi, there is a discussion of dotnet core about serial port here : https://github.com/dotnet/corefx/issues/984

[jaime-olivares]

Have a look at the PR: https://github.com/jcurl/SerialPortStream/pull/13

[thedumbtechguy]

I tried out the Core version from nuget and it worked fine, albeit requiring me to import a very specific interop.runtime package version (I'll update later when at my desk).

Im running on Windows currently.

[jcurl]

It's been a while. I plan to look at this next week when I have time off from my job and I can spend time ramping up on dotnet. Sorry for the delay!

[jcurl]

Any idea how to catch EntryPointNotFoundException? It's raised, but doesn't appear to be exposed anywhere. Catching the type Exception seems to work, but feels kludgy.

In particular, as I upgrade my library, I add new API's. To keep backward compatibility, I test if that API exists or not, and if it doesn't, fallback to default behaviour. This is how I implement finding the list of all ports, in case the user doesn't install or update the latest version of my libnserial.so library.

[jcurl]

Please look at the branch feature/netstandard15. This contains an update to the master which I've now pushed. It compiles for me using VS2015 U3 + .NET Core extension. I want to still look at the build script and how I can use this. Still need to test on Ubuntu.

Exception handling on Linux is broken, as there's no built-in way to map errno to exceptions, unless I'm mistaken.

[jaime-olivares]

@jcurl EntryPointNotFoundException is not supported by netstandard 1.x, you may need to wait until 2.0 is widely adopted.

[jcurl]

Still learning .net core. When that happens, I assume a new project in a folder netstandard20 like you've done? By the way, when I opened the xproj in VS2015u3, I wasn't able to manipulate the NuGet packages as I could if I made a new project from nil. Any idea what the problem is?

[jaime-olivares]

Yes, you can compile a different project for .net standard 2.0, but it is not widely adopted yet.

[jaime-olivares]

Not sure how you manipulated nuget packages before. I have used the command line tool for generating a valid multi-platform nuget package.

[jcurl]

On Windows, I create the nuspec package, compile everything (using the bat file) and run "nuget pack serialportstream.nuspec -symbols". It's not creating my nuget package, it's updating the .net core packages. For example, when I go to VS2015 Manage NuGet Packages, I would have expected to see .NET Standard 1.5 and that it's upgradeable.

[jaime-olivares]

I think VS2015 doesn't have a complete support for .net standard, you may need VS2017 for better support. I use VS Code instead.

[jaime-olivares]

Hi @jcurl, are you generating a nuget package for the .net standard version? either separated or together with the .net framework version

[jcurl]

Hi I plan to have one nuget package for all. Before I release, it would be great to get feedback on the last one I generated, to exclude any unforeseen problems. I could probably do a release this weekend