[BUG] SkiaSharp.csproj does not reference Linux native assets

[bitbltr]

Description

I'm getting a build issue where SkiaSharp.NativeAssets.Linux v2.88.7 is being included as a transient package rather than v3.119.0. I'm guessing, but believe this is due to SkiaSharp.csproj not referencing the SkiaSharp.NativeAssets.Linux project

Code

Add this to SkiaSharp.csproj:

Expected Behavior

Linux build to include the same version of all native assets as the version of SkiaSharp (3.119.0)

Actual Behavior

An old version of Linux native assets is included (2.88.1) and the following error is thrown:

System.TypeInitializationException : The type initializer for 'SkiaSharp.SKColorSpace' threw an exception.
----> System.TypeInitializationException : The type initializer for 'SkiaSharp.SKObject' threw an 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).

Version of SkiaSharp

3.116.0 (Current)

Last Known Good Version of SkiaSharp

2.88.9 (Previous)

IDE / Editor

Visual Studio (Windows), Other (Please indicate in the description)

Platform / Operating System

Linux

Platform / Operating System Version

Occurring in Linux runner in GitHub Action for CI

Devices

No response

Relevant Screenshots

No response

Relevant Log Output

Code of Conduct

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

[molesmoke]

Can you provide a repro? AFAIK, SkiaSharp doesn't reference the Linux native assets, nor the other way round:

https://www.nuget.org/packages/SkiaSharp#dependencies-body-tab
https://www.nuget.org/packages/SkiaSharp.NativeAssets.Linux/#dependencies-body-tab

So I'd guess this is a problem with your package references.

[bitbltr]

I'll work on a repro. In the meantime, I call this out because SkiaSharp references every other platform's native assets. So why does it not reference Linux? I'm not the only one with this issue: #3117 #3238

[molesmoke]

Primarily, I'd say that's a consequence of factors like Linux having multiple distros, C libraries etc. and needing a mechanism with NuGet to support the different configurations - you need some way to select the one that works for your particular case. Even on Windows it's a potential problem - 3.119.x is compiled against DX12 so it won't work out of the box on Windows 7 and earlier. It's not particularly uncommon for NuGets to take that approach. Not to mention that downloading all the native assets for every platform would take a bunch of potentially avoidable bandwidth and disk-space.

#3210