Shared framework is missing correct RID fallback chain for manjaro #62554
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
badgerwild
changed the title
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
dotnet-issue-labeler
bot
added
the
untriaged
|
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsDescribe the bugA embedded systems project that I am working on uses a C# program as a serial loader to send data to an Arduino Nano. I have installed dotnet and adding the To ReproduceExceptions (if any)Further technical detailsProject is built and run through the CLI using the command output of Here is
|
This should load net6.0-unix implementation in the runtimes/unix/lib/net6.0 folder per 00d8f8e#diff-896c6652ae24cab2b91d7d5ab1696fced448d15514a344b7ea9d08552275d817R286 But instead is loading the platform-agnostic implementation (net6.0), which (BUG) should update its resource string. It could be caused by how your referencing the Ports (make sure to use the package) or loading it (make sure its listed in your project's deps file). Can you run just the output of the project, with host tracing enabled? That should indicate which RID the host is using and what assemblies it's considering when you load System.IO.Ports.dll. |
|
Here's how you can capture a host trace: https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#how-do-i-debug-the-probing-properties-construction |
ericstj
added
the
needs-author-action
|
Pretty sure that OS Exception is thrown here Line#25 I'd say it's not detecting Manjaro as a supported version of Linux? https://github.com/dotnet/runtime/blob/main/eng/pipelines/libraries/helix-queues-setup.yml |
|
This issue has been automatically marked |
|
Arch and Alpine Linux variants/derivatives raise this exception with .NET 6.0.1 |
|
Any updates on this? I couldn't find any workarounds so as of now I can't work on my application because of this targeting bug. It would be great to have a fix, even if it's just a temporary one. I searched through the sources and found some msbuild (I think) entries and copied them to my code to see what variables are set. However, I have never worked with msbuild directly and I'm not sure if I understand; please correct me if I'm wrong. The following .csproj builds correctly on my 5.16.2-1-MANJARO which would indicate that
If any of those conditions weren't true, the build would throw an error indicating that that file could not be found. <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.IO.Ports" Version="6.0.0" />
</ItemGroup>
<PropertyGroup>
<IsPartialFacadeAssembly Condition="$([MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')) == '.NETFramework'">true</IsPartialFacadeAssembly>
</PropertyGroup>
<ItemGroup>
<Compile Condition="'$(IsPartialFacadeAssembly)' == 'true'" Include="PartialFacadeAssembly == true" />
<Compile Condition="'$(TargetsAnyOS)' == 'true'" Include="TargetsAnyOS == true" />
<Compile Condition="'$(TargetsWindows)' == 'true'" Include="TargetsWindows == true" />
<Compile Condition="'$(TargetsUnix)' == 'true'" Include="TargetsUnix == true" />
</ItemGroup>
</Project>In the following snippet there's a condition for generating the not-supported warnings with "ISN'T a partial facade assembly AND DOES target any OS". I don't know when these conditions are checked. If they are checked when I build my project, I don't understand why these warnings are generated, since only the first of those two conditions apply to my project. Also more of a side-note but "System.IO.Ports is currently only supported on Windows." hasn't been true for quite a while now. |
According to https://github.com/dotnet/core/blob/main/release-notes/6.0/supported-os.md#linux, Alpine Linux should be fully supported, so that's even worse than the Manjaro case I guess. I also just now for the first time realized that .NET doesn't support Arch Linux derivatives. That's very unfortunate, I've been using it on Manjaro (arch based) for a while now without issues until this struck. I really hope .NET can support Arch distros in the future! |
|
Any updates on this? Or any workarounds? |
|
This issue has been automatically marked |
|
Bump |
OK I just downloaded latest version of Manjaro 21.2.4 and created a USB boot version (just for quick test on laptop)
So have you tried the latest build and latest preview of |
|
Unfortunately that doesn't work for me.
My os is: csproj of test-project: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.IO.Ports" Version="7.0.0-preview.1.22076.8" />
</ItemGroup>
</Project>I still get the same exception as soon as the constructor is called (after clearing all NuGet caches): Ps. your repo is probably private, I can't view it. |
|
5.16.11-2-MANJARO x86_64 GNU/Linux ? I can find that version, but might be just be a different reported version format. |
|
I just did Again, the more interesting difference might be how .NET was installed. Could you try installing .NET SDK 6.0.2 from the package manager and see if that works?
Not sure what you mean. It's bare-metal, not a VM, if that's what you mean. |
|
@Joelius300 Didn't want to make that repo public as it's just a very simple junk hack test util. But Ive added you as contributor so you can try it so comparing like for like. |
|
This issue has been automatically marked |
|
Bump |
|
@ericstj do you have any further thoughts re above? |
|
@Joelius300 sorry for the delay in getting back to you. Let me just restate what I'm seeing where I think things are going wrong. If you examine the fallback-RID chain's present in the success case, you'll see that a chain is defined for In the case of the failing runtime, the shared frameworks deps file does not have this fallback chain. The only one present is for If you would like for that failing case to better support falling back to the |
ericstj
changed the title
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsDescribe the bugA embedded systems project that I am working on uses a C# program as a serial loader to send data to an Arduino Nano. I have installed dotnet and adding the To ReproduceExceptions (if any)Further technical detailsProject is built and run through the CLI using the command output of Here is
|
|
@ericstj No worries, thanks for investigating :)
No idea, I'm sorry. If you need anything from my end, I'll be happy to assist where I can. |
|
This feels almost like a dupe of dotnet/sdk#23390. Short description of how the RID stuff works in the host:
I think the fix for this is effectively the same as the fix for dotnet/sdk#23390 - that is to never get a RID fallback graph which is incomplete. The |
|
It could be that #53550 helps here. |
|
This issue has been automatically marked |
|
Bump :) |
|
We don't plan to make any changes for this area for .NET 7. For .NET 8, we're investigating #59803, which may address this scenario directly, or cause us to take a different change for this. In the meantime I see two potential solutions:
|
agocke
removed
the
needs-author-action
|
Thank you for the clarification. For any Manjaro users stumbling into this issue, a third solution is using the AUR packages (e.g. |
|
FWIW, this also causes issues with other NuGet packages distributed in a multi-target manner, see e.g. kleisauke/net-vips#186. The symptoms are the same, it causes to reference |
|
Closing as RIDs are no longer resolved in the same way: https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/8.0/rid-asset-list |
ghost
locked as resolved and limited conversation to collaborators
Describe the bug
A embedded systems project that I am working on uses a C# program as a serial loader to send data to an Arduino Nano. I have installed dotnet and adding the
System.Io.Portspackage on the host machine. When trying to run the project, I get an error saying thatSystem.Io.Portsis only available on windows. This same code and installation process works on Ubuntu 18.04, the latest version of Arch Linux, and Mac without issue.To Reproduce
Exceptions (if any)
Further technical details
Project is built and run through the CLI using the command
sudo dotnet run <file>dotnet --infoon the Manjaro systemoutput of
dotnet list package:Here is
dotnet --infoon the Arch and Ubuntu systems where theSystem.Io.Serialdoes work on this project:The text was updated successfully, but these errors were encountered: