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

4

I had found some of this also. and I have added libfreetype6 to the container. or at least I think I did that part correctly.

# your regular RUN statements here

# Install required packages

RUN apt-get -q -y update && \

apt-get -q -y install \\

openssl \\

openssh-server \\

rsync \\

file \\

libice6 \\

libsm6 \\

libx11-dev \\

libfontconfig1 \\

libfreetype6 \\

&& apt-get clean && apt-get autoremove && \\

rm -rf /var/lib/apt/lists/\*

but I am at a loss on how to add he LD_PRELOAD to the docker file.

I am pretty sure it will be added to the CMD line but I have been failing at the correct formatting. I am also just guessing that I will need to have it on the Dockerfile.debug and Dockerfile (files in the project)

I will keep at it but very open to suggestions.

5

The LD_PRELOAD is just an environment variable, so I would assume something like this should work:

  • In Dockerfile:
ENV LD_PRELOAD="/usr/lib/libfreetype.so /usr/lib/libuuid.so"

Or when running the container:

docker run -e LD_PRELOAD="/usr/lib/libfreetype.so /usr/lib/libuuid.so" <image>

Just make sure you have the right paths to the libraries (they may be in a different folder, not /usr/lib - depends on what base OS docker image you have). You can run the container once in interactive mode, check the location and then adjust your Dockerfile or command line arguments accordingly.

6

well at least I did manage to find that information. I tried:

ENV LD_PRELOAD=“LD_PRELOAD=/usr/lib/aarch64-linux-gnu/libfreetype.so.6”

but that produced an error:

ERROR: ld.so: object ‘LD_PRELOAD=/usr/lib/aarch64-linux-gnu/libfreetype.so.6’ from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

so I tried setting Environment in the yaml file

- LD_PRELOAD=/usr/lib/aarch64-linux-gnu/libfreetype.so.6

that didn’t produce an error but with either variation I still end up with the undefined symbol: FT_Get_BDF_Property error.

I am attempting to start with a fresh template and bring pieces of code in one bit at a time now.

I am a bit frustrated at the process at the moment.

7

well I found that it was the Avalonia.Scott plot component causing the issue. will need to rethink a graphing component for now.