[BUG] Build outputs duplicate native libraries

[nneitzke]

Description

On .NET Framework 4.8 when this nuget package is referenced as part of an ASP.NET MVC application upon build (with msbuild) it outputs the native libraries into the OutputPath in both the root directory and the bin directory duplicating them all.

Code

Not applicable

Expected Behavior

single copy of dylib, x86, x64, and arm64 native libraries under bin/ (it would be extremely nice if we could just exclude platforms we don't want either, like dylibs/arm64).

Actual Behavior

The following files are generated on build -

libHarfBuzzSharp.dylib
libSkiaSharp.dylib
arm64/libHarfBuzzSharp.dll
arm64/libSkiaSharp.dll
x64/libHarfBuzzSharp.dll
x64/libSkiaSharp.dll
x86/libHarfBuzzSharp.dll
x86/libSkiaSharp.dll

bin/libHarfBuzzSharp.dylib
bin/libSkiaSharp.dylib
bin/arm64/libHarfBuzzSharp.dll
bin/arm64/libSkiaSharp.dll
bin/x64/libHarfBuzzSharp.dll
bin/x64/libSkiaSharp.dll
bin/x86/libHarfBuzzSharp.dll
bin/x86/libSkiaSharp.dll

Version of SkiaSharp

2.88.3 (Current)

Last Known Good Version of SkiaSharp

Other (Please indicate in the description)

IDE / Editor

Visual Studio (Windows)

Platform / Operating System

All

Platform / Operating System Version

No response

Devices

No response

Relevant Screenshots

No response

Relevant Log Output

No response

Code of Conduct

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

[rozeboosje]

Can I add my "me too" to this one? We are using a 3rd party product that, in its latest release, has started using SkiaSharp. Having upgraded to this release I see it's using SkiaSharp 2.88.6 but even when I update the nuget packages to SkiaSharp 2.88.8 it still ends up peppering our Error List with spurious nonsense such as:

Severity Code Description Project File Line Suppression State Details
Warning The referenced component 'C:\Users*****.nuget\packages\skiasharp.nativeassets.macos\2.88.8\buildTransitive\net462....\runtimes\osx\native\libSkiaSharp.dylib' could not be found. project name here

Not only is this annoying, but it generates "noise" in the Error List, which may lead to us failing to spot a serious warning that needs attention. I cannot stress enough how important it is that this is fixed.

We build for .NET Framework 4.8 for Windows 64-bit

[mattleibow]

@rozeboosje this is your issue which I just found a potential workaround; #2824