Getting error on windows => System.PlatformNotSupportedException: 'System.IO.Ports is currently only supported on Windows.'

[harvinders]

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.

[stephentoub]

cc: @JeremyKuhne, @AlexGhiondea

[danmoseley]

@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.

[harvinders]

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.

[hillin]

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?

[hillin]

A slight bump: this issue persists in 4.7.0.

[JeremyKuhne]

Triage: @joperezr this appears to be packaging related, can you take a look?

[joperezr]

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:

1. Create your .NET Standard library project.
2. Add System.IO.Ports package version 4.7.0 and use it by for example referencing the SerialPort class.
3. Create a .NET Framework project that targets net461.
4. Add the following code to your .NET Framework .csproj:

<PropertyGroup>
  <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
  <RuntimeIdentifier>win</RuntimeIdentifier>
</PropertyGroup>

5. Add reference from .NET Framework project to your .NET Standard library project.
6. Using msbuild, restore packages for the .NET Framework project (either via developer command prompt or via Visual Studio). This step is very important. If doing it from the command line, then just call msbuild yourNetFrameworkProject.csproj /t:Restore
7. Use the netstandard library

After 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.

[JonasG0]

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.

[markusschweitzer]

Still persists in v5

[JonasG0]

I switched my minimal repo (https://github.com/JonasGoldt/PortsPackageProblem) to .NET5 and System.IO.Ports 5.0.0 and it seems to be fixed.

[JonasG0]

Sorry, forget my previous comment, it is still not working. I just made a mistake.

I "fixed" my repo and switched to System.IO.Ports 5.0.1, the test still fails:
https://github.com/JonasGoldt/PortsPackageProblem/runs/2278155935

[danmoseley]

Adding untriaged so the crew sees this update.

[djanri]

I've stuck with this issue in my WPF project after migrating from .netframework to .NET 6. My library and main projects have TargetFramework as "net6.0-windows". Installing package System.IO.Ports 6.0.0 does not fix the issue. Only copying dll from runtime "net6.0" fixes it.

For automation I added next code to the .csproj file:

<Target Name="PostBuild" AfterTargets="PostBuildEvent">
   <GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
     <Output TaskParameter="Assemblies" ItemName="CurrentAssembly" />
   </GetAssemblyIdentity>
   <Exec Command="xcopy /F /Y /E $(TargetDir)\\runtimes\\win\\lib\\net6.0\\ $(TargetDir)\\" />
 </Target>

[JanJorgensen]

I also have this problem since I migrated to .NET5 from .NET Framework 4x.
In my project I have addon assemblies loaded with reflection, and that breaks the addon that uses System.IO.Ports.dll.
As a temporary fix I have added the addon project directly as a reference from the WPF and console applications in the project, and that's not the right solution.
I have created a test project here on github.
The fix from @djanri does not work for me, maybe because I haven't done the procedure described by @joperezr, because I can see that the assembly is in runtimes\win\lib\netstandard2.0 !
I can see that @adamsitnik pushed this issue to 7.0.0, so I guess there's no solution anytime soon :-(

[Juniorsnet]

I've stuck with this issue in my WPF project after migrating from .netframework to .NET 6. My library and main projects have TargetFramework as "net6.0-windows". Installing package System.IO.Ports 6.0.0 does not fix the issue. Only copying dll from runtime "net6.0" fixes it.

For automation I added next code to the .csproj file:

<Target Name="PostBuild" AfterTargets="PostBuildEvent">
   <GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
     <Output TaskParameter="Assemblies" ItemName="CurrentAssembly" />
   </GetAssemblyIdentity>
   <Exec Command="xcopy /F /Y /E $(TargetDir)\\runtimes\\win\\lib\\net6.0\\ $(TargetDir)\\" />
 </Target>

I have a serialport project:
On Ubuntu 18.04, dotnet 6.0.200, System.IO.Ports 6.0.0, works OK
On Manjaro, dotnet 6.0.102, System.IO.Ports 6.0.0, Error "only support on windows"
The package System.IO.Ports was installer vía nuget (dotnet add package)
On Manajaro, the @djanri suggestion works OK.

[djanri]

I also have this problem since I migrated to .NET5 from .NET Framework 4x. In my project I have addon assemblies loaded with reflection, and that breaks the addon that uses System.IO.Ports.dll. As a temporary fix I have added the addon project directly as a reference from the WPF and console applications in the project, and that's not the right solution. I have created a test project here on github. The fix from @djanri does not work for me, maybe because I haven't done the procedure described by @joperezr, because I can see that the assembly is in runtimes\win\lib\netstandard2.0 ! I can see that @adamsitnik pushed this issue to 7.0.0, so I guess there's no solution anytime soon :-(

@JanJorgensen
Please look at fork on github. In the TheApp.csproj file you could find postbuild event which fixes your issue.

[JanJorgensen]

@JanJorgensen Please look at fork on github. In the TheApp.csproj file you could find postbuild event which fixes you issue.

@djanri
Thanks for your tip, but I don't have a "runtimes" folder in the target dir. In my case the target type is a class library. I'm not an expert in the build- and deploy-stuff, but I can see that there's a difference from building a class library and an executable. For executable projects, it works fine, but for class libraries loaded by reflection it doesn't.

[jozkee]

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.

Could anyone here facing the issue assist with the binlog @joperezr is asking for?
https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Binary-Log.md#creating-a-binary-log-during-a-build

[ghost]

This issue has been marked needs-author-action since it may be missing important information. Please refer to our contribution guidelines for tips on how to report issues effectively.

[Juniorsnet]

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.

Could anyone here facing the issue assist with the binlog @joperezr is asking for? https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Binary-Log.md#creating-a-binary-log-during-a-build

Here is my binlog.
I testing more and the version of .net maybe the problem.
On manjaro I remove the 6.0.0.102 from packages.
I install manually the 6.0.0.202 from dotnet-install.sh
Now the project runs.
The function SerialPort.GetPortNames() returns nothing but at least not crash with System.PlatformNotSupportedException
What is the diference between 6.0.0.1xx vs 6.0.0.2xx?
msbuild.binlog.gz

[ghost]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[ghost]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.