Runtime: Packaging for System.IO.Ports.Native/System.IO.Ports

[krwq]

Currently System.IO.Ports is an OOB package depending on netstandard2.0 but linux implementation also depends on native component System.IO.Ports.Native.so which ships in box in 3.0. This is causing runtime errors that the component is missing when System.IO.Ports package is used with netcoreapp2.X.

Currently our build is not ready for shipping OOB native packages (it's not trivial to do it).

Here are example ways to fix this:

• add support for OOB native packages
• remove native component and replace it with platform dependant managed code

OOB is also using PInvokes to native shims which are private components of .NET Core.

cc: @jkotas @wfurt

[jkotas]

Currently our infrastructure doesn't support shipping OOB native packages.

What would it take to fix out infrastructure to support OOB native package? It would be the most appropriate way to fix this.

[ericstj]

The infra supports this, it's not a matter of supports vs not, just that we don't have examples to follow so @krwq would need to blaze a trail here. With no build changes to join cross-distro output we could produce a package structure like SqlClient today without any build work. We were doing similar things in 1.x. With build changes and/or packaging in core-setup we could join the cross-distro assets into a single package.

I'm concerned about the native dependencies here, since we made a concerted effort in the past to put everything with native dependencies in the shared framework so that we didn't have to worry about versioning of the native shims. There's nothing in the process today that validates the native exports from our shims in 2.0 (though we could repurpose the PInvoke checker to do this).

[krwq]

Package restores correctly and all published apps contain correct binaries