I have a .net standard 2.0 dll (Drivers.CommunicationLocal) which is referencing SerialPort class. When I try to use this from a .Net 4.6.1 console app or a xUnit (.net core 2.0) on windows 10, I get the following exception. Using it from UWP app works fine.
System.PlatformNotSupportedException: System.IO.Ports is currently only supported on Windows.
at System.IO.Ports.SerialPort..ctor(String portName, Int32 baudRate, Parity parity, Int32 dataBits)
at Drivers.CommunicationLocal.CommunicationLayerSerialPortLocal..ctor(SettingSerialPortLocal settings) in C:\Users\abc\Documents\Visual Studio 2017\Projects\experiment\senna\src\Drivers.CommunicationLocal\CommunicationLayerSerialPortLocal.cs:line 24
I am using nuget package System.IO.Ports.
cc: @JeremyKuhne, @AlexGhiondea
@harvinders is it possible to boil this down to a minimal repro (would be at least two projects and stub sources) and share for us? I suspect a reference isn't flowing correctly through the project references.
Meantime you may be able to work around this by adding a direct Nuget package reference from your app project to System.IO.Ports package.
I believe the issue is within project.asset.json. I created a copy of the whole project and then removed stuff one by one. I removed the bin and obj and restored the packages. This resulted in a different project.asset.json.
Unfortunately, I can't share it and still trying to have a meaningful minimal repo that reproduces the issue. Sorry about that.
Same here, using 4.6.0 on nuget.
Trying to decompile the System.IO.Ports.dll file (34 KB) copied to my app's directory revealed that it's actually a .NET Framework 4.7 assembly in which all methods in System.IO.Ports.SerialPort throw a PlatformNotSupportedException.
When dig into the nupkg, I can see the file lib\netstandard2.0\System.IO.Ports.dll (34 KB), which was copied to my app's directory, is the incorrect .NET Framework 4.7 assembly. I can find the correct file at runtimes\win\lib\netstandard2.0\System.IO.Ports.dll (71 KB). Replacing the wrong file with this one worked like a charm.
So a faulty packing I guess?
A slight bump: this issue persists in 4.7.0.
Triage: @joperezr this appears to be packaging related, can you take a look?
The package isn't correctly authored, my guess here is that the way that net461 project is consuming the package is via packages.config which won't produce an assets file so it's just bringing the same implementation picked by the netstandard assembly. It would really help if we could get a binlog to confirm my suspicions.
Here is a way to work around it:
<PropertyGroup>
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<RuntimeIdentifier>win</RuntimeIdentifier>
</PropertyGroup>
msbuild yourNetFrameworkProject.csproj /t:RestoreAfter running the above steps, I'm getting the right System.IO.Ports placed in the binfolder and I'm able to run correctly. Please give that a try and if it doesn't work let me know so I can investigate.
Maybe to add to this issue, we have a smiliar problem in our project and I tried to boil it down into this simple repo https://github.com/JonasGoldt/PortsPackageProblem
There are two projects, both targeting dotnet core 3.1. One class lib and one test. The test references the class lib.
The problem occurs with the library reference "Test"->"Library". When running the test, it loads the System.IO.Ports directly from the output folder, instead of the correct runtimes/win... version.
The workaround mentioned by @danmosemsft works, but we have more complicated cases, e.g where we load unknown libs at runtime.
For now, we copy the correct Ports assembly into the output folder ourselves.
Still persists in v5
Most helpful comment
Still persists in v5