The 3.1 and 5.0 SDKs do not support musl/Alpine Linux anymore

[mattleibow]

Describe the bug

I am building an app for Alpine 3.15 and/or 3.16, but those versions of Alpine can no longer load the .so files from the linux-musl-x64 folders. I had a look at the runtime.json on those installs and I notice the version of alpine in the json is only 3.14.

To Reproduce

Just try use SkiaSharp - or any other NuGet that has a musl-specific binary.

Se also these issues:

• [BUG] SkiaSharp unable to load library libSkiaSharp or one of its dependencies after update alpine mono/SkiaSharp#2169
• Unable to load shared library 'libSkiaSharp' - Alpine Linux 3.16 - SkiaSharp.NativeAssets.Linux.NoDependencies 2.88.0 mono/SkiaSharp#2215

I can work around this by adding/editing the json file to include alpine.3.15 and alpine.3.16.

Exceptions (if any)

System.DllNotFoundException: Unable to load shared library 'libSkiaSharp' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library liblibSkiaSharp: No such file or directory

Further technical details

• Using the dotnet docker image which was Alpine 3.16 and had SDK 3.1.28 installed.
• I also see the Alpine version in the json on GitHub: https://github.com/dotnet/corefx/blob/v3.1.28/pkg/Microsoft.NETCore.Platforms/runtime.json#L80

[marcpopMSFT]

@rbhanda @richlander

[mattleibow]

I just downloaded the linux alpine package from the website: https://download.visualstudio.microsoft.com/download/pr/b0e6dd66-02f4-497d-b2d8-ccf0726d4c22/517de52ae05d7829e9be58b6b0308472/aspnetcore-runtime-3.1.28-linux-musl-x64.tar.gz

The package is not including the alpine.3.16 - even though it appears that this should exist based on the source in the comments above.

[richlander]

It's possible we've stopped making the required RID updates for those product versions. .NET Core 3.1 is now in maintenance and .NET 5 is EOL. You may need to move to .NET 6 to get the behavior you want. Per my understanding, .NET 6 doesn't have this problem such that RID updates are not required for it.

@vitek-karas can likely give us a definitive statement on this.

[mattleibow]

I am more concerned that the corefx repo has the required changes and the commits were added to specifically fix this. But the final packages do not see those changes. What other changes are missing?

[dsplaisted]

The runtime graph information in the SDK comes from the Microsoft.NETCore.Platforms package. The last 3.1 version of that package is 3.1.9 from October 2021.

@mmitche @joperezr @ericstj @vitek-karas Did we intend to stop updating the RuntimeIdentifier graph for 3.1 after 3.1.9?

[ericstj]

Seems like it was removed in dotnet/corefx@79ae376#diff-43676c2abb12b62b72c9d923c709c340a45fafccf2a7b7daf84549b0ee2b0f54L29
As is normal in branding for corefx incremental servicing, then it was not added back in subsequent releases despite version updates:
https://github.com/dotnet/corefx/commits/release/3.1/pkg/Microsoft.NETCore.Platforms
The first of those being the Alpine release mentioned in this issue.

I think we need to make sure to ship this package in the next servicing release, ensure we review for that package authoring change to the package.builds for all packages (including MIcrosoft.NETCore.Platforms) moving forward, and ensure that folks look for the updated package and ideally bundled runtime.json in the sdk as part of the validation for RID changes. @carlossanlop do you have a good place to document this?

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.