Problem under linux with a nuget referencing GdPicture.API

[Christophe]

Hello,

We have an application A referencing GdPicture.API. We created a nuget package of this application, and referenced this nuget in an application B. Under Windows it works fine, but under linux the execution of B fails with the message :
GdPicture runtime exception: Can not find GdPicture.NET.14.filters.64.so. Please, copy last version of this dll into your application directory at: /usr/lib64/dotnet
or
GdPicture runtime exception: Can not find GdPicture.NET.14.filters.64.so. Please, copy last version of this dll into your application directory at: <ProjetPath>/bin/Debug/net6.0
(depending on the dotnet container).

I am not very familiar with linux, but is there something specific to do, maybe in the configuration of package A, so that the GdPicture .so files are copied to the correct location and/or properly found ? Isn't referencing the GdPicture.API nuget in A enough ? I notice that at the build of B GdPicture.NET.14.API.dll is copied to the directory of B.exe but not the .so files.

[Fabio]

Hello Christophe,

This error could be due to a missing component on your Linux machine.
Have you installed .NET on it?
If not, that may explain why GdPicture cannot load the DLLs (the filters DLL is the first loaded in the build process).

The NuGet package takes care to get the right DLLs in the right folder to be built.

If you already have the right .NET version installed on your machine, could you please tell me what is your CPU?

Best regards,
Fabio

[emanuelr]

Hello, I'm running into the same issue when attempting to use GdPicture on Linux. I'm running Ubuntu X64 in WSL2 on my machine.
An exception is thrown when GdPicture is called. I can see the shared object runtime files are in the bin folder at runtimes/linux-x64/native.
Also this same app works on windows.

GdPicture.csproj

Code: Select all

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="GdPicture.API" Version="14.2.48" />
  </ItemGroup>
</Project>

Program.cs

Code: Select all

using GdPicture14;

// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World!");

LicenseManager licensceManager = new();

Console Output

Code: Select all

dev:~/dotnet/GdPicture$ dotnet run
Hello, World!
Unhandled exception. System.Exception: GdPicture runtime exception: Can not find GdPicture.NET.14.filters.64.so. Please, copy last version of this dll into your application directory at: /home/dev/dotnet/GdPicture/bin/Debug/net6.0
   at GdPicture.Internal.Imaging.ImageFiltering.FiltersImports.ᜀ(Boolean A_0)
   at GdPicture.Internal.Imaging.ImageFiltering.FiltersImports.ᜀ(Boolean A_0)
   at GdPicture.Internal.Globals.GdPictureToolkit.Initialize(Boolean forceInitialization, Int32 maxTreads)
   at GdPicture14.LicenseManager..ctor()
   at Program.<Main>$(String[] args) in /home/dev/dotnet/GdPicture/Program.cs:line 6

[Christophe]

Hello,

Thank you for your answers. .NET is a not a priori in question, with version 14.2.35 of GdPicture we found a workaround by adding a PrivateAssets tag in our csproj file

Code: Select all

	  <PackageReference Include="GdPicture.API" Version="14.2.35">
		  <PrivateAssets>none</PrivateAssets>
	  </PackageReference>

This solutions works but was not satisfactory in our case. From version 14.2.46 there has been a change in the package configuration that has led to the binaries now actually being copied to a runtimes/linux-x64/native sub-directory. It now works, but provided we specify the "-r linux-x64" option in the build or publish (even when compiling under Linux).

[doorknit]

One possible cause of this error on your Linux computer could be a missing component. Have you given it a.NET installation? If not, that could explain why the filters DLL loads first during the build process and GdPicture is unable to load the other DLLs.

[Christophe]

Hello,
As previously said, specifying the runtime "linux-x64" when building the application B (referencing the application A referencing GdPicture) solves the problem, for us it is ok now.

[Christophe]

Hello,
I noticed that there had been an evolution on this point from version 14.2.52, since this version the runtime option is no longer even necessary, so now everything works well.

[nora10]

It seems you're encountering an issue with referencing GdPicture.API via NuGet on Linux. Ensure that your project's dependencies and configurations are compatible with Mono or .NET Core, which are commonly used on Linux. Double-check the NuGet package compatibility with your target framework and version. Additionally, verify that all required native libraries are properly installed and accessible on your Linux environment. If the problem persists, consider reaching out to the GdPicture.API support community for further assistance.

[feeney2]

What are the changes in the package configuration of GdPicture.API from version 14.2.35 battleship game to 14.2.46 that resulted in the binaries being copied to a 'runtimes/linux-x64/native' sub-directory? And why is it necessary to specify the '-r linux-x64' option during build or publish, even when compiling under Linux?

[Christophe]

I talked about this subject to the GdPicture support and I guess the changes are in the "Fixes NuGet runtimes libraries resolution on Visual Studio debugging on WSL" release note of version 14.2.46 (although it is not only valid when debugging on wsl). The '-r linux'x64' option is no longer required since version 14.2.52, probably due to the same relase note on version 14.2.52.