Added support for .net standard (.net core & .net fx 4.6.x)

[jaime-olivares]

As mentioned. It compiles well with Visual Studio Code. The changes don't interfere with the current implementation for .Net Framework and Mono.

The compilation instructions are in /netstandard/readme.md

[jaime-olivares]

Hi Jason, the reason is that .net standard doesn't implement ApplicationException.

Alternatively I can put more #if's in those cases, but I suggest to take whatever .net standard offers, as it will the unified .net framework in the near time.

[jcurl]

I have a couple of questions before I continue with the pull request. As I'm only using .NET 4.0, how do you run nUnit test cases on the .NET Standard? Can you modify this pull request for the nuspec package?

[jaime-olivares]

Regarding testing, a .net Standard library is compatible with the last frameworks including .net Core and .net Framework 4.6.x, so it is only a matter to configure the same tests using any of them and referencing the .net Standard library.

[jaime-olivares]

@jcurl This time I have used VS 2015 for building the project. I have generated a related .xproj file. I hope there is no conflict with the version of Visual Studio you use, as I see some differences in the .sln file. Also I have updated the .nuspec file for targeting both .net framework 4.x and .net standard 1.5

[maitredede]

Hi, Shouldn't it be better to use a more typed exception than the generic one ? Like InvalidProgramException ?

[jaime-olivares]

According to MSDN:

InvalidProgramException - The exception that is thrown when a program contains invalid Microsoft intermediate language (MSIL) or metadata. Generally this indicates a bug in the compiler that generated the program.

It doesn't seem to be related to the cases where I switched to Exception.

I don't think there will be more added-value in finding 'any' other exception type, as the cases where I switched (unexpected code flow, unknown parity) are very unlikely to happen. The value of the exception will be increased with a more verbose exception message, in my honest opinion. Anyway, this is totally up to the author.

[jaime-olivares]

@clegendre I modified the references in project.json as suggested

[jcurl]

Any reason why you went with netstandard15 and not netstandard16?

[jaime-olivares]

I have had several issues trying to use .net standard 1.6 with .net 4.6.2 (windows), which is currently the latest stable release. A .net 4.6.2 application doesn't accept a .net standard 1.6 library.

[jcurl]

Interesting. According to nuget, if you use my nuget package, it will pull in the net45 target framework moniker. Is this a usecase that you need, using the netstandard library with net462? Why not use the net40 version?

[jaime-olivares]

4.0 doesn't have any kind of support for .net standard. It belongs to the "old-generation" versions. Have a look at the map of versions (taken from https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/). You will better understand the relationships. Net Standard 2.0 is the future of all the cross-platform frameworks, but still not supported.

[jcurl]

Thanks for the link. I've seen this before, I was worried about your scenario of using .NET 4.6.2 importing .NET Standard 1.5 when the .NET 4.0 implementation (which is also loadable using .NET 4.6.2). Is it because you have a .NET Standard 1.5 library that then uses mine, then that is used in your.NET 4.6.2 package? I'm trying to ascertain what it means for my nuget package, where the monikers net40, net45, netstandard1.5 are all present.

[jaime-olivares]

Currently 4.6.x is a good choice whenever building a set of applications that rely on .net standard libraries. I have a set of applications for Windows, Linux and macOS (netcore CLI, asp netcore, and desktop) sharing many .net standard libraries and all them work smoothly with .net standard 1.5. Of course I am just waiting for the adoption of 2.0 so I can expand the supported platforms keeping a single code base, but that may take many months.

[jcurl]

Would this nuget package work for you? it's the current state of the feature/netstandard15 branch. It should keep the API's that you created your package with, but includes three frameworks.

serialportstream.zip

[jaime-olivares]

Cannot test it unless published in nuget.org, but there is not reason why not.

[jcurl]

You can use NuGet to add a new package source (e.g. a folder on your local directory), rename the symbols file to the nupkg file and just use a nuget update. I feel uncomfortable publishing non-tested software as no stability is guaranteed between that and the next version. Other users might be confused.

[jaime-olivares]

According to Nuget Package Explorer, that nuget file only supports .net standard 1.5. I already have tried to do that by myself and it works for me: https://www.nuget.org/packages/SerialPortStreamCore/2.1.0

[jcurl]

Weird. For the ZIP file I uploaded, the NuGet Package Explorer shows me (SerialPortStream.2.1.0-beta1.symbols.nupkg):

• lib/net40 (.NETFramework,Version=v4.0)
• lib/net45 (.NETFramework,Version=v4.5)
• lib/netstandard1.5 (.NETStandard,Version=v1.5)
• src/

The dependencies for .NETStandard,Version=v1.5 are now defined, based on a previous comment and copied from dotnet pack (but I didn't use this package that was generated).

[jaime-olivares]

oh sorry, I didn't open the file tree, only saw the dependencies list which only mentions .net standard 1.5. In fact I can see all what you have mentioned.

[jcurl]

I've made a few internal changes, which you can review on the feature/netstandard15 branch. Your rebased commit is there, and my commits on top. When everything is finalised, I'll be squashing it down to two commits (or one). There is some work that still needs to be done, but just to handle exceptions properly under Linux (there's no errno to exception mapping in .NET Standard as far as i can tell for P/Invoke).

[jcurl]

I've just noticed one problem I need to fix. i'll be renaming the .NET Standard binaries also to RJCP.SerialPortStream.dll to be consistent with the other packages.

[jcurl]

A modified version is now in the v2.x branch, supporting port lists and proper exception handling on Linux. Some refactoring done too.