NuGet Packages

Reference for all NuGet packages produced by SkiaSharp — purpose, contents, and usage guidance.

Related: Adding Libraries | Architecture | Linux Assets

Contents

• Core Managed Packages — SkiaSharp, HarfBuzzSharp, and extensions
• Views Packages — UI controls for each platform
• GPU Backend Packages — Vulkan and Direct3D support
• Native Assets — Platform-specific native binaries for SkiaSharp and HarfBuzzSharp
  • Platform Packages — Per-platform package details
  • Auto-Included NativeAssets — What's pulled in automatically by TFM
  • Linux Package Selection Guide — Which Linux package to use
• Deployment & Containers — Container and publishing guidance
  • Container Deployment — Which Linux package to use in containers
  • Publishing Modes — Framework-dependent, self-contained, single-file
• Obsolete Packages — Deprecated, do not use
• Troubleshooting: Native Loading — Diagnosing DllNotFoundException on Linux

Core Managed Packages

These contain the managed C# assemblies. The SkiaSharp and HarfBuzzSharp core packages automatically include the appropriate NativeAssets for most platforms (see Auto-Included NativeAssets). For Linux, WebAssembly, NanoServer, and WinUI you must add the NativeAssets package manually.

Views Packages

Platform-specific UI controls for rendering SkiaSharp content. These provide ready-to-use views/controls that handle the platform-specific rendering surface setup.

GPU Backend Packages

Optional packages for hardware-accelerated rendering via specific GPU APIs.

Native Assets

Each platform has a pair of NativeAssets packages containing pre-built native binaries:

• SkiaSharp.NativeAssets.{Platform} — contains libSkiaSharp
• HarfBuzzSharp.NativeAssets.{Platform} — contains libHarfBuzzSharp

Both follow the same platform matrix and architectures. HarfBuzzSharp does not have Linux.NoDependencies, NanoServer, or WinUI variants.

Important: Library projects should depend on SkiaSharp only. NativeAssets packages belong in the application (executable) project so the correct binary is deployed. See Deployment & Containers.

Platform Packages

⚠️ WASM is NOT dynamic loading. Unlike all other platforms, WebAssembly uses static linking at compile time. The .a files are passed to the Emscripten linker which embeds them into the final dotnet.wasm binary. DllImport("libSkiaSharp") still works — the .NET WASM runtime resolves it to statically linked symbols.

Unity WebGL: Unity WebGL also uses Emscripten. While not officially supported, the same static linking principle applies. Unity-specific integration may require manual configuration beyond the standard NativeFileReference approach.

Auto-Included NativeAssets

The core SkiaSharp and HarfBuzzSharp packages automatically include NativeAssets for most platforms via TFM-conditional dependencies:

Must be added manually (not auto-included):

• SkiaSharp.NativeAssets.Linux / HarfBuzzSharp.NativeAssets.Linux — for Linux server/desktop
• SkiaSharp.NativeAssets.Linux.NoDependencies — for minimal Linux containers (SkiaSharp only)
• SkiaSharp.NativeAssets.WebAssembly / HarfBuzzSharp.NativeAssets.WebAssembly — for Blazor/Uno WASM. SkiaSharp.NativeAssets.WebAssembly is auto-included by SkiaSharp.Views.Blazor and SkiaSharp.Views.Uno.WinUI; HarfBuzzSharp.NativeAssets.WebAssembly must always be added manually.
• SkiaSharp.NativeAssets.NanoServer — for Windows Nano Server (SkiaSharp only)
• SkiaSharp.NativeAssets.WinUI — for WinUI 3 apps (SkiaSharp only; auto-included by SkiaSharp.Views.WinUI)

Linux Package Selection Guide

Deployment & Containers

Application vs Library References

NativeAssets packages must be referenced in the application project (the one that produces the executable), not in library projects. The .NET runtime resolves native binaries from the application's output directory using runtime identifiers (RIDs).

If a NativeAssets package is only referenced in a transitive library, the native binary may not be copied to the final output — causing DllNotFoundException at runtime.

Container Deployment

For containers, use SkiaSharp.NativeAssets.Linux.NoDependencies unless you specifically need fontconfig for system font enumeration. This package has zero third-party dependencies and works in minimal base images (mcr.microsoft.com/dotnet/aspnet, Alpine, distroless).

Publishing Modes

Obsolete Packages

These packages are no longer actively maintained. Use the listed replacement.

Troubleshooting: Native Loading

Understanding DllNotFoundException on Linux

On Linux, DllNotFoundException errors from dlopen() have two distinct failure modes with different root causes:

Wrong Binary Deployed

SkiaSharp.NativeAssets.Linux.NoDependencies ships a .so with zero external dependencies — only libc/libm/libpthread/libdl. If you reference NoDependencies but see errors about missing fontconfig, uuid, or other libraries:

1. The binary being loaded is not from NoDependencies — it's from NativeAssets.Linux (or another source)
2. Check for a transitive SkiaSharp.NativeAssets.Linux reference conflicting with NoDependencies
3. Check that NoDependencies is in the executable project (not a library project)
4. Check your container build tool (e.g. .NET Aspire, Docker SDK) — it may deploy the wrong RID variant

You can verify which binary is loaded by running ldd on the libSkiaSharp.so in your publish output. The NoDependencies variant will show only libc/libm/libpthread/libdl.

Reading .NET Native Loading Errors

The .NET runtime tries multiple paths to load a native library and reports ALL failures. Focus on the first error — subsequent lines are fallback attempts:

System.DllNotFoundException: Unable to load shared library 'libSkiaSharp'
  libfontconfig.so.1: cannot open shared object file     ← LOOK HERE (binary found, dependency missing)
  /usr/share/dotnet/.../libSkiaSharp.so: cannot open      ← fallback path, file not found
  /app/liblibSkiaSharp.so: cannot open                    ← fallback path, file not found

Container Deployment Checklist

Related Documentation

• Adding Libraries — Creating new packages
• Architecture — Three-layer design
• Linux Assets — Linux package design philosophy
• Dependencies — Native dependency tracking