Avalonia project/template update issue

Technical Support
, ,
1

So I had a small Avalonia project started a few months back. put it on the back burner while figuring out a couple other containers. Came back to it loaded it up and I am now getting an error:

Exception has occurred: CLR/System.TypeInitializationException
An unhandled exception of type 'System.TypeInitializationException' occurred in SkiaSharp.dll: 'The type initializer for 'SkiaSharp.SKFontManager' threw an exception.'
 Inner exceptions found, see $exception in variables window for more details.
 Innermost exception 	 System.InvalidOperationException : The version of the native libSkiaSharp library (88.1) is incompatible with this version of SkiaSharp. Supported versions of the native libSkiaSharp library are in the range [119.0, 120.0).
   at SkiaSharp.SkiaSharpVersion.CheckNativeLibraryCompatible(Version minSupported, Version current, Boolean throwIfIncompatible)
   at SkiaSharp.SkiaSharpVersion.CheckNativeLibraryCompatible(Boolean throwIfIncompatible)
   at SkiaSharp.SKObject..cctor()

so I did what I worked for me in the past and created a new avalonia project from the extension. Ran it just fine. Then brought my existing files over. rebuilt and still the same error. I am not sure how to work this one out since it is in the Skia library’s.

I did try adding these package references to the project:

  <PackageReference Include="SkiaSharp" Version="3.119.1" />
  <PackageReference Include="SkiaSharp.NativeAssets.Linux" Version="3.119.1" />

Which eliminates the exception… But then I am stuck with the following:

Fontconfig warning: "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf", line 6: unknown element "reset-dirs"
/home/torizon/app/PowisAvaloniaUI: symbol lookup error: /home/torizon/app/libSkiaSharp.so: undefined symbol: FT_Get_BDF_Property

and the container dies before I can collect any data.

I am still to darn new to the container trouble shooting so not sure which way to go.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

SkiaSharp Version Compatibility Issue with .NET Avalonia

This appears to be a SkiaSharp native library version mismatch issue that commonly occurs when updating or recreating Avalonia projects. The error indicates that your project is trying to use SkiaSharp version 3.119.1 with a native library version 88.1, but SkiaSharp 3.119.1 expects native library versions in the range [119.0, 120.0).

Root Cause Analysis

The issue stems from two potential sources:

  1. Container Base Image Mismatch: The Toradex dotnet-uno container you’re using may contain an older version of the native SkiaSharp libraries
  2. Package Version Conflicts: When you manually added the SkiaSharp package references, you created a version conflict between the managed SkiaSharp package and the native libraries in the container

Recommended Solution Steps

Step 1: Remove Manual SkiaSharp References

Remove these lines from your .csproj file:

<PackageReference Include="SkiaSharp" Version="3.119.1" />
<PackageReference Include="SkiaSharp.NativeAssets.Linux" Version="3.119.1" />

Step 2: Check Your Container Base Image

For .NET Avalonia FrameBuffer applications, Toradex uses custom dotnet-uno containers as base containers(1). These containers are based on Torizon base containers but include the appropriate .NET runtime and necessary dependencies.

Step 3: Verify Template Consistency

Since creating a new Avalonia project from the Torizon extension worked fine, compare:

  • The .csproj file package references
  • The Dockerfile base image version
  • The tasks.json configuration

Step 4: Container Rebuild

After removing the manual SkiaSharp references:

  1. Clean your build artifacts
  2. Rebuild the container completely using the Torizon extension
  3. Deploy and test

Additional Troubleshooting

If the issue persists, the problem may be related to the specific version of the dotnet-uno container being used. The Toradex .NET templates use the --no-self-contained argument with dotnet publish because the .NET runtime is already included in the container(1).

Alternative Approach

If you continue experiencing issues, consider:

  1. Creating a fresh Avalonia project from the Torizon extension
  2. Gradually migrating your application code (not project files) to the new template
  3. Testing after each major component migration to isolate any problematic dependencies

This approach ensures you’re using the exact container configuration and dependency versions that Toradex has tested and validated for Avalonia FrameBuffer applications.

Best regards,
Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hi,

We also faced this issue with SkiaSharp 3.119+ on Uno Platform/Avalonia applications. It is reported in the SkiaSharp repo and a possible solution described in the same thread. Make sure you have libfreetype installed in the container and do LD_PRELOAD before running the app if necessary. Sometimes this also needs to be done for libuuid.

Something like this worked for us in a non-containerized environment on tdx-multimedia image where the right versions of libfreetype and libuuid can be found under /usr/lib:

LD_PRELOAD="/usr/lib/libfreetype.so.6 /usr/lib/libuuid.so.1" <path to self-contained app>

Hope it helps,

Sergey