[BUG] Unable to load on Azure Container app with Aspire

[dansiegel]

Description

We are deploying a set of WebAPIs using .NET Aspire. This creates a Linux based Container App. While everything works locally it does not work when deployed in this way.

Code

<PackageReference Include="SkiaSharp" />
<PackageReference Include="SkiaSharp.NativeAssets.Linux.NoDependencies" />

Expected Behavior

Images should be able to generate.

Actual Behavior

Images fail to generate

Version of SkiaSharp

3.116.0 (Current)

Last Known Good Version of SkiaSharp

2.88.9 (Previous)

IDE / Editor

Visual Studio (Windows)

Platform / Operating System

Linux

Platform / Operating System Version

• (Linux) Azure Container App - deployed with .NET Aspire

Devices

No response

Relevant Screenshots

No response

Relevant Log Output

stdout F fail: Microsoft.AspNetCore.Server.Kestrel[13]
stdout F       Connection id "0HNGDGHEEMT83", Request id "0HNGDGHEEMT83:00000004": An unhandled exception was thrown by the application.
stdout F       System.TypeInitializationException: The type initializer for 'SkiaSharp.SKAbstractManagedStream' threw an exception.
stdout F        ---> System.DllNotFoundException: Unable to load shared library 'libSkiaSharp' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable: 
stdout F       libfontconfig.so.1: cannot open shared object file: No such file or directory
stdout F       /usr/share/dotnet/shared/Microsoft.NETCore.App/9.0.10/libSkiaSharp.so: cannot open shared object file: No such file or directory
stdout F       /app/liblibSkiaSharp.so: cannot open shared object file: No such file or directory
stdout F       /usr/share/dotnet/shared/Microsoft.NETCore.App/9.0.10/liblibSkiaSharp.so: cannot open shared object file: No such file or directory
stdout F       /app/libSkiaSharp: cannot open shared object file: No such file or directory
stdout F       /usr/share/dotnet/shared/Microsoft.NETCore.App/9.0.10/libSkiaSharp: cannot open shared object file: No such file or directory
stdout F       /app/liblibSkiaSharp: cannot open shared object file: No such file or directory
stdout F       /usr/share/dotnet/shared/Microsoft.NETCore.App/9.0.10/liblibSkiaSharp: cannot open shared object file: No such file or directory
stdout F       
stdout F          at SkiaSharp.SkiaApi.sk_managedstream_set_procs(SKManagedStreamDelegates procs)
stdout F          at SkiaSharp.SkiaApi.sk_managedstream_set_procs(SKManagedStreamDelegates procs)
stdout F          at SkiaSharp.SKAbstractManagedStream..cctor()
stdout F          --- End of inner exception stack trace ---
stdout F          at SkiaSharp.SKAbstractManagedStream..ctor(Boolean owns)
stdout F          at SkiaSharp.SKManagedStream..ctor(Stream managedStream, Boolean disposeManagedStream)
stdout F          at SkiaSharp.SKCodec.WrapManagedStream(Stream stream)
stdout F          at SkiaSharp.SKCodec.Create(Stream stream, SKCodecResult& result)
stdout F          at SkiaSharp.SKCodec.Create(Stream stream)
stdout F          at SkiaSharp.SKBitmap.Decode(Stream stream)

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Triage Summary

Labels will be applied to indicate the specific area of the issue (libSkiaSharp.native), the affected operating system (Linux), and a potential compatibility concern.

This issue is not explicitly defined as a regression but indicates a compatibility issue with different versions of SkiaSharp.

Additional remarks:

• The problem relates to a bug in deploying a web API using SkiaSharp; however, the currently available labels do not cover SkiaSharp or image processing contexts directly.

Detailed Summary and Actions

Summary of the triage:

• The issue involves a failure in loading the native library 'libSkiaSharp' on Linux.
• It is specifically occurring in a Linux-based Azure Container App.
• There's a potential compatibility concern between the current version of SkiaSharp (3.116.0) and the last known good version (2.88.9).

Summary of the actions that will be performed:

Action	Item	Description
Apply Label	area/libSkiaSharp.native	The issue pertains to a failure in loading the 'libSkiaSharp' library, which relates to the native bindings.
Apply Label	os/Linux	The issue is specifically occurring on a Linux-based Azure Container App.
Apply Label	tenet/compatibility	The issue indicates a potential compatibility problem with the current version of SkiaSharp compared to an earlier version.

This entire triage process was automated by AI and mistakes may have been made. Please let us know so we can continue to improve.

[dansiegel]

In case it helps anyone else who may find this later, I was able to come up with the following work around.

Fixing the TypeInitializationException

1. Since we had to use a custom image with the native dependencies installed, I switched to SkiaSharp.NativeAssets.Linux.
2. I created the following repo AvantiPoint/aspnet-skia. This has a Dockerfile based on the mcr.microsoft.com/dotnet/aspnet:X.0-noble image. This then installs all of the required native dependencies into the Linux Environment for SkiaSharp. You can find the public images for this on ghcr.io
   • ghcr.io/avantipoint/aspnet-skia:9.0
   • ghcr.io/avantipoint/aspnet-skia:10.0
3. I updated the csproj for each of the executable projects that we are deploying which might make use of SkiaSharp to include the following:

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>net9.0</TargetFramework>
  <ContainerBaseImage>ghcr.io/avantipoint/aspnet-skia:9.0</ContainerBaseImage>
</PropertyGroup>

4. While the packages are public, ghcr.io requires authentication. Generate a PAT for GitHub and run docker login ghcr.io.

---

Fixing the Missing Assembly (Trimming)

Following the TypeInitializationException we were still getting another fatal error. This was being caused by the fact that System.Memory.Data was not found. This assembly was a transitive reference for us and was therefore being stripped out because trimming is enabled. When we set this to be a Top Level NuGet dependency this issue was resolved and our APIs began working as expected and like they do in development.

<ItemGroup>
  <!-- 
    NOTE: 
       We use Central Package Management... 
       you should target the version that makes sense for your project. 
  -->
  <PackageReference Include="System.Memory.Data" />
</ItemGroup>