System.IO.Ports should not depend on System.Native

[ericstj]

We don't consider System.Native to be a stable public API, yet System.IO.Ports depends on it. This can cause someone using an older System.IO.Ports to break when running on a newer shared framework where we update System.Native.

System.IO.Ports should remove this dependency, for example by including the same exports in its own native library, or eliminating the usage by moving functionality into the assembly.

We could potentially add validation to our packaging to catch this (we already analyze assemblies for DllImports here).

[krwq]

cc: @maloo this should fix the issue you have mentioned in #35545

[maloo]

Great, do you know if anyone is working on this issue? Seems to been idle for a long time. And without this fixed there is no way of using SerialPort in net core 3.1 LTS.

[krwq]

Likely myself or one of the co-owners will pick this up soon. Note this fix won't be available for this preview anyway, I'm targeting preview5 for this fix (or whatever we name what comes after preview4).

I'm planning to pick this up possibly early next week. As a workaround for you in the meanwhile I recommend removing Flush and use older version of the package (which we shipped in 3.1 timeframe).

[maloo]

Prefect, let me know when there is a nuget (nightly or others) and I will test it. Unfortunately I can't just remove the Flush, it is other .Net frameworks that is calling it. My example was just the result of tracking the issue down into a minimal repro for issue reporting. One framework that is calling Flush is this one (the one that got me into this issue): https://github.com/dotnet/runtime/blob/master/src/libraries/System.IO.Pipelines/src/System/IO/Pipelines/StreamPipeWriter.cs#L308